GNU bug report logs - #66738
30.0.50; Gud LLDB regressions

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Wed, 25 Oct 2023 04:25:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 66738 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66738 <at> debbugs.gnu.org
Subject: Re: bug#66738: 30.0.50; Gud LLDB regressions
Date: Wed, 25 Oct 2023 11:40:40 +0200
25 okt. 2023 kl. 11.06 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:

> ...I'll fix this myself, thank you.
> 
> Yeah, I did that. But it seems I have misinterpreted what the intention
> of the delete-region is.

The gist of it is that lldb uses CHA and ED as follows:

  "previous line\nsome text" (CHA N) (ED) "something else"

where (CHA N) repositions the cursor to column N, which is usually somewhere inside "some text", and (ED) clears the rest of the text on the line.

This means that if the current line, "some text", is M characters long, then we can simply delete the last M-N characters and remove the CHA and ED sequences which now have done their job, and continue processing.

The snag is that part of "some text" may have already been inserted into the buffer earlier and is thus not part of the current string being filtered. For that reason, we start by removing that part from the buffer and gluing it onto the front of our string so that the CHA and ED operations can act on it.

That text deleted from the buffer may have been write-protected but that's fine; it will be protected again next time it's inserted.

> Then let me ask differently: why did you change this in the first place?

You mean why I didn't use a series of forward slashes as end-delimiter for the full path name? It seemed no less arbitrary than a newline and no more robust. The current solution is straightforward and handles any Unix or Windows file name users will come across.

I did try out NUL as a delimiter but predictably this didn't work (lldb threw an exception, actually).





This bug report was last modified 1 year and 210 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.