bug#66738: 30.0.50; Gud LLDB regressions

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

25 okt. 2023 kl. 11.06 skrev Gerd Möllmann <gerd.moellmann@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).