REPLY: 1:154/10 65cfef1c   
   MSGID: 1:104/117 65d37cf8   
   CHRS: US-ASCII 2   
   TZUTC: -0700   
   TID: hpt/lnx 1.9 2022-07-03   
   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.   
    VA>> So do you have terminal 160 chars wide, but message displayed   
    VA>> narrower?   
    NB> Yes, the message itself was created by a script and was only 78   
    NB> characters wide to begin with when it was created, and is posted to   
    NB> the message base with 'hpt post'.   
      
   Then most probably it has 'soft CR'. You may dump message hex codes with 'I'.   
      
    NB> I just think that my utf-8 hackery may be moving some of those line   
    NB> drawing characters to the next line when it shouldn't be doing so.   
    NB> Maybe there are some soft CRs in there I should be looking for (I   
    NB> 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   
      
    VA>> So how bisect works.   
    VA>> You start process with git bisect start as you already did.   
    VA>> First you mark some commit which is good for sure with git bisect   
    VA>> good. Then mark "bad" commit with git bisect bad. That will be   
    VA>> last commit in repo. git will checkout commit in the middle of   
    VA>> those two for you. Then you build it and test. If it's good, run   
    VA>> git bisect good, if it's bad, git bisect bad. Build it and test   
    VA>> again.   
      
    NB> That's how I understand it. However, you asked me to roll back to a   
    NB> 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.   
      
    NB> So without going that route, I can say ever since you've started   
    NB> updating Golded I haven't had any display issues, until this latest   
    NB> version. What you seemed to have fixed for Wilfred, did the opposite   
    NB> 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)   
   SEEN-BY: 15/0 18/200 50/109 90/1 104/117 105/81 106/201 128/260 129/305   
   SEEN-BY: 135/225 153/7715 218/700 226/30 227/114 229/110 112 113 206   
   SEEN-BY: 229/307 317 400 426 428 470 664 700 266/512 280/464 5555   
   SEEN-BY: 282/1038 291/111 292/854 301/1 320/219 322/757 342/200 396/45   
   SEEN-BY: 460/16 58 256 1124 5858 463/68 467/888 633/280 712/848 3634/12   
   SEEN-BY: 5000/111 5001/100 5005/49 5015/46 5020/828 846 1042 4441   
   SEEN-BY: 5030/49 5054/8 30 5061/133 5075/128 5083/444 5090/958   
   PATH: 104/117 5020/1042 460/58 229/426