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: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,096 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 48:01:27 |
| Calls: | 14,060 |
| Calls today: | 1 |
| Files: | 187,100 |
| D/L today: |
10,653 files (3,270M bytes) |
| Messages: | 2,486,019 |
