Hello Nicholas.

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

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

 NB> I assume I'm looking for 8D somewhere? If so, there are none in the
 NB> entire message.

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

 NB> I did notice a question mark in the message body:

 NB> 00B0   C4 C4 C4 C4  C4 BF 20 C4  C4 C4 C4 C4  C4 C4 C4 C4    ?

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

 VA>> If you just want to use specific commit, then use git checkout.
 VA>> If you want to do binary search for broken commit - use git
 VA>> bisect interactively. Here's a tutorial, how to use it:

 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.

 VA>> And that's is very strange. I'd not be surprised if it was broken
 VA>> when I made first change (which was reverted by last commit), but
 VA>> looks like it worked fine.

 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.

Vitaliy

--- GoldED+/LNX 1.1.5-b20231030