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


View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66738 <at> debbugs.gnu.org
Subject: bug#66738: 30.0.50; Gud LLDB regressions
Date: Wed, 25 Oct 2023 16:02:58 +0200
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 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).

Ok, thanks.

I see you fixed this in master, so I'm closing this issue.




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.