bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 19 okt. 2023 kl. 13.50 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>>>  script --language python -- print('Gud initialized')
>>> 
>>> is apparently sent twice. Perhaps something simpler can be sent, and
>>> only once?
>> 
>> Hm, I'm sending it once
>
> Sorry, you are perfectly right. The code is
>
>   (gud-basic-call "script --language python -- print('Gud initialized')")
>   (gud-basic-call "script --language python -- print('Gud initialized.')"))
>
> so you are actually sending two slightly different commands.

Fixed, apparently I can't smerge.

>>> 2. Sometimes there's an extra (second) space after the (lldb) prompt,
>>> typically after stopping. No idea where that comes from.
>> 
>> Hm, I don't think I see that here.  Is it immediately after the stop, or
>> does it come later?
>
> Just after the stop. Transcript (with line numbers for reference):
>
> 01|(lldb) b exec_byte_code
> 02|Breakpoint 2: where = emacs`exec_byte_code + 20 at bytecode.c:476:33, 
> address = 0x000000010b389b84
> 03|(lldb) c
> 04|Process 13507 resuming
> 05|(lldb) emacs was compiled with optimization - stepping may behave oddly; 
> variables may not be available.
> 06|(lldb)  Process 13507 stopped
> 07|* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
> 08|    gud-info: (gud-lldb-stop :file 
> ////Users/mattias/emacs/src/bytecode.c/// :line 476 :column 33)
> 09|Target 0: (emacs) stopped.
> 10|(lldb)  <cursor here>
>
> In lines 5 and 6, an (lldb) prompt is printed although no input takes
> place there. No such prompts are seen when lldb runs in a terminal.
> Line 6 also prefixes "Process" with an extra space which isn't present
> when running in a terminal either.

I don't really know, but the only thing interacting with the lldb
process in addition to what is done "normally" is completion.  Could you
please set completion-at-point-functions to nil in the lldb buffer, and
see if that's also happening then?

>
>> It's a bit overkill ATM, but you must admit that it's elegant :-).
>
> Overkill is the least of it. Just you wait until someone makes you debug some 
> crafted source code that causes your Emacs to evaluate arbitrary Lisp 
> expressions!
>
> In general:
> 1. Don't use `eval` for parsing data.
> 2. Don't use `eval`.

3. Don't use CL.

I'll have a look tomorrow.