TIP: Click on subject to list as thread! ANSI
echo: golded
to: Nicholas Boel
from: Vitaliy Aksyonov
date: 2024-02-16 07:10:00
subject: Re: Latest sources..

Привет, Nicholas!

15 Feb 24 20:53, ты писал(а) мне:

 VA>> Just make your terminal wider and then start golded. It will use
 VA>> whole window width unless you use "Dispmargin" parameter in your
 VA>> config. As for quotes, they will be broken down to "Quotemargin"
 VA>> columns.

 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?

 VA>> Sure. That's your choice. :) I just want to tell that GoldEd was
 VA>> designed to work with one byte encodings and UTF-8 may work
 VA>> incorrectly.

 NB> Definitely understood. However, it worked _better_ before, and I'm
 NB> just trying to figure out what happened and why.

 NB> With that said, I'm not ruling out the possibility something was
 NB> actually "fixed" that broke my utf-8 hackery, either. :)

Could be. Let's keep looking for cause.

[...skipped...]

 VA>> Got it. What is weird, last commit fixed issue for one sysop and
 VA>> broken it for you.

 NB> Yes, I know. I've had some side discussions with Wilfred about this
 NB> exact issue. However, it seems he's using a bit more of a single-byte
 NB> setup than I am. So, it's possible that he is doing less translation
 NB> from cp437 to utf-8 (as far as I know, he isn't using any xlat
 NB> settings whatsoever in golded.conf) .

 VA>> Could you try to build from commit
 VA>> 372220588c6f17cd3f709dcb721a9144169d988c ? It was before all my
 VA>> changes. If it will have same behavior, then it's something wrong
 VA>> with setup on your side and we'll try to figure that out.

 NB> I can, but as I'm not super experienced with git, so I have some
 NB> questions.

 NB> When I use 'git bisect' with these steps:

 NB> $ git bisect start
 NB> $ git bisect bad
 NB> $ git bisect good 372220588c6f17cd3f709dcb721a9144169d988c

 NB> I get this:

 NB> Bisecting: 29 revisions left to test after this (roughly 5 steps)
 NB> [f535cc792abd5d254da57a2f5b70d5b02cbd7abf] Add github actions badge

 NB> This is a much later revision after quite a few of your changes, so
 NB> 'git bisect' didn't seem to take me back as far as you wanted me to
 NB> go.. unless I'm doing something wrong.

 NB> I did see this after typing 'git bisect --help':

 NB> " Once you have specified at least one bad and one good commit, git
 NB> bisect selects a commit in the middle of that range of history, checks
 NB> it out, and outputs something similar to the following: "

 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.

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)

SOURCE: echomail via QWK@pharcyde.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.