Pseudo-graphics symbols encoded to three bytes in UTF-8. That's
why it's not enough. So you either ignore it or make windows at
least 3 times wider than that message. It might sound stupid and
overkill, but it shall do the trick. :)
I usually just ignore it. But it would be nice if one day it displayed properly. :)
By the way, I see you added the Aliases branch to master, were you
still planning on setting the locale before initscr?
I've updated my Golded to the latest, and then added that line again
and recompiled. Still seems to be working as expected!
That would be perfect. It only takes huge amount of effort.
Especially with keeping code backward compatible with systems,
which may not have Unicode support. I keep thinking about it and
looking for possible ways to implement.
For example function, which splits message to lines is almost
1000 lines long! It has variables, used in multiple places, it
not only splits the message, but guess charset, do recoding and
other fun stuff.
I've updated my Golded to the latest, and then added that line
again and recompiled. Still seems to be working as expected!
Great. Thanks for help!
I've updated my Golded to the latest, and then added that line
again and recompiled. Still seems to be working as expected!
Great. Thanks for help!
Since I would just sit there like a deer in headlights if I were to
jump into the code myself, I'll leave that up to you and just test
where I can. :)
Definitely not going to stop traffic or anything, but if you take a
look at the above quote header line taken from golded.tpl, it seems
when trying to use "@otzoffset" in golded.tpl it adds an extra space before it. I'm specifically using "On @odate @otzoffset," with only
one space in between the two tokens, and the date I have set in gedlngus.cfg doesn't have a space at the end of it, either.
Definitely not going to stop traffic or anything, but if you take a
look at the above quote header line taken from golded.tpl, it seems
when trying to use "@otzoffset" in golded.tpl it adds an extra space
before it. I'm specifically using "On @odate @otzoffset," with only
one space in between the two tokens, and the date I have set in
gedlngus.cfg doesn't have a space at the end of it, either.
That shall be supersimple. I'll take a look on that too when have some time.
I've updated my Golded to the latest, and then added that line
again and recompiled. Still seems to be working as expected!
Great. Thanks for help!
Since I would just sit there like a deer in headlights if I were
to jump into the code myself, I'll leave that up to you and just
test where I can. :)
I'll work on that. Wait couple of days please.
Definitely not going to stop traffic or anything, but if you
take a look at the above quote header line taken from
golded.tpl, it seems when trying to use "@otzoffset" in
golded.tpl it adds an extra space before it. I'm specifically
using "On @odate @otzoffset," with only one space in between the
two tokens, and the date I have set in gedlngus.cfg doesn't have
a space at the end of it, either.
That shall be supersimple. I'll take a look on that too when have
some time.
Thank you!
Best possible way is to use UTF-8 for all strings inside and only
convert text when read/write from/to message base and to screen.
And even if drop DOS support - need to take into account OS specifics
for Unicode.
As long as GoldEd uses fixed size buffers in many places -
that's huge refactoring. Better to replace it with std::string almost everywhere.
For example function, which splits message to lines is almost
1000 lines long! It has variables, used in multiple places, it
not only splits the message, but guess charset, do recoding and
other fun stuff.
That's one of the reasons, why progress is slow.
Best possible way is to use UTF-8 for all strings inside and only
convert text when read/write from/to message base and to screen.
And even if drop DOS support - need to take into account OS
specifics for Unicode.
As long as GoldEd uses fixed size buffers in many places -
that's huge refactoring. Better to replace it with std::string
almost everywhere.
For example function, which splits message to lines is almost
1000 lines long! It has variables, used in multiple places, it
not only splits the message, but guess charset, do recoding and
other fun stuff.
That's one of the reasons, why progress is slow.
If you may try to add one line of code to latest master and try it -
that would be helpful.
goldlib/gcui/gkbdbase.cpp
line 149, right before initscr add this:
setlocale(LC_ALL, "");
If you may try to add one line of code to latest master and try
it - that would be helpful.
goldlib/gcui/gkbdbase.cpp
line 149, right before initscr add this:
setlocale(LC_ALL, "");
I pulled in the latest code with this change, and this breaks my configuration again. :-(
So I reverted that change, and everything is back to normal...
I haven't tried OS/2 at all, so have no idea, how UTF-8 works there.
Does it use ncurses too?
Pull request is sent. Wait for commit.
Unfortunately it will break pseudo-graphics in some other systems. But
my change shall be there anyway. Ncurses shall not be initialized before setlocale().
I pulled in the latest code with this change, and this breaks my configuration again. :-(
So I reverted that change, and everything is back to normal...
Pull request is sent. Wait for commit.
Unfortunately it will break pseudo-graphics in some other systems. But
my change shall be there anyway. Ncurses shall not be initialized
before setlocale().
Windows and Linux works with console very differently. Even support
those two together is a challenge. Code is not very well encapsulated in GoldEd and OS specifics just everywhere.
Pull request is sent. Wait for commit.
Unfortunately it will break pseudo-graphics in some other
systems. But my change shall be there anyway. Ncurses shall not
be initialized before setlocale().
Thank you, I'll update when it's pushed!
Why would it break pseudo-graphics in other systems? Or are you just referring to other systems that don't actually use translation tables?
:)
Pull request is sent. Wait for commit.
Unfortunately it will break pseudo-graphics in some other
systems. But my change shall be there anyway. Ncurses shall not
be initialized before setlocale().
The specific things you did for me are working as expected. Thank you!
Windows and Linux works with console very differently. Even
support those two together is a challenge. Code is not very well
encapsulated in GoldEd and OS specifics just everywhere.
duno if it'd be useful but nftp (ayukov.com) had a little ui unit for win/lin/os2/etc .. if only to see other examples
If you may try to add one line of code to latest master and try
it - that would be helpful.
goldlib/gcui/gkbdbase.cpp
line 149, right before initscr add this:
setlocale(LC_ALL, "");
I pulled in the latest code with this change, and this breaks my
configuration again. :-(
So I reverted that change, and everything is back to normal...
One of the changes is very similar to that one which was reverted previously.
Remind me your setup please. Do you use UTF-8 locale?
What terminal do you use? TERM variable.
Do you use local console or remote/ssh?
Why would it break pseudo-graphics in other systems? Or are you just
referring to other systems that don't actually use translation tables?
:)
It's not about translation tables, but about displaying the text.
Ncurses has special logic to output pseudo-graphics and it most probably won't work correctly in Unicode locale. It was kinda "working" just because ncurses "thought" that it worked in "legacy" mode, not unicode.
Why would it break pseudo-graphics in other systems? Or are you
just referring to other systems that don't actually use
translation tables?
:)
It's not about translation tables, but about displaying the text.
Ncurses has special logic to output pseudo-graphics and it most
probably won't work correctly in Unicode locale. It was kinda
"working" just because ncurses "thought" that it worked in
"legacy" mode, not unicode.
But, I'm the one using a unicode locale, and it is working. It seems
to only affect people using a cp437/cp850-style single bit locale.
If you may try to add one line of code to latest master and try
it - that would be helpful.
goldlib/gcui/gkbdbase.cpp
line 149, right before initscr add this:
setlocale(LC_ALL, "");
I pulled in the latest code with this change, and this breaks
my configuration again. :-(
So I reverted that change, and everything is back to normal...
One of the changes is very similar to that one which was reverted
previously.
Remind me your setup please. Do you use UTF-8 locale?
# sudo -u fido locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
(I also start golded with 'sudo -u fido')
But for my golded terminal in Konsole, I have the "Default character encoding" set to IBM850.
What terminal do you use? TERM variable.
# sudo -u fido echo $TERM
xterm
Do you use local console or remote/ssh?
Both, but this test I only did in my local console.
OK. Your terminal works in IBM850, but you run golded may try to run
in UTF-8. That won't work and it worked before just because golded was
not initializing correctly!
Question. What is your XLatLocalSet in GoldEd?
OK. Your terminal works in IBM850, but you run golded may try to
run in UTF-8. That won't work and it worked before just because
golded was not initializing correctly!
Ok, so how do I fix it? ;)
Yesterday I did some experimenting with the latest golded (commit:
"call setlocale() before initscr() (#86)"), trying different ways to start golded and different golded xlat configurations. I found 2
setups that work for me, so the messages with pseudo graphics in the STATS area look ok:
My golded.cfg for both:
include charsets.cfg
XLATIMPORT CP437
XLATLOCALSET CP850
XLATEXPORT CP850
And starting golded in a local Konsole terminal "TERM=xterm" with the default charset set to utf-8:
# sudo -u fido LANG=en_EN.CP850 luit -encoding 'CP850' /usr/local/bin/golded -f
And in the same kind of terminal but with the default charset set to cp850, this one works:
# sudo -u fido LANG=en_US.CP850 /usr/local/bin/golded -f
I will still have to test these in a putty terminal later during the coming week.
And messages which have utf-8 characters, like the ones from Michiel
in the UTF area, don't display properly (of course). I did try adding:
XLATCHARSET UTF-8 CP850 utf8_850.chs
But that didn't help. Of course only a small subset of utf-8
characters can be displayed with cp850...
OK. Your terminal works in IBM850, but you run golded may try to run
in UTF-8. That won't work and it worked before just because golded
was not initializing correctly!
Ok, so how do I fix it? ;)
Yesterday I did some experimenting with the latest golded (commit:
"call setlocale() before initscr() (#86)"), trying different ways to
start golded and different golded xlat configurations. I found 2
setups that work for me, so the messages with pseudo graphics in the
STATS area look ok:
My golded.cfg for both:
include charsets.cfg
XLATIMPORT CP437
XLATLOCALSET CP850
XLATEXPORT CP850
Do not use xlatexport cp850. This parameter is used to select charset which
will be used when you write messages to message base. Unless you really want cp850. I assume you want to have cp437 there.
And starting golded in a local Konsole terminal "TERM=xterm" with
the default charset set to utf-8:
# sudo -u fido LANG=en_EN.CP850 luit -encoding 'CP850'
/usr/local/bin/golded -f
If you use luit - than having xterm in UTF-8 is correct.
And in the same kind of terminal but with the default charset set to
cp850, this one works:
# sudo -u fido LANG=en_US.CP850 /usr/local/bin/golded -f
This is correct commandline to if you have your terminal in cp850. Just choose what works better for you. Probably luit and terminal in UTF-8 is most convenient.
I will still have to test these in a putty terminal later during the
coming week.
Putty will work fine. Only I suggest you to change terminal type in putty from xterm (they use if by default)
to putty or putty-256color. It's in Connection->Data section.
And messages which have utf-8 characters, like the ones from Michiel
in the UTF area, don't display properly (of course). I did try
adding:
XLATCHARSET UTF-8 CP850 utf8_850.chs
But that didn't help. Of course only a small subset of utf-8
characters can be displayed with cp850...
Golded cannot read from UTF-8. There is no Unicode support. You must use another editor or GoldEd with external editor to work with Unicode.
It may convert from one-byte charsets to UTF-8, but not vise versa.
Golded cannot read from UTF-8. There is no Unicode support. You must
use another editor or GoldEd with external editor to work with
Unicode.
It may convert from one-byte charsets to UTF-8, but not vise versa.
And starting golded in a local Konsole terminal "TERM=xterm" with
the default charset set to utf-8:
# sudo -u fido LANG=en_EN.CP850 luit -encoding 'CP850'
/usr/local/bin/golded -f
If you use luit - than having xterm in UTF-8 is correct.
And in the same kind of terminal but with the default charset set
to cp850, this one works:
# sudo -u fido LANG=en_US.CP850 /usr/local/bin/golded -f
This is correct commandline to if you have your terminal in cp850.
Just choose what works better for you. Probably luit and terminal in
UTF-8 is most convenient.
I'll see after I have tested with putty...
I will still have to test these in a putty terminal later during
the coming week.
Putty will work fine. Only I suggest you to change terminal type in
putty from xterm (they use if by default)
I think it's set to 'linux' in putty.
to putty or putty-256color. It's in Connection->Data section.
Golded cannot read from UTF-8. There is no Unicode support. You
must use another editor or GoldEd with external editor to work
with Unicode.
It may convert from one-byte charsets to UTF-8, but not vise
versa.
We know it is unsupported, but I'm pretty sure I've said multiple
times it can display in Golded just fine, with CHRS kludge, UTF-8
Cyrillic characters (MANY other characters display fine, also):
https://pharcyde.org/golded-utf8.png
It indeed can be done. The problem is everyone's terminals and what
else is being used to run golded is different in every case.
And starting golded in a local Konsole terminal "TERM=xterm"
with the default charset set to utf-8:
# sudo -u fido LANG=en_EN.CP850 luit -encoding 'CP850'
/usr/local/bin/golded -f
If you use luit - than having xterm in UTF-8 is correct.
This one also works with putty (which is set to use utf-8 as charset).
And in the same kind of terminal but with the default charset
set to cp850, this one works:
# sudo -u fido LANG=en_US.CP850 /usr/local/bin/golded -f
This is correct commandline to if you have your terminal in
cp850. Just choose what works better for you. Probably luit and
terminal in UTF-8 is most convenient.
I'll see after I have tested with putty...
I'll probably switch to this setup since it also works with putty.
I will still have to test these in a putty terminal later
during the coming week.
Putty will work fine. Only I suggest you to change terminal type
in putty from xterm (they use if by default)
I think it's set to 'linux' in putty.
Switching from 'linux' to 'putty' makes things worse:
https://paste.opensuse.org/pastes/8a290fabf761
Also some keys, like the F3 key stopped working. So I keep my
terminal
type as 'linux'.
to putty or putty-256color. It's in Connection->Data section.
'putty-256color' makes no difference.
This is correct commandline to if you have your terminal in
cp850. Just choose what works better for you. Probably luit and
terminal in UTF-8 is most convenient.
I'll see after I have tested with putty...
I'll probably switch to this setup since it also works with putty.
It's definitely more convenient.
Putty will work fine. Only I suggest you to change terminal type
in putty from xterm (they use if by default)
I think it's set to 'linux' in putty.
Switching from 'linux' to 'putty' makes things worse:
https://paste.opensuse.org/pastes/8a290fabf761
That may be because terminfo for putty doesn't exist on your system. You may need to install additional packages. I have putty-256color and it works
perfect.
How to check.
Run infocmp -D
This will show you which directories are used to find terminfo.
Then search in those directories, is putty available. If not - you may need
install package like ncurses-term. May have different name on your system.
Let me know it that helped please.
Also some keys, like the F3 key stopped working. So I keep my
terminal type as 'linux'.
to putty or putty-256color. It's in Connection->Data section.
'putty-256color' makes no difference.
putty-256color just add more colors support. F keys are broken most probably because terminfo is missing.
This is correct commandline to if you have your terminal in
cp850. Just choose what works better for you. Probably luit
and terminal in UTF-8 is most convenient.
I'll see after I have tested with putty...I'll probably switch to this setup since it also works with
putty.
It's definitely more convenient.
I changed to using luit, for both the putty and konsole terminals for golded.
I do now have the problem that sometimes (not most of the time), the terminal is in strange state after closing golded. I've fixed that by adding the 'reset' command as the last command in the script that
starts golded.
Putty will work fine. Only I suggest you to change terminal
type in putty from xterm (they use if by default)
I think it's set to 'linux' in putty.
Switching from 'linux' to 'putty' makes things worse:
https://paste.opensuse.org/pastes/8a290fabf761
That may be because terminfo for putty doesn't exist on your
system. You may need to install additional packages. I have
putty-256color and it works perfect.
How to check.
Run infocmp -D
This will show you which directories are used to find terminfo.
Then search in those directories, is putty available. If not -
you may need install package like ncurses-term. May have
different name on your system.
I had already checked this:
# ls -l /etc/termcap
lrwxrwxrwx 1 root root 23 2015-10-29 21:23:18 termcap -> /usr/share/misc/termcap
# grep putty /etc/termcap
putty|PuTTY terminal emulator:\
vt100-putty|Reset PuTTY to pure vt100:\
putty-256color|PuTTY 0.58 with xterm 256-colors:\
putty-vt100|VT100+ keyboard layout:\
putty-sco|putty with SCO function keys:\
infocmp shows more or less the same:
# infocmp -D
/usr/share/terminfo
# find /usr/share/terminfo -iname 'putty*'
/usr/share/terminfo/p/putty
/usr/share/terminfo/p/putty-256color
/usr/share/terminfo/p/putty-sco
/usr/share/terminfo/p/putty-vt100
Let me know it that helped please.
So terminfo for putty already exists on my system...
Also some keys, like the F3 key stopped working. So I keep my
terminal type as 'linux'.
to putty or putty-256color. It's in Connection->Data section.
'putty-256color' makes no difference.
putty-256color just add more colors support. F keys are broken
most probably because terminfo is missing.
That is not the case...
putty-256color just add more colors support. F keys are broken
most probably because terminfo is missing.
That is not the case...
I spend a lot of time configuring my Putty to work correctly. I'd suggest you first make it working without luit.
You may need to play with Putty's settings. And TERM=putty works the
best for me. What I mean - it may work and it's just configuration
thing. It should be totally fine for you too because you have correct termnifo.
putty-256color just add more colors support. F keys are broken
most probably because terminfo is missing.
That is not the case...
I spend a lot of time configuring my Putty to work correctly. I'd
suggest you first make it working without luit.
Then I have to set my terminals to cp850 charset. I rather keep them
as utf8
You may need to play with Putty's settings. And TERM=putty works
the best for me. What I mean - it may work and it's just
configuration thing. It should be totally fine for you too
because you have correct termnifo.
I can spend a lot of time on it, or keep my current working config...
I see no gain, spending the time.
I spend a lot of time configuring my Putty to work correctly. I'd
suggest you first make it working without luit.
Then I have to set my terminals to cp850 charset. I rather keep them
as utf8
Only temporary. F keys shall not be dependent on locale.
You may need to play with Putty's settings. And TERM=putty works
the best for me. What I mean - it may work and it's just
configuration thing. It should be totally fine for you too
because you have correct termnifo.
I can spend a lot of time on it, or keep my current working config...
I see no gain, spending the time.
Sure. If that works for you. I'm just trying to help. :)
I spend a lot of time configuring my Putty to work correctly.
I'd suggest you first make it working without luit.
Then I have to set my terminals to cp850 charset. I rather keep
them as utf8
Only temporary. F keys shall not be dependent on locale.I suspect it might have to do with different escape sequences, or handling of, for the function keys in the 'linux' and 'putty'
settings.
You may need to play with Putty's settings. And TERM=putty
works the best for me. What I mean - it may work and it's just
configuration thing. It should be totally fine for you too
because you have correct termnifo.
I can spend a lot of time on it, or keep my current working
config... I see no gain, spending the time.
Sure. If that works for you. I'm just trying to help. :)And that is highly appreciated!
I suspect it might have to do with different escape sequences, or
handling of, for the function keys in the 'linux' and 'putty'
settings.
You're completely right. That's the reason. And when you change terminal type, ncurses expects different escape sequences.
My settings are:
terminal type putty
Then in Terminal->Keyboard:
The Backspace key -> Control-?
The Home and End keys -> Standard
The Function keys and keypad -> ESC[n~
Shift/Ctrl/Alt with the arrow keys -> Ctrl toggles app mode
Initial state of cursor keys -> Normal
Initial state of numeric keypad -> Normal
AltGf acts as Compose key -> off
Control-Alt is different from AltGf -> on
In Terminal->Features all is off except "Disable application keypad mode"
Try my settings. It could work.
I suspect it might have to do with different escape sequences,
or handling of, for the function keys in the 'linux' and
'putty' settings.
You're completely right. That's the reason. And when you change
terminal type, ncurses expects different escape sequences.
My settings are:
terminal type putty
Then in Terminal->Keyboard:
The Backspace key -> Control-?
The Home and End keys -> Standard
The Function keys and keypad -> ESC[n~
That was the one that was different for me.
I also had to Disable remote-controled terminal resizing, otherwise my terminal would resize to 80 chars wide after closing golded.
Shift/Ctrl/Alt with the arrow keys -> Ctrl toggles app mode
Initial state of cursor keys -> Normal
Initial state of numeric keypad -> Normal
AltGf acts as Compose key -> off
Control-Alt is different from AltGf -> on
In Terminal->Features all is off except "Disable application
keypad mode"
Try my settings. It could work.
It fixed the keyboard problems. But not how golded looks. The line drawing characters are still the 'qqqqqq' kind. It doesn't matter if I use luit or not.
What did help, was enabling in Window/Tranlation: Enable VT100 line drawing even in UTF-8 mode So now I can use the 'putty-256color'
terminal type. :-)
What did help, was enabling in Window/Tranlation: Enable VT100 line
drawing even in UTF-8 mode So now I can use the 'putty-256color'
terminal type. :-)
The only difference that I don't run golded in UTF, that's why you had to change this parameter. Glad it works for you!
My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit -encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?
My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit
-encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?
Make sure your luit has that encoding.
$ luit -list | grep CP850
What did help, was enabling in Window/Tranlation: Enable VT100
line drawing even in UTF-8 mode So now I can use the
'putty-256color' terminal type. :-)
The only difference that I don't run golded in UTF, that's why
you had to change this parameter. Glad it works for you!
My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit -encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?
What did help, was enabling in Window/Tranlation: Enable VT100
line drawing even in UTF-8 mode So now I can use the
'putty-256color' terminal type. :-)
The only difference that I don't run golded in UTF, that's why
you had to change this parameter. Glad it works for you!
My terminal is UTF, bug I start golded with 'LANG=en_EN.CP850 luit
-encoding 'CP850'', so I don't run golded in UTF either. Or do you
mean something else?
Yep. That is what I meant. Anyway I glad it works for you now.
I'm still seeing an issue with some messages in German areas. For instance:
https://paste.opensuse.org/pastes/0cc6a7ecd695
Some characters are displayed as '~A', where they should be able to be displayed in their right form, while others are displayed correctly.
The two High ascii characters in the marked area are:
\x81 ; latin small letter u with diaeresis
\xE1 ; greek small letter beta (here used as german ss)
The last character in the line, an 'e', isn't even displayed, probably because
of the expansion of 1 of the characters to 2 characters.
These characters are the same in CP437 and CP850. So my CP850 terminal should
display them correctly. It seems to come from Golded itself, or maybe the ncurses library, because it doesn't matter if I use luit for starting Golded
or not, or running it in my remote putty terminal, or my local konsole terminal. The \x81 character is always displayed as ~A ... Strange!?
I'm still seeing an issue with some messages in German areas.
For
instance:
https://paste.opensuse.org/pastes/0cc6a7ecd695
Some characters are displayed as '~A', where they should be able
to be displayed in their right form, while others are displayed
correctly.
The two High ascii characters in the marked area are:
\x81 ; latin small letter u with diaeresis
\xE1 ; greek small letter beta (here used as german ss)
The last character in the line, an 'e', isn't even displayed,
probably because of the expansion of 1 of the characters to 2
characters.
These characters are the same in CP437 and CP850. So my CP850
terminal should display them correctly. It seems to come from
Golded itself, or maybe the ncurses library, because it doesn't
matter if I use luit for starting Golded or not, or running it
in my remote putty terminal, or my local konsole terminal. The
\x81 character is always displayed as ~A ... Strange!?
Btw: My terminal seems fine with displaying the CP850 high ascii characters (despite the warning):
https://paste.opensuse.org/pastes/8bcb9d2ecfdf
Btw: My terminal seems fine with displaying the CP850 high ascii
characters (despite the warning):
https://paste.opensuse.org/pastes/8bcb9d2ecfdf
Looks like your luit doesn't support CP850 or you don't have en_US.CP850. There are some encodings which luit list, but doesn't support actually. For
example, mine lists CP866, but doesn't work with it.
Does it present in `locale -a` output?
Have you tried to run that script without luit? You don't even need to change locale for it - just encoding in terminal.
Btw: My terminal seems fine with displaying the CP850 high
ascii characters (despite the warning):
https://paste.opensuse.org/pastes/8bcb9d2ecfdf
Looks like your luit doesn't support CP850 or you don't have
en_US.CP850. There are some encodings which luit list, but
doesn't support actually. For example, mine lists CP866, but
doesn't work with it.
Does it present in `locale -a` output?
I don't know if that says much, because mostly there are just the
xx_XX and xx_XX.utf8 versions of the encodings. To give you a sample:
# locale -a | grep en_
Does this mean there is just an utf8 charset and an unspecified one
for almost every language-country? That doesn't seem logical!
Doesn't this show you what encodings luit supports:
# luit -list
Known locale encodings:
C: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
POSIX: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
US-ASCII: GL -> G0, GR -> G2, G0: ASCII, G2: ISO 8859-1
...
CP850: GL -> G0, GR -> G2, G0: ASCII, G2: CP 850
...
Known charsets (not all may be available):
ISO 646 (1973) (ISO 2022, 94 codes)
ASCII (ISO 2022, 94 codes)
...
CP 437 (128 codes)
CP 850 (128 codes)
CP 852 (128 codes)
...
So luit seems to know about CP850...
Have you tried to run that script without luit? You don't even
need to change locale for it - just encoding in terminal.
https://paste.opensuse.org/pastes/574e349fadaf
So without luit it doesn't display anything useful. With luit,
although you get the warning, it does display the right characters for CP850 !?
You need to install or generate this locale and GoldEd will show those letters! What Linux distribution do you use?
Do you need help with locale generation?
You need to install or generate this locale and GoldEd will show
those letters! What Linux distribution do you use?
wilnux5:/etc # cat os-release
NAME="openSUSE Leap"
VERSION="42.1"
VERSION_ID="42.1"
PRETTY_NAME="openSUSE Leap 42.1 (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:42.1" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://opensuse.org/"
ID_LIKE="suse"
(Yes, it's old ;-))
Do you need help with locale generation?
I think I found out how to do this on my system.
First I used my systems package manager to install: "glibc-i18ndata - Database Sources for 'locale'"
Afterwards this command ran without any output:
# localedef --no-archive -f IBM850 -i en_US en_US.CP850
#
And this directory was created with contents:
/usr/lib/locale/en_US.cp850
And 'locale -a -v' now shows:
...
locale: en_US directory: /usr/lib/locale/en_US ---------------------------------------------------------------------- ---------
title | English locale for the USA
source | Free Software Foundation, Inc.
address | http://www.gnu.org/software/libc/
email | bug-glibc-locales@gnu.org
language | English
territory | USA
revision | 1.0
date | 2000-06-24
codeset | ISO-8859-1
locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850 ---------------------------------------------------------------------- ---------
title | English locale for the USA
source | Free Software Foundation, Inc.
address | http://www.gnu.org/software/libc/
email | bug-glibc-locales@gnu.org
language | English
territory | USA
revision | 1.0
date | 2000-06-24
codeset | IBM850
...
But golded output is borked now, in my current utf-8 configured putty terminal:
https://paste.opensuse.org/pastes/2a5c7f2fbdc4
It doesn't matter if I use luit or not, they are displayed the same.
Also the ~A characters for messages with CHRS: CP437 in the german
areas are still there.
And this is still the same:
https://paste.opensuse.org/pastes/f3961b7ea085
PRETTY_NAME="openSUSE Leap 42.1 (x86_64)"
(Yes, it's old ;-))
Got it. Not too old for FidoNet. :)
locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850
This is what you need. Good.
But golded output is borked now, in my current utf-8 configured putty
terminal:
https://paste.opensuse.org/pastes/2a5c7f2fbdc4
This is exactly how I saw it on my computer, when was using pseudo-graphics
with wrong or missing locale.
It doesn't matter if I use luit or not, they are displayed the same.
Also the ~A characters for messages with CHRS: CP437 in the german
areas are still there.
And this is still the same:
https://paste.opensuse.org/pastes/f3961b7ea085
This looks like locale is not used. I saw such pictures when Strange.
Do you use latest GoldEd build?
Do you still run it with LANG=en_US.cp850?
In some message I saw en_EN.CP850.
Could you also run:
LANG=en_US.cp850 locale
locale: en_US.cp850 directory: /usr/lib/locale/en_US.cp850
This is what you need. Good.
But golded output is borked now, in my current utf-8 configured
putty
terminal:
https://paste.opensuse.org/pastes/2a5c7f2fbdc4
This is exactly how I saw it on my computer, when was usingThe locale is there, so is it wrong?
pseudo-graphics with wrong or missing locale.
It doesn't matter if I use luit or not, they are displayed the
same. Also the ~A characters for messages with CHRS: CP437 in
the german areas are still there.
And this is still the same:
https://paste.opensuse.org/pastes/f3961b7ea085
This looks like locale is not used. I saw such pictures when
Strange.
Do you use latest GoldEd build?
Almost. I'm using this one:
commit 4b6c754756d0fa96c0c3210d6ed0b63d49ec8e6a
Author: Vitaliy Aksyonov <18148062+vitaliy-aksyonov@users.noreply.github.com>
Date: Wed Mar 6 13:38:52 2024 -0700
call setlocale() before initscr() (#86)
See section Initialization in man 3 ncurses.
https://www.man7.org/linux/man-pages/man3/ncurses.3x.html
Locale shall be initialized before ncurses initialization.
The latest one doesn't seem so change anything regarding screen
output.
Do you still run it with LANG=en_US.cp850?Yes.
In some message I saw en_EN.CP850.
The localdef command, created the directory with lowercase 'cp850' although I specified it with uppercase 'CP850'. It also shows it with lowercase 'cp' when locale -a is executed. So I switched to specifying
it as lowercase in my golded start script. But case probably doesn't matter.
^^^^^Could you also run:
LANG=en_US.cp850 locale
Here are some tries:
wilnux5:/home/fido/log # locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="POSIX"^^^^^^^
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
This is exactly how I saw it on my computer, when was using
pseudo-graphics with wrong or missing locale.
The locale is there, so is it wrong?
I have no idea. It looks correct. But output looks like ncurses uses incorrect
locale.
It doesn't matter if I use luit or not, they are displayed the
same. Also the ~A characters for messages with CHRS: CP437 in
the german areas are still there.
Remind me. Do you have XLAT conversion table from cp437 to cp850?
In some message I saw en_EN.CP850.
The localdef command, created the directory with lowercase 'cp850'
although I specified it with uppercase 'CP850'. It also shows it
with
lowercase 'cp' when locale -a is executed. So I switched to specifying
it as lowercase in my golded start script. But case probably doesn't
matter.
No, I mean that i saw you using en_*EN*.cp850, not en_*US*.cp850. That is important.
wilnux5:/home/fido/log # locale^^^^^
LANG=POSIX
LC_CTYPE=en_US.UTF-8
This is not correct
Make sure that all LC_-s are en_US.cp850. Especially LC_CTYPE.
Make sure that all LC_-s are en_US.cp850. Especially LC_CTYPE.
Ok that did the trick! Just setting LC_CTYPE=en_US.cp850 is enough. So now I have the following line for starting golded:
sudo -u fido LC_CTYPE=en_US.cp850 luit -encoding 'CP850' /usr/local/bin/golded -f
The linedrawing characters, and the german characters (with @CHRS:
CP437) are ok too!
So this:
# sudo -u fido LC_CTYPE=en_US.cp850 locale
LANG=POSIX
LC_CTYPE=en_US.cp850
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
Seems enough to get the right output from golded!?
Ok that did the trick! Just setting LC_CTYPE=en_US.cp850 is enough.
So now I have the following line for starting golded:
Great! Glad to help.
# sudo -u fido LC_CTYPE=en_US.cp850 locale
LANG=POSIX
LC_CTYPE=en_US.cp850
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
Seems enough to get the right output from golded!?
Other LCs are pretty much not used in GoldEd, shall be fine for your case.
On to the next issues... ;-)
I notice in my putty terminal that alignment of the columns in the area listing is off when there are unread messages in the areas:
https://paste.opensuse.org/pastes/1b0a6ac1a41e
This might not be new, and already happening before I started changing/fixing
my code page issues. I'll check later if this also happens in my local konsole
terminal.
Also the header with the number of messages on the message reader
screen is sometimes missing a space between the first number and
'of', when I go directly to a message from the area messages listing.
https://paste.opensuse.org/pastes/80901e9650d8
Could this be related to the above issue?
On to the next issues... ;-)
I notice in my putty terminal that alignment of the columns in
the area listing is off when there are unread messages in the
areas:
https://paste.opensuse.org/pastes/1b0a6ac1a41e
This might not be new, and already happening before I started
changing/fixing my code page issues. I'll check later if this
also happens in my local konsole terminal.
In my local konsole it's fine. There is a '>' character after the 0 on lines for areas where there is new mail.
Also the header with the number of messages on the message
reader screen is sometimes missing a space between the first
number and 'of', when I go directly to a message from the area
messages listing.
https://paste.opensuse.org/pastes/80901e9650d8
Could this be related to the above issue?
I don't see this happening in my local konsole terminal either.
This probably means I have to play with my putty settings (again)...
:-/ ;-)
In my local konsole it's fine. There is a '>' character after the 0
on lines for areas where there is new mail.
Interesting. I assume you use luit with same configuration/locale in local console and putty?
Also the header with the number of messages on the message
reader screen is sometimes missing a space between the first
number and 'of', when I go directly to a message from the area
messages listing.
https://paste.opensuse.org/pastes/80901e9650d8
Could this be related to the above issue?
I don't see this happening in my local konsole terminal either.
This probably means I have to play with my putty settings (again)...
:-/ ;-)
You full of surprises! :) Just kidding.
It may be lost in so many layers you use... I'd suggest to check if
putty and local console use same/different TERM.
echo $TERM
Also the header with the number of messages on the message
reader screen is sometimes missing a space between the first
number and 'of', when I go directly to a message from the area
messages listing.
https://paste.opensuse.org/pastes/80901e9650d8
Could this be related to the above issue?
I don't see this happening in my local konsole terminal either.
This probably means I have to play with my putty settings
(again)...
:-/ ;-)
You full of surprises! :) Just kidding.
Well it helped! I switched to the $TERM=putty-256color settings we discussed before, and now all is well!
It may be lost in so many layers you use... I'd suggest to check
if putty and local console use same/different TERM.
echo $TERM
Is is 'xterm' in my local konsole, and was 'linux' but now 'putty-256color' in my putty terminal.
Well it helped! I switched to the $TERM=putty-256color settings we
discussed before, and now all is well!
Great. Looks like some question need to be saved in FAQ. I only never saw English version of it.
echo $TERM
Is is 'xterm' in my local konsole, and was 'linux' but now
'putty-256color' in my putty terminal.
256color make console very different in other programs too.
Well it helped! I switched to the $TERM=putty-256color settings
we discussed before, and now all is well!
Great. Looks like some question need to be saved in FAQ. I onlyI don't think it exists.
never saw English version of it.
echo $TERM
Is is 'xterm' in my local konsole, and was 'linux' but now
'putty-256color' in my putty terminal.
256color make console very different in other programs too.
I haven't tested the regular TERM=putty, but compared to TERM=linux, Midnight Commander looks the same. But my own ncurses program (configuration program for FMail tosser), looks ok now too!
https://paste.opensuse.org/pastes/c77fdc8fd4af
In the background how it looks with 'putty-256color' and how it is supposed to look. In the forground how it looks if TERM=linux.
256color make console very different in other programs too.
I haven't tested the regular TERM=putty, but compared to TERM=linux,
Midnight Commander looks the same. But my own ncurses program
(configuration program for FMail tosser), looks ok now too!
https://paste.opensuse.org/pastes/c77fdc8fd4af
In the background how it looks with 'putty-256color' and how it is
supposed to look. In the forground how it looks if TERM=linux.
ncurses uses terminfo and `linux` not the best for Putty. `xterm` may work,
but `putty` or `putty-256color` is the best for sure.
| Sysop: | Luis Silva |
|---|---|
| Location: | Lisbon |
| Users: | 763 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 168:16:29 |
| Calls: | 111 |
| Files: | 46,971 |
| Messages: | 11,189 |
