bug#66738: 30.0.50; Gud LLDB regressions

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

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

Ok, thanks.

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