bug#66604: [PATCH] Gud LLDB completions

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

Visuwesh <visuweshm@gmail.com> writes:

> [புதன் அக்டோபர் 18, 2023] Gerd Möllmann wrote:
>
>>> Another thing that is a bit annoying with the new lldb support is that every command sent to lldb is echoed:
>>>
>>>   (lldb) b exec_byte_code
>>>   b exec_byte_code           <--- echo
>>>   Breakpoint 1: where = emacs`exec_byte_code ...
>>>
>>> Surely that wasn't intended?
>>
>> Should be fixed in the attached patch. If I guess that right, it's
>> comint that echoes. I have that turned off globally here for M-x shell.
>
> IME, this issue is better solved by forcing the process to not use any
> line editing library such as readline.
>
>>    (gud-set-repeat-map-property 'gud-gdb-repeat-map)
>>    (setq comint-prompt-regexp (rx line-start "(lldb)" (0+ blank)))
>> +  (setq comint-process-echoes t)
>
> As this can possibly lock Emacs in remote lldb sessions over TRAMP for
> the entire duration of no echo from process.  A good way to check is to
> set that variable to t in a remote bash shell and say `sleep 10' and
> enjoy the locked up Emacs for 10 seconds.  :-)
> This happens due to the use of accept-process-output to remove the
> echoed back input line IIRC.
>
>>    (setq paragraph-start comint-prompt-regexp)
>>    (setq gud-running nil)
>>    (setq gud-filter-pending-text nil)
>> +  (gud-lldb-initialize)
>>    (run-hooks 'lldb-mode-hook))
>>  
>>  (provide 'gud)

Ok, patches welcome, so to say, since I have not idea how to make lldb
not echo or not use its readline stuff, and so on. I'm more or less the
opposite of an LLDB expert, I just need something that works on my M1
mac :-).