GNU bug report logs - #66604
[PATCH] Gud LLDB completions

Previous Next

Full log

Message #34 received at 66604 <at> debbugs.gnu.org (full text, mbox):

From: Visuwesh <visuweshm <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66604 <at> debbugs.gnu.org,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>
Subject: Re: bug#66604: [PATCH] Gud LLDB completions
Date: Thu, 19 Oct 2023 12:01:02 +0530

[புதன் அக்டோபர் 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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.