Hello All,
The latest commits that were removed (more than likely the one that
had to do with ncurses) has caused me some issues with my current
config.
I have a few screenshots for comparisons..
Second, a screenshot of the same message viewed in Golded either
screen and/or tmux (I don't remember which one exactly, because the issue(s) caused me to try out a couple different terminal multiplexors
to make sure it wasn't specific to any of those - which it wasn't).
This was Golded BEFORE the removal of the commits. As you can see,
line drawing characters are indeed present; but some of them wrap
wrong, etc:
https://pharcyde.org/ss2.png
Third, a screenshot of Golded AFTER the removal of the commits. Mind
you, this isn't the exact same message in the two screenshots above,
but they all display the same as this one - I just took the screenshot
on a different day:
https://pharcyde.org/golded-cp437.png
For all three instances, I'm using:
include [pathTo]/golded-plus/cfgs/config/charsets.cfg
xlatimport cp437
xlatexport utf-8
xlatlocalset utf-8
charsets.cfg is included with Golded sources (if one was wondering and didn't already know), utilizing all translation tables available.
I'm not sure what has changed or what I can do to make it better. Any suggestions? Thank you in advance!
First of all - thanks for feedback. That change I made shouldn't be a reason of this behavior. Let's try to find what may be wrong.
Have you tried to run it in terminal without screen multiplexors? I had an issue with screen on my system, don't remember if I tried tmux with golded.
Golded doesn't work well with multibyte encodings like UTF-8. Last screenshot looks like text recoding issue to me.
Is there anything in golded.log?
Have you tried to use one byte local charset? Like cp437.
What OS do you have? Do you build golded yourself? Do you use cmake or make?
First of all - thanks for feedback. That change I made shouldn't
be a reason of this behavior. Let's try to find what may be
wrong.
Ok. Then with that said, I also realized I seem to have an enormous
amount of warnings while compiling. Maybe because of a recent gcc
update? Or are all these warnings normal?
$ gcc --version
gcc (GCC) 13.2.1 20230801
.. and the actual package is gcc-13.2.1-5 from Archlinux.
Have you tried to run it in terminal without screen multiplexors?
I had an issue with screen on my system, don't remember if I
tried tmux with golded.
Yes I have. It's the same, if not worse. While using golded in a utf-8 linux console (no X), accessed via PuTTY (also setup for utf-8) over
ssh, and not using a multiplexor, all of the line drawing characters
on the main loading screen, the area list, and while reading messages
are replaced by the letter "q". The multiplexor (in my current case,
tmux) fixes that and displays the screens correctly.
I have too many things in play here to narrow it down, it seems. I
just asked because I hadn't changed anything in quite some time and
how things were displayed has changed since the latest
update/rollback.
Golded doesn't work well with multibyte encodings like UTF-8.
Last screenshot looks like text recoding issue to me. Is there
anything in golded.log?
No. golded.log has been 0 bytes for quite some time now. Is that
normal?
Golded has had it's issues with utf-8, but it was far better than it
is now. At least the lines and graphs were drawn at one point, even
though sometimes not in the correct location or some were moved to the next line.
Have you tried to use one byte local charset? Like cp437.
Yes, but since nothing here locally is actually setup for cp437 unless
I use some other 3rd party program or reconfigure PuTTY, it doesn't display right either.
What OS do you have? Do you build golded yourself? Do you use
cmake or make?
Archlinux 64bit. Yes I build golded myself, with make. I will keep
messing with my settings and see if I can come up with anything
better. I just figured I'd ask here as maybe someone else has
experienced something similar.
The latest commits that were removed (more than likely the one that
had to do with ncurses) has caused me some issues with my current
config.
I'm not sure what has changed or what I can do to make it better. Any suggestions? Thank you in advance!
Yes I have. It's the same, if not worse. While using golded in a utf-8 linux console (no X), accessed via PuTTY (also setup for utf-8) over
ssh, and not using a multiplexor, all of the line drawing characters
on the main loading screen, the area list, and while reading messages
are replaced by the letter "q". The multiplexor (in my current case,
tmux) fixes that and displays the screens correctly.
Sometimes (going through messages) "Subject" is scrambled.
For example - that thread:
Usualy I see "Latest sources.."
but from some replies I see "Latest ses..es.."
I have that since ever...
Does anybody have that as well?
Does anybody have that as well?
Yes, i get that to when a subject starts with Re:
I'm not sure what is happening there.
Those warnings are "normal". In terms like they better be fixed, by they are expected especially in new compiler. They mostly safe and you may ignore them.
Do you use following parameters when build it:
USE_NCURSES
WIDE_NCURSES
BUGGY_NCURSES
And which ncurses library version do you have?
That is interesting. It shall work totally fine without screen multiplexor.
Would be interesting to understand how screen or tmux makes a difference.
BTW, what do you have for $TERM env variable?
My last commit rollback some change I made previously because it was found to be buggy in some cases. So it could be some other change actually.
If you familiar with git, would be nice if you hunt down which commit makes
things worse in your setup. You may use git bisect for that.
https://git-scm.com/docs/git-bisect
It is very good actually. Golded writes errors in that file and if it empty
- it's a good sign.
Moved to next line is OK. It's just for messages, which has lines longer than your terminal width.
To use cp437 you need to change Putty config for sure. And I'd recommend you to use one byte locale for golded if you don't need many different encodings. That will solve many issues for you right away.
Some people do experience issues like you. And would be really great to find and fix root cause.
Could you also try to remove file goldxlat.gel? Golded will generate it on start.
That "q" reference sounded familiar. I found a setting in putty that mentions this:
https://paste.opensuse.org/pastes/6fc707014110
Btw: With these settings your messsages look OK in putty. But now my 'mc' linedrawing characters look totally borked. When I set putty to use utf-8,
'mc' looks ok, but your messages in golded look like this:
https://paste.opensuse.org/pastes/13f114dba16c
Not as it should be, but usable...
It is pitty...
My last commit rollback some change I made previously because it was found to be buggy in some cases. So it could be some other change actually.
If you familiar with git, would be nice if you hunt down which commit makes
things worse in your setup. You may use git bisect for that.
https://git-scm.com/docs/git-bisect
Would be interesting to understand how screen or tmux makes a
difference.
It wasn't much, it just displayed the above mentioned things correctly without any additional PuTTY settings.
BTW, what do you have for $TERM env variable?
TERM="xterm"
Moved to next line is OK. It's just for messages, which has lines
longer than your terminal width.
Is there a way to change the line length in Golded? If it is set for something like 78 by default, maybe changing it to 79 would help as it could be one extra character that's causing it to wrap to the next
line. Although, I don't know how replies and quotes coming from here
would look on others' systems then.. I'd rather break things on my
end, not others. :)
To use cp437 you need to change Putty config for sure. And I'd
recommend you to use one byte locale for golded if you don't need
many different encodings. That will solve many issues for you
right away.
Honestly, I have no interest in using CP437 in a terminal. I don't
mind some irregularities, but this time there were just more than
usual.
I don't like things easy. For some reason I enjoy making things
extremely difficult for myself.
Some people do experience issues like you. And would be really
great to find and fix root cause.
I agree! Then again, if/when you get iconv working properly I think
many of these issues will probably disappear since iconv > old crusty translation tables.
Could you also try to remove file goldxlat.gel? Golded will
generate it on start.
I did, and it didn't change anything. I'll use 'git bisect' and see if
I can figure out if a recent commit changes it back to the way it was.
My last commit rollback some change I made previously because it
was found to be buggy in some cases. So it could be some other
change actually.
If you familiar with git, would be nice if you hunt down which
commit makes things worse in your setup. You may use git bisect
for that.
https://git-scm.com/docs/git-bisect
I'm not very familiar with it, but I was able to figure it out with
the link you provided. Thank you!
$ git bisect start
$ git bisect bad
$ git bisect good f7be1e97e251ee2be20f63abdcf2a18f93c880b9
I chose this commit because it was just prior to the 'revert "zero conversion" workaround', where things were definitely looking more
towards 'normal'.
$ make BUILD=minimal (this compiled version 20231112 for some reason I don't yet understand)
It was back to normal with this compile.
$ git bisect good
$ make BUILD=minimal (this compiled version 20240206)
It was still good.
$ git bisect good
https://pharcyde.org/git-bisect-result.png
It seems as though I'm back to the way it was in version GoldED+/LNX 1.1.5-b20240206. Here is an example:
https://pharcyde.org/golded-20240206.png
$ git bisect reset (to go back to the master branch 20240209)
$ make BUILD=minimal
https://pharcyde.org/golded-20240209.png
Same configuration in golded.conf:
[ start paste ]
# Character translation path
xlatpath /home/axisd/src/golded-plus/cfgs/charset
include /home/axisd/src/golded-plus/cfgs/config/charsets.cfg
# UTF-8 Configuration
#
xlatcharset utf-8 utf-8 utf_utf.chs
xlatimport cp437
xlatexport utf-8
xlatlocalset utf-8
[ end paste ]
For bisect you better chose wider range. Like a year or so. With bisect you
only need ln(N) tries to find broken commit. It could be broken earlier actually.
You have xlatimport cp437.
Does that message with broken pseudo-graphics have CHRS kludge? If not - is
it really in cp437 encoding? Pseudo-graphics characters located in second half of charset table and it's different for different charsets.
Just make your terminal wider and then start golded. It will use whole window width unless you use "Dispmargin" parameter in your config. As for quotes, they will be broken down to "Quotemargin" columns.
Sure. That's your choice. :) I just want to tell that GoldEd was designed to work with one byte encodings and UTF-8 may work incorrectly.
I'm working on some refactoring now in charset conversions now. When that is done, then iconv integration will be very simple.
Got it. What is weird, last commit fixed issue for one sysop and broken it for you.
Could you try to build from commit 372220588c6f17cd3f709dcb721a9144169d988c
? It was before all my changes. If it will have same behavior, then it's something wrong with setup on your side and we'll try to figure that out.
It is pitty...
It looks like the two of you that have this similar issue are using a
form of LATIN codepage (you with LATIN-2, and Al with LATIN-1). Just
an observation. Hope you figure it out!
It looks like the two of you that have this similar issue are using a
form of LATIN codepage (you with LATIN-2, and Al with LATIN-1). Just
an observation. Hope you figure it out!
I will try to get more data about that.
That "q" reference sounded familiar. I found a setting in putty that
mentions this:
https://paste.opensuse.org/pastes/6fc707014110
That doesn't seem to work very well for me.
Just make your terminal wider and then start golded. It will use
whole window width unless you use "Dispmargin" parameter in your
config. As for quotes, they will be broken down to "Quotemargin"
columns.
My terminal during that session is already 160 wide, so that's not the issue with the random wrapping of those characters, then.
Sure. That's your choice. :) I just want to tell that GoldEd was
designed to work with one byte encodings and UTF-8 may work
incorrectly.
Definitely understood. However, it worked _better_ before, and I'm
just trying to figure out what happened and why.
With that said, I'm not ruling out the possibility something was
actually "fixed" that broke my utf-8 hackery, either. :)
Got it. What is weird, last commit fixed issue for one sysop and
broken it for you.
Yes, I know. I've had some side discussions with Wilfred about this
exact issue. However, it seems he's using a bit more of a single-byte setup than I am. So, it's possible that he is doing less translation
from cp437 to utf-8 (as far as I know, he isn't using any xlat
settings whatsoever in golded.conf) .
Could you try to build from commit
372220588c6f17cd3f709dcb721a9144169d988c ? It was before all my
changes. If it will have same behavior, then it's something wrong
with setup on your side and we'll try to figure that out.
I can, but as I'm not super experienced with git, so I have some questions.
When I use 'git bisect' with these steps:
$ git bisect start
$ git bisect bad
$ git bisect good 372220588c6f17cd3f709dcb721a9144169d988c
I get this:
Bisecting: 29 revisions left to test after this (roughly 5 steps) [f535cc792abd5d254da57a2f5b70d5b02cbd7abf] Add github actions badge
This is a much later revision after quite a few of your changes, so
'git bisect' didn't seem to take me back as far as you wanted me to
go.. unless I'm doing something wrong.
I did see this after typing 'git bisect --help':
" Once you have specified at least one bad and one good commit, git
bisect selects a commit in the middle of that range of history, checks
it out, and outputs something similar to the following: "
So am I actually able to specify which commit I would like to go back
to with 'git bisect' or should I use 'git checkout'? If checkout is
the answer, I won't be able to keep track of good or bad commits any
more.
Hello Nicholas!
16 Feb 24 08:30, I wrote to you:
Symptom in Subject:
4 characters from position 13 copied to position 9
correct: 123456789ABCDEFGHIJKL
will look: 12345678DEFGDEFGHIJKL
(no matter if EDITREPLY is setup and how)
Happening if:
- If subject is longer than 16 characters (better to say, short ones can not see)
- CHRS is missing
- CHRS is one of: LATIN-1 2, UTF-8 2
-- but - not always
- where CHRS look ok: CP850 2, UTF-8 4
-- again - not always...
Karel
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Plast DATA (2:423/39)
So do you have terminal 160 chars wide, but message displayed narrower?
So how bisect works.
You start process with git bisect start as you already did.
First you mark some commit which is good for sure with git bisect good. Then mark "bad" commit with git bisect bad. That will be last commit in repo.
git will checkout commit in the middle of those two for you. Then you build
it and test. If it's good, run git bisect good, if it's bad, git bisect bad. Build it and test again.
So do you have terminal 160 chars wide, but message displayedYes, the message itself was created by a script and was only 78
narrower?
characters wide to begin with when it was created, and is posted to
the message base with 'hpt post'.
I just think that my utf-8 hackery may be moving some of those line drawing characters to the next line when it shouldn't be doing so.
Maybe there are some soft CRs in there I should be looking for (I
don't know how to spot those)?
So how bisect works.
You start process with git bisect start as you already did.
First you mark some commit which is good for sure with git bisect
good. Then mark "bad" commit with git bisect bad. That will be
last commit in repo. git will checkout commit in the middle of
those two for you. Then you build it and test. If it's good, run
git bisect good, if it's bad, git bisect bad. Build it and test
again.
That's how I understand it. However, you asked me to roll back to a specific version, and git bisect is not able to do that.
So without going that route, I can say ever since you've started
updating Golded I haven't had any display issues, until this latest version. What you seemed to have fixed for Wilfred, did the opposite
for me. :)
Then most probably it has 'soft CR'. You may dump message hex codes with 'I'.
If you just want to use specific commit, then use git checkout. If you want
to do binary search for broken commit - use git bisect interactively. Here's a tutorial, how to use it:
And that's is very strange. I'd not be surprised if it was broken when I made first change (which was reverted by last commit), but looks like it worked fine.
Then most probably it has 'soft CR'. You may dump message hex
codes with 'I'.
I assume I'm looking for 8D somewhere? If so, there are none in the
entire message.
I did notice a question mark in the message body:
00B0 C4 C4 C4 C4 C4 BF 20 C4 C4 C4 C4 C4 C4 C4 C4 C4 ?
But that's about it as far as anomolies.
If you just want to use specific commit, then use git checkout.
If you want to do binary search for broken commit - use git
bisect interactively. Here's a tutorial, how to use it:
I used checkout to get the specific commit you asked me to grab (372220588c6f17cd3f709dcb721a9144169d988c), and it is indeed exactly
how the latest version is. So you were right.
And that's is very strange. I'd not be surprised if it was broken
when I made first change (which was reverted by last commit), but
looks like it worked fine.
It did not. Whatever first change you made actually kind of helped me,
I suppose. Hopefully this helps narrow things down better and we can figure out what's going on.
Code 20 is a space. So wrapping caused by that.
Also check if you have DispMargin parameter in your config. If you do - comment it out or remove. Then GoldEd will use all window width.
You said that before you started to experiment - all worked fine. Have you used same compiler? Now I suspect that issue caused by something in your setup. Because it's quite opposite from others have.
That's why would be interesting to use bisect from 372220588c6f17cd3f709dcb721a9144169d988c to master and find specific commit
which made it bad in your specific case.
Your mail editor seems to insert an unnecessary utf-8 character, I can't read, in front of these quoted lines. :-(
Your mail editor seems to insert an unnecessary utf-8 character,
I can't read, in front of these quoted lines. :-(
I looked back on a few previous messages, and it seems to only add it
once the quote level gets to 3. (>>>). I will take a look, thanks!
I looked back on a few previous messages, and it seems to only
add it once the quote level gets to 3. (>>>). I will take a look,
thanks!
Also with level 2.
Thunderbird seems to replace some normal spaces by non-breaking spaces (UTF-8: C2 A0) in quotes. I intended to investigate this...
Also with level 2.
Code 20 is a space. So wrapping caused by that.I doubt it.
Also check if you have DispMargin parameter in your config. If
you do - comment it out or remove. Then GoldEd will use all
window width.
Most likely whatever the default settings is, since I don't use it in
my config.
You said that before you started to experiment - all worked fine.I said before that it has looked fine for quite some time. I didn't go back to the version you asked me too until I got the answer to use 'checkout' instead of 'bisect'. Now that I was able to go back that
Have you used same compiler? Now I suspect that issue caused by
something in your setup. Because it's quite opposite from others
have.
far, I was able to give you a better answer.
That's why would be interesting to use bisect from
372220588c6f17cd3f709dcb721a9144169d988c to master and find
specific commit which made it bad in your specific case.
I did this, sort of. Instead of bisect, I used checkout and tried
every version after 372220588* until I got to the one that changed the display.
8e9f3518ac9b3b32676e7b7563e92cc44e7b5ba7 is the commit that changes
things for the better in my case.
It stayed that way until you reverted the commit in the latest
version.
My only thoughts is that I am using PuTTY to connect with utf-8
settings to a utf-8 linux terminal. I include golded-plus/cfgs/config/charsets.cfg so I basically translate to and
from everything currently possible.
Maybe Wilfred had issues with this commit because he's not actually
using any xlat configuration? He had told me he's using some kind of
half and half utf-8/cp437 terminal and not using any xlat* settings in
his configuration. If he can view that stat screen I posted as well as view Michiel's tearline and origin line over in the UTF-8 echo during
the same golded session and no configuration changes, I would be surprised.
This is with 8e9f3518*:
https://pharcyde.org/golded-stats.png
https://pharcyde.org/golded-utf8.png
As you can see the only issue I seem to have with this version (and everything up till the 20240206 release) is a few line wraps on the
stat screen that shouldn't be happening - and I don't have a very extensive golded.conf where I could see anything in there that would
be causing that, except the translation tables themselves.
Default is to use whole window. Then it's weird, that line is broken.
That's something. Thanks for doing that.
Have you tried to run it in local terminal emulator? Do you have any GUI on
that computer?
Putty may be pain in the ass to configure correctly.
Would be cool if you may share your config and message base with message containing pseudo-graphics for me to play with. If I reproduce it internally - then I may find the cause very quickly! By config I mean not only golded.cfg, but all included files, including charset tables.
Sure. I will netmail you a link to the zip file. You will most likely have the directory structure in the config to make things work, but otherwise all pertinent information should be there.
Sure. I will netmail you a link to the zip file. You will most
likely have the directory structure in the config to make things
work, but otherwise all pertinent information should be there.
"You will most likely have *to change* the directory structure."
It was not a Golded bug, it was user error. ;)
Are you referring to having these issues with a version from 2018? If
so, I would suggest you upgrade to the latest version and see if you
have any of the same issues you have now.
Are you referring to having these issues with a version from 2018? If
so, I would suggest you upgrade to the latest version and see if you
have any of the same issues you have now.
Just did and same result (= same issues).
If that is the case, and you have the sources, try including 'golded-plus/cfgs/config/charsets.cfg' in your golded.conf and see if
that helps or not.
For that group I have:
GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP
If that is the case, and you have the sources, try including
'golded-plus/cfgs/config/charsets.cfg' in your golded.conf and
see if that helps or not.
Already have that since ever.
For that group I have:
GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP
Using UTF-8 in putty, having LANG=cs_CZ.utf8 in bash, startin golded:
luit -encoding 'ISO-8859-2' ./gedlnx -f
(because GROUP A we have ISO-8859-2 as agreed coding)
As I wrote, I have issue in GROUP B, GOLDED here...
For that group I have:
GROUP B
XLATPATH /home/fido/golded/xlat
XLATCHARSET CP437 LATIN-2 asc_il2.chs
XLATCHARSET LATIN-2 CP437 il2_asc.chs
XLATIMPORT CP437
XLATIMPORT CP437
XLATLOCALSET LATIN-2
MSGLISTWIDESUBJ YES
ENDGROUP
Are you using the wrong translation table? I think you should be using cp437 -> il2, rather than ascii -> il2.
Are you using the wrong translation table? I think you should be using
cp437 -> il2, rather than ascii -> il2.
Most probably he does because it works for him prior to my last changes. So I assume that text conversion performed correctly.
Try to set LANG to cs_CZ.ISO8859-2 and that will solve your issue! No
need to set it for the whole system. Just for golded session.
$ LANG=cs_CZ.ISO8859-2 luit -encoding 'ISO-8859-2' ./gedlnx -f
Your problem is that luit converts symbols from 8859-2 to UTF, but
ncurses tries to work in UTF-8 mode because you have LANG=cs_CZ.utf8.
Are you using the wrong translation table? I think you should be using cp437 -> il2, rather than ascii -> il2.
Are you using the wrong translation table? I think you should be using
cp437 -> il2, rather than ascii -> il2.
I do not have xlat file like that.
Point is that in group B there I expect only English and old fashioned ascii 127 anyway.
You might want to try iso-8859-2 in PuTTY, also, rather than UTF-8.
Then try the command line that Vitaliy recommended to use?
xlatcharset cp437 utf-8 437_u8.chs
If that .chs file isn't in your xlat directory, I believe you can grab
it from Golded sources on github.
Try to set LANG to cs_CZ.ISO8859-2 and that will solve your
issue! No need to set it for the whole system. Just for golded
session.
$ LANG=cs_CZ.ISO8859-2 luit -encoding 'ISO-8859-2' ./gedlnx -f
Just did, but no improvement. Would it be possible that old messages
are alreadu scrambled and I have to wait for new examples?
Your problem is that luit converts symbols from 8859-2 to UTF,
but ncurses tries to work in UTF-8 mode because you have
LANG=cs_CZ.utf8.
I am not sure that is just my XLAT setup or BASH env. Interesting is,
that it is only subject (message is OK). What is difference for XLAT
in Subj and in Message? Why one UTF-8 is OK a different is not (UTF-8
4 against UFT-8 2)?
And there was another collegue who has same issue (assume different setup).
Could you please make sure that your system actually has such locale?
What does it show if you run:
LANG=cs_CZ.ISO8859-2 locale
Also try to run:
locale -a
It could be both. Could you please show your xlat setup?
BTW, luit works for me. Only difference is that my FidoNet charset is KOI8-r.
As for UTF - it's not supported and might "work" if you do some weird setup, but I'd not count on it. Better work in one-byte locales like
cp437 or ISO8859-2 in your case.
I totally understand you. I spend several days before my system
started to work OK. Will try to resolve your issues. :)
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,038 |
| Nodes: | 15 (1 / 14) |
| Uptime: | 158:26:49 |
| Calls: | 236,141 |
| Calls today: | 1 |
| Files: | 60,374 |
| D/L today: |
67 files (97,642K bytes) |
| Messages: | 288,766 |
| Posted today: | 7 |
