I made another patch slowly moving to rework charsets recoding and
iconv.
I'd appreciate if someone may build it from branch 'Aliases' and try to navigate your messages and write new messages.
Especially if you have xlatcharsetalias entries in your config.
https://github.com/golded-plus/golded-plus/tree/Aliases
--- GoldED+/LNX 1.1.5-b20231030
I made another patch slowly moving to rework charsets recoding
and iconv.
I'd appreciate if someone may build it from branch 'Aliases' and
try to navigate your messages and write new messages.
I'm using it now. It seems to work just as well as my previous version GED+LNX 1.1.5-b20240209, from 'master', in my current config.
Especially if you have xlatcharsetalias entries in your config.
I don't use any of those though...
https://github.com/golded-plus/golded-plus/tree/Aliases
--- GoldED+/LNX 1.1.5-b20231030
You're not using it yourself? ;-)
Especially if you have xlatcharsetalias entries in your config.
I don't use any of those though...
But you have xlatcharset in your config. That was changed too.
I don't have any in my standard configuration. But if I include
charsets.cfg from the project. All messages in the stats area with
linedrawing characters don't look ok. But that's the same in the
previous version of golded that I was using.
If you don't have any - pseudo-graphics won't work unless you have console in same encoding as message.
Because GoldEd will only do charset translations if you have it configured.
Otherwise it just prints message as is. And codes for pseudo-graphics is different in cp437 (message charset) and utf-8 (your terminal charset).
When you have charsets configured - there is another issue. GoldEd may convert from one byte encodings like cp437 to utf-8, but can't convert it back from utf-8 to cp437. I'm working on that. Have no idea, how much time it may take though.
On Tue, 27 Feb 2024 12:59:54 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:
This is why I wonder if he has a cp437 terminal setup, and this
is why these messages look fine to him. Whereas, I'm using a
utf-8 terminal so I have to translate everything to look ok.
Yes. You need to use translation in this case. The problem is
that GoldEd may translate from one byte charset to UTF-8, but not
in reverse direction yet. That mean that you'll be able to read
messages, but not write them. Actually, you'll be able to write
them if no symbols with codes > 127 are used. But CHRS kludge in
message will look like UTF-8 2.
Yes, I've known this for quite some time. And my current issue has to
do with reading messages (the one we've been using as an example) specifically translated from cp437 to utf-8.
Otherwise, if I absolutely have to reply to a message containing cp437 characters, I just don't quote those - as I know they won't be
translated properly.
I didn't mention this before, but there are some linker warnings:
../goldlib/uulib/libuulib.a(uunconc.cpp.o): In function `UUDecode(_uulist*)': uunconc.cpp:(.text+0x34e2): warning: the use of `tempnam' is dangerous, better use
`mkstemp' CMakeFiles/golded.dir/gedoit.cpp.o: In function `WriteMsgs(GMsg*)': gedoit.cpp:(.text+0xa51): warning: the use of `mktemp' is dangerous, better use `mkstemp'
They should be easy to address.
I switched back to the master branch because this patch was merged. Of course there are no changes in its operation for me.
I didn't mention this before, but there are some linker warnings:
../goldlib/uulib/libuulib.a(uunconc.cpp.o): In function
`UUDecode(_uulist*)': uunconc.cpp:(.text+0x34e2): warning: the use of
`tempnam' is dangerous, better use
`mkstemp' CMakeFiles/golded.dir/gedoit.cpp.o: In function
`WriteMsgs(GMsg*)': gedoit.cpp:(.text+0xa51): warning: the use of
`mktemp' is dangerous, better use `mkstemp'
They should be easy to address.
I've seen those. I'm not sure that mkstemp is available in all systems GoldEd is possible to build.
I switched back to the master branch because this patch was merged.
Of course there are no changes in its operation for me.
So everything from the "Aliases" branch has been merged into master now?
Unless Vitaliy is going to continue doing things there for testing, I
may as well delete that install (I installed it separately as to not
mess up what is actually working for me).
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.
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.
If you don't have any - pseudo-graphics won't work unless you
have console in same encoding as message.
This is why I wonder if he has a cp437 terminal setup, and this is why these messages look fine to him. Whereas, I'm using a utf-8 terminal
so I have to translate everything to look ok.
I made another patch slowly moving to rework charsets recoding
and iconv.
I'd appreciate if someone may build it from branch 'Aliases' and
try to navigate your messages and write new messages.
Especially if you have xlatcharsetalias entries in your config.
https://github.com/golded-plus/golded-plus/tree/Aliases
When adding this patch does Golded need to be compiled with iconv
support (ICONV=1)?
I would imagine Wilfred wouldn't see anything different if he's not
using any kind of character translations. But if one uses charsets.cfg this would be a good test for you.
This is why I wonder if he has a cp437 terminal setup, and this is why
these messages look fine to him. Whereas, I'm using a utf-8 terminal
so I have to translate everything to look ok.
Yes. You need to use translation in this case. The problem is that
GoldEd may translate from one byte charset to UTF-8, but not in reverse direction yet. That mean that you'll be able to read messages, but not write them. Actually, you'll be able to write them if no symbols with codes > 127 are used. But CHRS kludge in message will look like UTF-8 2.
Yes. He shall not see any difference. And if he does - it mean I have
a bug in my code. That's why I want as many people with different
settings as possible to try it.
I made another patch slowly moving to rework charsets recoding
and iconv.
I'd appreciate if someone may build it from branch 'Aliases' and
try to navigate your messages and write new messages.
I'm using it now. It seems to work just as well as my previous
version GED+LNX 1.1.5-b20240209, from 'master', in my current config.
Sounds good. Thanks.
I played with your configuration and have a good and bad news for you.
Good:
- I reproduced your issue.
- GoldEd correctly converts pseudo-graphics from cp437 to utf-8.
Bad:
- GoldEd does not support unicode. Even if you compile it with ncursesw, it still uses non unicode versions of functions to print text. That's
why you see those escape sequences instead of pseudo-graphics symbols.
I still suggest you to use one-byte locale for GoldEd. And remember, you don't need to switch whole system to that locale, because in Linux
locale is a property of a process. So you may have UTF-8 everywhere and cp437 for GoldEd. Most of terminals (including Putty) support different charsets.
Another option - is to use external editor, but that won't help you with message reader.
Especially if you have xlatcharsetalias entries in your config.
I don't use any of those though...
But you have xlatcharset in your config. That was changed too.
I don't have any in my standard configuration. But if I include charsets.cfg from the project. All messages in the stats area with linedrawing characters don't look ok. But that's the same in the
previous version of golded that I was using.
Hello Wilfred.
23 Feb 24 16:31, you wrote to me:
If you don't have any - pseudo-graphics won't work unless you have console in same encoding as message.
I made another patch slowly moving to rework charsets recoding and iconv.
I'd appreciate if someone may build it from branch 'Aliases' and try to navigate your messages and write new messages.
Especially if you have xlatcharsetalias entries in your config.
https://github.com/golded-plus/golded-plus/tree/Aliases
I played with your configuration and have a good and bad news for
you.
Good:
- I reproduced your issue.
- GoldEd correctly converts pseudo-graphics from cp437 to utf-8.
Well, it did. Until you reverted those changes. :(
Bad:
- GoldEd does not support unicode. Even if you compile it with
ncursesw, it still uses non unicode versions of functions to
print text. That's why you see those escape sequences instead of
pseudo-graphics symbols.
Something happened recently where it made it quite a bit worse. I was reading utf-8 Cyrillic, Greek, Japanese, Chinese, etc just fine in
Golded until the most recent version.
What changed with the ncurses init that was reverted?
And why does that change affect me opposite of a cp437 locale user?
If all I'm doing is translating from cp437 to utf-8 (or anything to
utf-8) I should still be able to read it properly, as I have been..
until recently. Whatever you were doing with ncurses init helped me. I
was able to read utf-8 messages perfectly fine. Almost every single
"Merry Christmas" or "Happy New Year" Michiel posts yearly (except
maybe a 2 or 3) were perfectly readable in Golded. The latest version
they are not.
I still suggest you to use one-byte locale for GoldEd. And
remember, you don't need to switch whole system to that locale,
because in Linux locale is a property of a process. So you may
have UTF-8 everywhere and cp437 for GoldEd. Most of terminals
(including Putty) support different charsets.
I'll pass on the suggestion :). I'll just keep using the last version
that worked for me (minus a couple badly displayed ascii line
characters, and keep testing newer versions to see if I ever get the display back that I lost. :)
Another option - is to use external editor, but that won't help
you with message reader.
I already do this (I have always used nano with Golded). Viewing and writing in an external editor has never been a problem. Until
recently, only reading became an issue. So the whole time it was
working for me you actually broke something instead? :((
I switched back to the master branch because this patch wasSo everything from the "Aliases" branch has been merged into master
merged. Of course there are no changes in its operation for me.
now? Unless Vitaliy is going to continue doing things there for
testing, I may as well delete that install (I installed it separately
as to not mess up what is actually working for me).
I didn't mention this before, but there are some linker
warnings:
../goldlib/uulib/libuulib.a(uunconc.cpp.o): In function
`UUDecode(_uulist*)': uunconc.cpp:(.text+0x34e2): warning: the
use of `tempnam' is dangerous, better use `mkstemp'
CMakeFiles/golded.dir/gedoit.cpp.o: In function
`WriteMsgs(GMsg*)': gedoit.cpp:(.text+0xa51): warning: the use
of `mktemp' is dangerous, better use `mkstemp'
They should be easy to address.
I've seen those. I'm not sure that mkstemp is available in all
systems GoldEd is possible to build.
mkstemp() is: 4.3BSD, POSIX.1-2001
If not available you could make your own from mktemp() and open() I suppose. I could find atleast 1 example on the net...
Most probably it was some combination which made it looking almost correct. I think that screen may be the reason you saw pseudo-graphics
more or less correctly. Remember those line wraps? That happens
because GoldEd converts those symbols to UTF-8 first. All
pseudo-graphics symbols represented as 3 bytes. So that line become 3 times longer in bytes. Then GoldEd tries to split message to lines and
it uses bytes! not symbols. That's why it splits the line in the
middle of those pseudo-graphics. Even worse, it may tear apart one
UTF-8 symbol to two lines and it will be displayed incorrectly.
GoldEd cannot work correctly with multibyte sequences. And even if it looks "correct", it's just because most English letters has same codes
in cp437 and UTF-8.
If you want to keep using UTF-8, I may only suggest to find version,
which "works" for you and stick to it.
Until full UTF-8 support implemented in GoldEd (if that ever happen), don't expect it to work correctly, sorry.
It's your choice. Just be aware, that if it works - it's just pure
luck and don't expect it to last. Until we implement UTF-8 support. It
may take years. Or never happen. It's not so easy to do it with
backward compatibility wih all older systems like DOS or OS/2.
Most probably it was some combination which made it looking
almost correct. I think that screen may be the reason you saw
pseudo-graphics
I'm no longer using screen or tmux, and this version (along with all previous versions since you made the ncurses change) work the same and show UTF-8 properly, except for what you describe below:
more or less correctly. Remember those line wraps? That happens
because GoldEd converts those symbols to UTF-8 first. All
pseudo-graphics symbols represented as 3 bytes. So that line
become 3 times longer in bytes. Then GoldEd tries to split
message to lines and it uses bytes! not symbols. That's why it
splits the line in the middle of those pseudo-graphics. Even
worse, it may tear apart one UTF-8 symbol to two lines and it
will be displayed incorrectly.
Yeah, I've noticed most of this.. and thank you for your explanation.
At least now I know why it is happening.
GoldEd cannot work correctly with multibyte sequences. And even
if it looks "correct", it's just because most English letters has
same codes in cp437 and UTF-8.
Maybe simple ones, like german umlauts and whatnot. But cp437 doesn't
have any Cyrillic, Greek, Japanese, Chinese, etc.
If you want to keep using UTF-8, I may only suggest to find
version, which "works" for you and stick to it.
I already have!
Until full UTF-8 support implemented in GoldEd (if that ever
happen), don't expect it to work correctly, sorry.
That's ok. I had it somewhat working for awhile, the latest reverts
have changed that. I don't have an issue going back to a "lucky"
version. ;)
It's your choice. Just be aware, that if it works - it's just
pure luck and don't expect it to last. Until we implement UTF-8
support. It may take years. Or never happen. It's not so easy to
do it with backward compatibility wih all older systems like DOS
or OS/2.
I don't mind being lucky sometimes.
I played little bit more with the code and different settings and found what was the difference between those two versions.
First - you use "wide" ncurses - ncursesw. I use ncurses.
Second. GoldEd incorrectly initializes ncurses in reverted version (like it was before I started to make any changes in GoldEd code). ncurses documentation explicitly says that before call initscr(), locale has to
be set with setlocale. Otherwise it will use incorrect settings. Most probably plain C locale. I kinda get picture very similar to yours.
Did you have an issue with non-English chars when scrolling the message?
What I see in UFT-8 terminal now - most of unicode text displayed correctly and pseudo-graphic too. Only pseudo-graphics lines broken similar to yours. And when I scroll text down - it corrupts.
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 that gives you expected result - I'll push this change to master.
Hope you still want to dig this. :)
As for the pseudo-graphics wrapped to the next line, I have a
(probably dumb) question about this: If the pseudo graphics were originally cp437 (single byte) and translated to utf-8, once they are translated are they now multiple bytes per character?
If "UTF-8 uses 1 to 4 bytes to encode a single character", I guess
what I'm wondering is if the character was 1 byte to begin with, why wouldn't it stay 1 byte when translated to utf-8? Or is it because
those _specific_ characters when in utf-8 are already multiple bytes?
So, at this point it's basically working and displaying properly, but
then comes in the 'characters' vs 'bytes' thing that Golded isn't supporting, so it is wrapping what it thinks is double, triple, or
even quadruple the amount of 'characters' that are there.
Thank you for the explanation. This definitely helps me to understand
what is happening.
Thanks for the explanation. While reading this, I did check the ASCII table and the characters I'm referring to are all above 127. This also
is kind of reflected while using Golded, if I widen my screen more
than 160 characters, less of those lines are wrapped to the next line.
However, it doesn't seem like I can widen my window enough to keep
them all on one line, so I'm guessing when they are translated to
utf-8 they are more than 2 bytes, since I'm well over double the width
of an 80 character screen - which the original stat message was made
for.
So, at this point it's basically working and displaying properly, but
then comes in the 'characters' vs 'bytes' thing that Golded isn't supporting, so it is wrapping what it thinks is double, triple, or
even quadruple the amount of 'characters' that are there.
Thank you for the explanation. This definitely helps me to understand
what is happening.
So, at this point it's basically working and displaying properly,
but then comes in the 'characters' vs 'bytes' thing that Golded
isn't supporting, so it is wrapping what it thinks is double,
triple, or even quadruple the amount of 'characters' that are
there.
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. :)
Unicode is very complex. It's event worse than you may think. For
example, some displayed symbols take one char space on screen, but
others two. Also one letter is not necessarily one Unicode "symbol".
Also it may have non-printable symbols and many more.
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.
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.
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 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.
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
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.
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, "");
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().
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.
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...
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: | Nitro |
|---|---|
| Location: | Portland, OR |
| Users: | 3 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 10:57:35 |
| Calls: | 136 |
| Files: | 751 |
| Messages: | 89,488 |
