• Latest sources..

    From Nicholas Boel@1:154/10 to All on Wed Feb 14 18:11:58 2024
    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..

    First, a screenshot of the same message in question viewed in Thunderbird using Smapinntpd. This is how the message was intended to look:

    https://pharcyde.org/ss1.png

    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!

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Wed Feb 14 21:10:56 2024
    Hello Nicholas.

    14 Feb 24 18:11, you wrote to All:

    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.

    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.

    I have a few screenshots for comparisons..

    [...skipped...]

    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).

    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.

    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.

    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.

    Could you share your config and message base with sample message, which displays incorrectly?

    What OS do you have? Do you build golded yourself? Do you use cmake or make?

    I'm not sure what has changed or what I can do to make it better. Any suggestions? Thank you in advance!


    Vitaliy

    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Wed Feb 14 23:34:00 2024
    On Thu, 15 Feb 2024 03:10:56 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Wed Feb 14 23:09:52 2024
    Hello Nicholas.

    14 Feb 24 23:34, you wrote to me:

    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?

    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.

    $ gcc --version
    gcc (GCC) 13.2.1 20230801

    .. and the actual package is gcc-13.2.1-5 from Archlinux.

    I use gcc 10 and tried others. That shall not be an issue. I had some issues in older compilers. Especially for Windows or OS/2. Those mostly were created way before any standardization.

    Do you use following parameters when build it:
    USE_NCURSES
    WIDE_NCURSES
    BUGGY_NCURSES

    And which ncurses library version do you have?

    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.

    That is interesting. It shall work totally fine without screen multiplexor.

    In my case I use Putty to connect to remote computer via SSH. I have koi8-r locale and configured Putty to use it too. I never had issues with pseudo-graphics.

    Would be interesting to understand how screen or tmux makes a difference.

    BTW, what do you have for $TERM env variable?

    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.

    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

    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?

    It is very good actually. Golded writes errors in that file and if it empty - it's a good sign.

    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.

    Moved to next line is OK. It's just for messages, which has lines longer than your terminal width.

    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.

    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.

    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.

    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.

    Vitaliy

    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Karel Kral@2:423/39 to Nicholas Boel on Thu Feb 15 08:31:52 2024
    Hello Nicholas!

    14 Feb 24 18:11, you wrote to 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 saw some discussion about "look" but did not understand if it is my case.

    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?

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Wilfred van Velzen@2:280/464 to Nicholas Boel on Thu Feb 15 09:13:38 2024
    Hi Nicholas,

    On 2024-02-14 18:11:58, you wrote to All:

    I'm not sure what has changed or what I can do to make it better. Any suggestions? Thank you in advance!

    It might help if your messages in the STATS area containing high ascii would have a CHRS: kludge, to help golded with the correct decoding?

    Bye, Wilfred.

    --- FMail-lnx64 2.2.1.0
    * Origin: FMail development HQ (2:280/464)
  • From Wilfred van Velzen@2:280/464 to Nicholas Boel on Thu Feb 15 09:32:25 2024
    Hi Nicholas,

    On 2024-02-14 23:34:00, you wrote to Vitaliy Aksyonov:

    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.

    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...


    Bye, Wilfred.

    --- FMail-lnx64 2.2.1.0
    * Origin: FMail development HQ (2:280/464)
  • From Alan Ianson@1:153/757 to Karel Kral on Thu Feb 15 00:59:56 2024
    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?

    Yes, i get that to when a subject starts with Re:

    I'm not sure what is happening there.

    --- BBBS/Li6 v4.10 Toy-6
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)
  • From Karel Kral@2:423/39 to Alan Ianson on Thu Feb 15 14:15:33 2024
    Hello Alan!

    15 Feb 24 00:59, you wrote to me:

    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.

    As I have no "Re:" whatsoever, I tested then EDITREPLYRE - but no impact.
    (have "NO" in there)

    It is pitty...

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Thu Feb 15 13:16:42 2024
    On Thu, 15 Feb 2024 05:09:52 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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.

    Ok great! It just seemed like there were more warnings than normal, but that may just be because of a newer gcc version - I do believe it was upgraded recently as well.

    Do you use following parameters when build it:
    USE_NCURSES
    WIDE_NCURSES
    BUGGY_NCURSES

    USE_NCURSES is default on Linux, so I don't specify that. I have used WIDE_NCURSES in the past but not this time (doesn't really make any difference for me, it seems), and I have never used BUGGY_NCURSES.

    This time around, I just ran 'make' with no parameters. Sometimes I use BUILD=minimal, but I don't think that makes much difference in regards to how things look.

    And which ncurses library version do you have?

    ncurses-6.4_20230520-1 is the package, so everything that comes with that.

    That is interesting. It shall work totally fine without screen multiplexor.

    I did get it to show the message header, loading screen and arealist correctly now by checking "Enable VT100 line drawing even in UTF-8 mode" in my PuTTY configuration. So with that I can now drop the multiplexors. However, it doesn't change what the actual messages look like.

    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"

    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 will take a look at that and try the last few commits. I will let you know if I see any differences.

     NB>> No. golded.log has been 0 bytes for quite some time now. Is that
     NB>> normal?

    It is very good actually. Golded writes errors in that file and if it empty
    - it's a good sign.

    Good. I must have cleared it back on December 7 because of old errors, since that is the current date of the file. Nothing since then, though.

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Wilfred van Velzen on Thu Feb 15 13:39:32 2024
    On Thu, 15 Feb 2024 15:32:24 +0100, Wilfred Van Velzen -> Nicholas Boel wrote:

    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.

    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...

    That looks somewhat similar to my experience when I do my full utf-8 config. When I use 'xlatimport xp437' that changes to a worse situation. Except while I do get those wierd characters after the area names, I'm not getting the block drawing characters anywhere right now, it's just those wierd characters (one on almost every line like in your screenshot), but basically blank space everywhere else the block characters are.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Karel Kral on Thu Feb 15 13:41:28 2024
    On Thu, 15 Feb 2024 20:15:32 +0100, Karel Kral -> Alan Ianson wrote:

    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!

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Thu Feb 15 14:23:44 2024
    On Thu, 15 Feb 2024 05:09:52 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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 ]

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Thu Feb 15 17:54:04 2024
    ਢ, Nicholas!

    15 Feb 24 13:16, ᠫ() :

    [...skipped...]

    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"

    You may also try "putty".

    [...skipped...]

    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. :)

    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.

    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.

    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.

    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.

    I'm working on some refactoring now in charset conversions now. When that is done, then iconv integration will be very simple.

    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.

    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.

    Best regards,
    Vitaliy Aksyonov.

    ... ६ ⠭஢!
    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Thu Feb 15 18:04:48 2024
    ਢ, Nicholas!

    15 Feb 24 14:23, ᠫ() :

    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'.

    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.

    $ make BUILD=minimal (this compiled version 20231112 for some reason I don't yet understand)

    Minimal build disables some stuff like spellchecker. It shall not affect version. That's strange. Also cleaning previous build results may help.

    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 ]

    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.

    Best regards,
    Vitaliy Aksyonov.

    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Thu Feb 15 20:24:40 2024
    On Fri, 16 Feb 2024 00:04:48 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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.

    I can go back further.

    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.

    No, the message has no CHRS kludge - so "xlatimport cp437" assumes that message is cp437.

    I can't imagine why that message wouldn't be cp437. Wilfred has more of a cp437 setup and it displays fine for him. Here is the same message viewed over telnet using Syncterm - which is a cp437 telnet client. Currently, it does not support utf-8.

    Also, in a previous message I also showed a screenshot of the same message viewed in Thunderbird using Smapinntpd - which uses the same character translation tables as Golded. In Smapinntpd's config, I use "read cp437" which is basically the same thing as "xlatimport cp437" and it displays correctly there as well.

    https://pharcyde.org/syncterm-1.png

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Thu Feb 15 20:53:08 2024
    On Thu, 15 Feb 2024 23:54:04 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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. :)

    I'm working on some refactoring now in charset conversions now. When that is done, then iconv integration will be very simple.

    I will continue to wait patiently. A bit excited, but patient nonetheless.

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Alan Ianson@1:153/757.2 to Nicholas Boel on Thu Feb 15 22:46:17 2024
    Hello Nicholas,

    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!

    I just had a look at a bunch of messages with subject lines that begin with RE:, loaded them up in the editor and they looked fine.

    My golded.cfg has "EDITREPLYRE NO" and it's working as expected currently.

    That looks much better..

    Ttyl :-),
    Al

    ... Do it! It's easier to get forgiveness than permission.
    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757.2)
  • From Karel Kral@2:423/39 to Nicholas Boel on Fri Feb 16 08:30:22 2024
    Hello Nicholas!

    15 Feb 24 13:41, you wrote to me:

    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!

    Maybe there is some connection. But figured nothing so far ;-)

    Wilfred van Velzen, CHRS: UTF-8 2: scrambled
    Vitaliy Aksyonov, US-ASCII 2: scrambled
    Nicholas Boel, UTF-8 4: OK
    Vitaliy Aksyonov, different message, CP866 2: scrambled

    I have no UTF translation. (I have only one MAPping there).

    I will try to get more data about that.

    Karel

    --- GoldED+/LNX 1.1.5-b20180707
    * Origin: Plast DATA (2:423/39)
  • From Karel Kral@2:423/39 to Nicholas Boel on Fri Feb 16 08:46:32 2024
    Hello Nicholas!

    16 Feb 24 08:30, I wrote to you:

    I will try to get more data about that.

    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)
  • From Wilfred van Velzen@2:280/464.112 to Nicholas Boel on Fri Feb 16 08:13:04 2024
    Hi Nicholas,

    On 15 Feb 24 13:39, Nicholas Boel wrote to Wilfred van Velzen:
    about: "Latest sources..":

    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.

    That doesn't surprise me at all. It's a setting related to copy paste, not to regular line drawing.

    Wilfred.

    --- FMail-W64 2.2.0.0
    * Origin: point@work (2:280/464.112)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Fri Feb 16 07:10:24 2024
    ਢ, Nicholas!

    15 Feb 24 20:53, ᠫ() :

    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.

    So do you have terminal 160 chars wide, but message displayed narrower?

    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. :)

    Could be. Let's keep looking for cause.

    [...skipped...]

    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.

    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.

    You need to repeat that process multiple times, until git says that it found bad commit.

    Best regards,
    Vitaliy Aksyonov.

    ... 﫨 ஥ - , ...
    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Karel Kral on Fri Feb 16 17:15:32 2024
    On Fri, 16 Feb 2024 14:46:32 +0100, Karel Kral -> Nicholas Boel wrote:

    Hello Nicholas!

    16 Feb 24 08:30, I wrote to you:

     KK>> I will try to get more data about that.

    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)

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Fri Feb 16 17:26:22 2024
    On Fri, 16 Feb 2024 13:10:24 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

     NB>> My terminal during that session is already 160 wide, so that's not the
     NB>> issue with the random wrapping of those characters, then.

    So do you have terminal 160 chars wide, but message displayed narrower?

    Yes, the message itself was created by a script and was only 78 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)?

     NB>> So am I actually able to specify which commit I would like to go back
     NB>> to with 'git bisect' or should I use 'git checkout'? If checkout is
     NB>> the answer, I won't be able to keep track of good or bad commits any
     NB>> more.

    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. :)

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Mon Feb 19 09:08:22 2024
    Hello Nicholas.

    16 Feb 24 17:26, you wrote to me:

    ?aNB>>> My terminal during that session is already 160 wide, so that's
    ?aNB>>> not the issue with the random wrapping of those characters,
    ?aNB>>> then.
    So do you have terminal 160 chars wide, but message displayed
    narrower?
    Yes, the message itself was created by a script and was only 78
    characters wide to begin with when it was created, and is posted to
    the message base with 'hpt post'.

    Then most probably it has 'soft CR'. You may dump message hex codes with 'I'.

    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)?

    I don't think it's because of UTF-8. Most probably it's just incorrect (for this specific case) settings. GoldEd has so many configuration parameters. It's very easy to screw it up.

    ?aNB>>> So am I actually able to specify which commit I would like to
    ?aNB>>> go back to with 'git bisect' or should I use 'git checkout'?
    ?aNB>>> If checkout is the answer, I won't be able to keep track of
    ?aNB>>> good or bad commits any more.

    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:

    https://youtu.be/P3ZR_s3NFvM

    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.

    Sorry for confusion. That's two different things to try. With specific version I wanted to make sure that version prior to my changes works correctly.

    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. :)

    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.

    Vitaliy

    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Mon Feb 19 17:54:42 2024
    On Mon, 19 Feb 2024 15:08:22 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Tue Feb 20 07:04:00 2024
    Hello Nicholas.

    19 Feb 24 17:54, you wrote to me:

    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.

    Yep. Looks like that message doesn't have soft CRs.

    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.

    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.

    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.

    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.

    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.

    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.

    Vitaliy

    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Tue Feb 20 18:20:24 2024
    On Tue, 20 Feb 2024 13:04:00 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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.

     NB>> I used checkout to get the specific commit you asked me to grab
     NB>> (372220588c6f17cd3f709dcb721a9144169d988c), and it is indeed exactly
     NB>> how the latest version is. So you were right.

    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.

    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 far, I was able to give you a better answer.

     NB>> It did not. Whatever first change you made actually kind of helped me,
     NB>> I suppose. Hopefully this helps narrow things down better and we can
     NB>> figure out what's going on.

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Wilfred van Velzen@2:280/464.112 to Nicholas Boel on Wed Feb 21 08:40:26 2024
    Hi Nicholas,

    On 20 Feb 24 18:20, Nicholas Boel wrote to Vitaliy Aksyonov:
    about: "Latest sources..":

     NB>>> exactly how the latest version is. So you were right.
    ^^

    Your mail editor seems to insert an unnecessary utf-8 character, I can't read, in front of these quoted lines. :-(


    Wilfred.

    --- FMail-W64 2.2.0.0
    * Origin: point@work (2:280/464.112)
  • From Nicholas Boel@1:154/10 to Wilfred van Velzen on Wed Feb 21 17:17:14 2024
    On Wed, 21 Feb 2024 14:40:26 +0100, Wilfred Van Velzen -> Nicholas Boel wrote:

    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!

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Carlos Navarro@2:341/234.1 to Nicholas Boel on Thu Feb 22 18:09:13 2024
    21 Feb 2024 17:17, you wrote to Wilfred van Velzen:

    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!

    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...

    Carlos

    --- GoldED+/W32-MSVC 1.1.5-b20180707
    * Origin: cyberiada (2:341/234.1)
  • From Nicholas Boel@1:154/10 to Carlos Navarro on Thu Feb 22 16:51:38 2024
    Hello Carlos,

    On Thursday February 22 2024 18:09, you wrote to me:

    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.

    I looked back on quite a few of my messages, and only saw them on quotes with 3 ">". So I don't have much more information than that.

    Thunderbird seems to replace some normal spaces by non-breaking spaces (UTF-8: C2 A0) in quotes. I intended to investigate this...

    Are you sure it's Thunderbird? Once the message is posted, doesn't Smapinntpd rearrange the quotes (when using -smartquote) in order to add initials? Or does Smapinntpd not touch the first space of every line before quoted text?

    Anyway, we should probably move this from the Golded echo. I'm trying to sort issues with Golded as well. :)

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- GoldED+/LNX 1.1.5-b20231004
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Carlos Navarro on Thu Feb 22 17:22:10 2024
    On Fri, 23 Feb 2024 00:09:12 +0100, Carlos Navarro -> Nicholas Boel wrote:

    Also with level 2.

    For the record, you are right. The messages I was looking at were quoted the 3rd time by someone else, so it was indeed my 2nd level. ;)

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Thu Feb 22 22:11:24 2024
    Hi, Nicholas!

    20 Feb 24 18:20, ᠫ() :

    Code 20 is a space. So wrapping caused by that.
    I doubt it.

    It was just a guess. :) I'm trying to dig in all possible directions.

    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.

    Default is to use whole window. Then it's weird, that line is broken.

     NB>>> I used checkout to get the specific commit you asked me to
     NB>>> grab (372220588c6f17cd3f709dcb721a9144169d988c), and it is
     NB>>> indeed exactly how the latest version is. So you were right.

    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.
    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
    far, I was able to give you a better answer.

    Great.

     NB>>> It did not. Whatever first change you made actually kind of
     NB>>> helped me, I suppose. Hopefully this helps narrow things down
     NB>>> better and we can figure out what's going on.

    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.

    That's something. Thanks for doing that.

    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.

    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.

    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.

    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.

    Best regards,
    Vitaliy Aksyonov.

    --- GoldED+/LNX 1.1.5-b20231030
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Fri Feb 23 16:30:26 2024
    On Fri, 23 Feb 2024 04:11:24 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    Default is to use whole window. Then it's weird, that line is broken.

     NB>> 8e9f3518ac9b3b32676e7b7563e92cc44e7b5ba7 is the commit that changes
     NB>> things for the better in my case.

     NB>> It stayed that way until you reverted the commit in the latest
     NB>> version.

    That's something. Thanks for doing that.

    Anything I can do to help out.

    Have you tried to run it in local terminal emulator? Do you have any GUI on
    that computer?

    It's a headless Linux VM on my ESXi server. No GUI. But I was able to test two methods besides PuTTY.

    1) I logged in to my VMWare ESXi web interface, and opened the VM in a window there.

    2) My main PC with Windows 11, command prompt > ssh via command line.

    Both options show basically the same results, except I'd guess the VMware window is probably pretty basic and the font may not support all of the characters.

    VMWare:

    https://pharcyde.org/golded-vmware-stats.png

    Windows command prompt:

    https://pharcyde.org/golded-windowscmd-stats.png

    Putty may be pain in the ass to configure correctly.

    Seems pretty similar to the other methods I was able to try.

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Nicholas Boel@1:154/10 to Nicholas Boel on Fri Feb 23 16:39:24 2024
    On Fri, 23 Feb 2024 22:30:26 -0600, Nicholas Boel -> Vitaliy Aksyonov wrote:

    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. ;)

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Sun Feb 25 19:05:18 2024
    Hello Nicholas.

    23 Feb 24 16:39, you wrote to you:

    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. ;)

    I'll definitely play with your config to find that issue. Thanks!

    Vitaliy

    ... B ?ape?ax ?e? ??oxux ?a??opo?!
    --- GoldED+/LNX 1.1.5-b20240223
    * Origin: Aurora, Colorado (1:104/117)
  • From Karel Kral@2:423/39 to Nicholas Boel on Sun Mar 3 10:41:59 2024
    Hello Nicholas!

    16 Feb 24 17:15, you wrote to me:

    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).

    Karel

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Plast DATA (2:423/39)
  • From Nicholas Boel@1:154/10 to Karel Kral on Sun Mar 3 08:52:34 2024
    On Sun, 3 Mar 2024 16:41:58 +0100, Karel Kral -> Nicholas Boel wrote:

    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).

    I would suggest trying some translation tables. I had to look back at
    your original messages about this since it was a few weeks ago already.
    I did see there that you said you are not using any (maybe one)
    translation tables?

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Karel Kral@2:423/39 to Nicholas Boel on Thu Mar 7 18:40:06 2024
    Hello Nicholas!

    03 Mar 24 08:52, you wrote to me:

    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...

    Karel

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Plast DATA (2:423/39)
  • From Nicholas Boel@1:154/10 to Karel Kral on Thu Mar 7 17:11:54 2024
    On Fri, 8 Mar 2024 00:40:06 +0100, Karel Kral -> Nicholas Boel wrote:

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Vitaliy Aksyonov@1:104/117 to Karel Kral on Thu Mar 7 17:08:24 2024
    Hello Karel.

    07 Mar 24 18:40, you wrote to Nicholas Boel:

    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...

    OK. Your case is actually simpler than I thought. You should have zero issues with pseudo-graphics.

    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.

    In my case I have separate session in Putty with KOI8-R. And run golded like this:

    LANG=ru_RU.koi8r gedlnx -C<myconfig>

    And have no issues with pseudo-graphics. But luit works too, just tried it.

    Vitaliy

    ... 640K ought to be enough for anybody
    --- GoldED+/LNX 1.1.5-b20240305-beta
    * Origin: Aurora, Colorado (1:104/117)
  • From Vitaliy Aksyonov@1:104/117 to Nicholas Boel on Thu Mar 7 17:27:32 2024
    Hello Nicholas.

    07 Mar 24 17:11, you wrote to Karel Kral:

    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.

    Most probably he does because it works for him prior to my last changes. So I assume that text conversion performed correctly.

    Vitaliy

    ... 640K ought to be enough for anybody
    --- GoldED+/LNX 1.1.5-b20240305-beta
    * Origin: Aurora, Colorado (1:104/117)
  • From Nicholas Boel@1:154/10 to Vitaliy Aksyonov on Thu Mar 7 18:51:16 2024
    On Thu, 7 Mar 2024 23:27:32 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote:

    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.

    By his previous messages, I'm led to believe his hasn't been working
    properly for awhile.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Karel Kral@2:423/39 to Vitaliy Aksyonov on Fri Mar 8 07:30:42 2024
    Hello Vitaliy!

    07 Mar 24 17:08, you wrote to me:

    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).

    Karel

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Plast DATA (2:423/39)
  • From Karel Kral@2:423/39 to Nicholas Boel on Fri Mar 8 07:33:28 2024
    Hello Nicholas!

    07 Mar 24 17:11, you wrote to me:

    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.

    Karel

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Plast DATA (2:423/39)
  • From Nicholas Boel@1:154/10 to Karel Kral on Fri Mar 8 05:59:06 2024
    On Fri, 8 Mar 2024 13:33:28 +0100, Karel Kral -> Nicholas Boel wrote:

    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.


    This is from one of your previous messages, just so I stay on track with
    what your settings are:

    "Using UTF-8 in putty, having LANG=cs_CZ.utf8 in bash, startin golded:
    luit -encoding 'ISO-8859-2' ./gedlnx -f"

    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?

    If that doesn't work, you could try using this as well and see if it
    does something different for you:

    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.

    Regards,
    Nick

    ... "Take my advice, I don't use it anyway."
    --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
    * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)
  • From Karel Kral@2:423/39 to Nicholas Boel on Sat Mar 9 02:02:59 2024
    Hello Nicholas!

    08 Mar 24 05:59, you wrote to me:

    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?

    Just tested. No improvement for GOLDED, even worse in shell.

    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.

    Got that file, included into golded.cfg - for UTF-8. No improvement.

    I also played with EDITREPLYRE, but also no change.

    As it is about 4 characters, I think is bug in golded related to "Re: ". I have no issue with other messages (even using local czech characters, including quoting). In total I see everything OK, except few messages in International echos.

    E.g. replying to you - you can see Subj. is OK.

    Karel

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Plast DATA (2:423/39)
  • From Vitaliy Aksyonov@1:104/117 to Karel Kral on Sat Mar 9 12:44:28 2024
    Hello Karel.

    08 Mar 24 07:30, you wrote to me:

    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?

    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

    If it doesn't show that locale - you need to install or generate it. Each linux distro has own way to do it, but that's easy to google.

    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)?

    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.

    And there was another collegue who has same issue (assume different setup).

    I totally understand you. I spend several days before my system started to work OK. Will try to resolve your issues. :)

    Vitaliy

    ... 640K ought to be enough for anybody
    --- GoldED+/LNX 1.1.5-b20240305-beta
    * Origin: Aurora, Colorado (1:104/117)
  • From Karel Kral@2:423/39 to Vitaliy Aksyonov on Sun Mar 10 14:09:35 2024
    Hello Vitaliy!

    09 Mar 24 12:44, you wrote to me:

    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

    .. LANG=cs_CZ.ISO8859-2 locale
    LANG=cs_CZ.ISO8859-2
    LC_CTYPE="cs_CZ.ISO8859-2"
    LC_NUMERIC="cs_CZ.ISO8859-2"
    LC_TIME="cs_CZ.ISO8859-2"
    LC_COLLATE="cs_CZ.ISO8859-2"
    LC_MONETARY="cs_CZ.ISO8859-2"
    LC_MESSAGES="cs_CZ.ISO8859-2"
    LC_PAPER="cs_CZ.ISO8859-2"
    LC_NAME="cs_CZ.ISO8859-2"
    LC_ADDRESS="cs_CZ.ISO8859-2"
    LC_TELEPHONE="cs_CZ.ISO8859-2"
    LC_MEASUREMENT="cs_CZ.ISO8859-2"
    LC_IDENTIFICATION="cs_CZ.ISO8859-2"
    LC_ALL=

    Also try to run:
    locale -a

    .. locale -a | grep cs_CZ
    cs_CZ
    cs_CZ.iso88592
    cs_CZ.utf8


    It could be both. Could you please show your xlat setup?

    GOLDED is showed as Group B
    in cfg (this is the latest, changed also based on the latest advice)

    GROUP B
    XLATPATH /home/fido/golded/xlat
    XLATCHARSET CP437 LATIN-2 asc_il2.chs
    XLATCHARSET LATIN-2 CP437 il2_asc.chs
    XLATCHARSET CP437 UTF-8 437_u8.chs
    XLATIMPORT CP437
    XLATIMPORT CP437
    XLATLOCALSET LATIN-2
    MSGLISTWIDESUBJ YES
    ENDGROUP

    BTW, luit works for me. Only difference is that my FidoNet charset is KOI8-r.

    It is working for me in local, czech echomail.

    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.

    Where I am reading, usualy they use English. Then pure ASCII should be enough. And I would be OK even for some exceptional scrambled messages. But why some Subject lines are impacted? I see whole message OK, just that line has copied over 4 bytes. Always the same position.

    I totally understand you. I spend several days before my system
    started to work OK. Will try to resolve your issues. :)

    No problem. Have that since years. I just started to wonder if somebody else can see that. Take is as the lowest prio.

    I checked code already, for some "quick win" - but I am not c-guy = nothing found by myself.

    Thank you for any help.

    Karel

    --- GoldED+/LNX 1.1.5-b20240209
    * Origin: Plast DATA (2:423/39)