Just a sample of the Echomail archive
[ << oldest | < older | list | newer > | newest >> ]
|  Message 2174  |
|  Nicholas Boel to Vitaliy Aksyonov  |
|  Latest sources..  |
|  15 Feb 24 20:53:08  |
 MSGID: 1:154/10 65cece0c REPLY: 1:104/117 65ceb498 PID: SmapiNNTPd/Linux 2.0 b20240117 CHRS: UTF-8 4 TZUTC: -0600 TID: hpt/lnx 1.9 2024-02-05 On Thu, 15 Feb 2024 23:54:04 -0700, Vitaliy Aksyonov -> Nicholas Boel wrote: VA> Just make your terminal wider and then start golded. It will use whole VA> window width unless you use "Dispmargin" parameter in your config. As for VA> 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. VA> Sure. That's your choice. :) I just want to tell that GoldEd was designed VA> 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. :) VA> I'm working on some refactoring now in charset conversions now. When that VA> is done, then iconv integration will be very simple. I will continue to wait patiently. A bit excited, but patient nonetheless. VA> Got it. What is weird, last commit fixed issue for one sysop and broken it VA> 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) . VA> Could you try to build from commit 372220588c6f17cd3f709dcb 21a9144169d988c VA> ? It was before all my changes. If it will have same behavior, then it's VA> 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) SEEN-BY: 10/0 1 15/0 18/200 90/1 102/401 103/1 705 105/81 106/201 SEEN-BY: 120/616 123/10 124/5016 128/260 129/305 135/225 153/757 7715 SEEN-BY: 154/10 30 40 50 700 203/0 214/22 218/0 1 215 601 700 720 SEEN-BY: 218/840 860 870 880 930 220/90 221/0 6 226/18 30 227/114 SEEN-BY: 229/110 112 113 206 307 317 400 426 428 470 664 700 240/1120 SEEN-BY: 240/5832 266/512 280/464 5003 5555 282/1038 291/111 292/854 SEEN-BY: 292/8125 301/1 310/31 320/219 322/757 341/66 234 342/200 SEEN-BY: 396/45 423/120 460/58 467/888 633/280 712/848 770/1 2320/105 SEEN-BY: 3634/12 5020/400 PATH: 154/10 280/464 103/705 218/700 229/426 |
[ << oldest | < older | list | newer > | newest >> ]