home bbs files messages ]

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

(c) 1994,  bbs@darkrealms.ca