bug#66604: [PATCH] Gud LLDB completions

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 158 bytes --]

Tags: patch

This is my first version of lldb command completions, which turned out
to be a lot more fiddly than I initially thought.

Comments welcome :-).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Gud-LLDB-completions.patch --]
[-- Type: text/patch, Size: 6917 bytes --]

From 6f3b987ebbf8eeabd054c967e673899d3da203dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd.moellmann@gmail.com>
Date: Wed, 18 Oct 2023 09:24:45 +0200
Subject: [PATCH] Gud LLDB completions

* etc/emacs_lldb.py: Remove xcomplete.
* lisp/progmodes/gud.el: Implement lldb command completions.
---
 etc/emacs_lldb.py     | 30 ---------------
 lisp/progmodes/gud.el | 87 ++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 85 insertions(+), 32 deletions(-)

diff --git a/etc/emacs_lldb.py b/etc/emacs_lldb.py
index f2c7a7987c7..fa8d95d7b5b 100644
--- a/etc/emacs_lldb.py
+++ b/etc/emacs_lldb.py
@@ -203,35 +203,6 @@ def xdebug_print(debugger, command, result, internal_dict):
     """Print Lisp_Objects using safe_debug_print()"""
     debugger.HandleCommand(f"expr safe_debug_print({command})")
 
-# According to SBCommanInterpreter.cpp, the return value of
-# HandleCompletions is as follows:
-#
-# Index 1 to the end contain all the completions.
-#
-# At index 0:
-#
-# If all completions have a common prefix, this is the shortest
-# completion, with the common prefix removed from it.
-#
-# If it is the completion for a whole word, a space is added at the
-# end.
-#
-# So, the prefix is what could be added to make the command partially
-# complete.
-#
-# If there is no common prefix, index 0 has an empty string "".
-
-def xcomplete(debugger, command, result, internal_dict):
-    """Print completions for COMMAND."""
-    interpreter = debugger.GetCommandInterpreter()
-    string_list = lldb.SBStringList()
-    interpreter.HandleCompletion(command, len(command), len(command),
-                                 -1, string_list)
-    list = ""
-    for i in range(string_list.GetSize()):
-        list += '"' + string_list.GetStringAtIndex(i) + '" '
-    result.AppendMessage("(" + list + ")")
-
 \f
 ########################################################################
 #                             Formatters
@@ -336,7 +307,6 @@ def enable_type_category(debugger, category):
 def __lldb_init_module(debugger, internal_dict):
     define_command(debugger, xbacktrace)
     define_command(debugger, xdebug_print)
-    define_command(debugger, xcomplete)
     define_type_summary(debugger, "Lisp_Object", type_summary_Lisp_Object)
     define_type_synthetic(debugger, "Lisp_Object", Lisp_Object_Provider)
     enable_type_category(debugger, "Emacs")
diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index ea5a3580629..a9c1c25a505 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -3850,7 +3850,7 @@ gud-tooltip-tips
 
 \f
 ;; 'gud-lldb-history' and 'gud-gud-lldb-command-name' are required
-;; because gud-symbol uses their values if they are present.  Their
+;; because 'gud-symbol' uses their values if they are present.  Their
 ;; names are deduced from the minor-mode name.
 (defvar gud-lldb-history nil)
 
@@ -3859,7 +3859,7 @@ gud-gud-lldb-command-name
   :type 'string)
 
 (defun gud-lldb-marker-filter (string)
-  "Deduce interesting stuff from output STRING."
+  "Deduce interesting stuff from process output STRING."
   (cond (;; Process 72668 stopped
          ;; * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
          ;;     frame #0: ...) at emacs.c:1310:9 [opt]
@@ -3879,6 +3879,83 @@ gud-lldb-marker-filter
          (setq gud-overlay-arrow-position nil)))
   string)
 
+;; According to SBCommanInterpreter.cpp, the return value of
+;; HandleCompletions is as follows:
+;;
+;; Index 1 to the end contain all the completions.
+;;
+;; At index 0:
+;;
+;; If all completions have a common prefix, this is the shortest
+;; completion, with the common prefix removed from it.
+;;
+;; If it is the completion for a whole word, a space is added at the
+;; end.
+;;
+;; So, the prefix is what could be added to make the command partially
+;; complete.
+;;
+;; If there is no common prefix, index 0 has an empty string "".
+
+(defun gud-lldb-fetch-completions ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((process (get-buffer-process gud-comint-buffer))
+         (start (process-mark process))
+         (end (point))
+         (to-complete (buffer-substring-no-properties start end))
+         (output-buffer (get-buffer-create "*lldb-completions*")))
+    ;; Send the completion command with output to our buffer
+    (with-current-buffer output-buffer
+      (erase-buffer))
+    (comint-redirect-send-command-to-process
+     (format "script --language python -- gud_complete('%s')"
+             to-complete)
+     output-buffer process nil t)
+    ;; Wait for output
+    (unwind-protect
+        (while (not comint-redirect-completed)
+          (accept-process-output process))
+      (comint-redirect-cleanup))
+    ;; Process the completion output.
+    (with-current-buffer output-buffer
+      (goto-char (point-min))
+      (when (search-forward "gud-completions:" nil t)
+        (read (current-buffer))))))
+
+(defun gud-lldb-completions (_context _command)
+  "Completion table for LLDB commands."
+  (gud-gdb-completions-1 (gud-lldb-fetch-completions)))
+
+(defun gud-lldb-completion-at-point ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((end (point))
+         (line-start (comint-line-beginning-position))
+         (start (save-excursion
+                  (skip-chars-backward "^ " line-start)
+                  (point))))
+    (list (copy-marker start t) end
+          (completion-table-dynamic
+           (apply-partially #'gud-lldb-completions
+                            (buffer-substring line-start start))))))
+
+(defvar gud-lldb-def-python-completion-function
+  (concat
+   "script --language python -- "
+   "def gud_complete(c): "
+   "ci = lldb.debugger.GetCommandInterpreter(); "
+   "sl = lldb.SBStringList(); "
+   "ci.HandleCompletion(c, len(c), len(c),-1, sl); "
+   "print('gud-completions: ('); "
+   "[print(f'\"{sl.GetStringAtIndex(i)}\" ') "
+   "  for i in range(sl.GetSize())]; "
+   "print(')')")
+  "LLDB command to define a Python function for completion.
+Must be a single line.")
+
+(defun gud-lldb-initialize ()
+  "Initialize the LLDB process as needed for this debug session."
+  (gud-basic-call gud-lldb-def-python-completion-function))
+
 ;;;###autoload
 (defun lldb (command-line)
   "Run lldb passing it COMMAND-LINE as arguments.
@@ -3979,11 +4056,17 @@ lldb
 	   nil
            "Run the program.")
 
+  (add-hook 'completion-at-point-functions
+            #'gud-lldb-completion-at-point
+            nil 'local)
+  (keymap-local-set "<tab>" #'completion-at-point)
+
   (gud-set-repeat-map-property 'gud-gdb-repeat-map)
   (setq comint-prompt-regexp (rx line-start "(lldb)" (0+ blank)))
   (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)
-- 
2.42.0

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

Thank you! Maybe it's my old lldb version (lldb-1300.0.42.3, from Apple), but:

  (lldb) script --language python -- def ff(): print("hello")

completes without error but somehow isn't evaluated properly (or in another namespace?) because:

  (lldb) script --language python -- ff()
  Traceback (most recent call last):
    File "<input>", line 1, in <module>
  NameError: name 'ff' is not defined

In contrast, evaluating expressions:

  (lldb) script --language python -- abc = 123
  (lldb) script --language python -- print(abc)
  123

works as expected.

This means that gud-lldb-def-python-completion-function doesn't define gud_complete properly. However, if I change it to run in interactive mode:

 (defvar gud-lldb-def-python-completion-function
   (concat
-   "script --language python -- "
+   "script --language python --\n"
    "def gud_complete(c): "
    "ci = lldb.debugger.GetCommandInterpreter(); "
    "sl = lldb.SBStringList(); "
@@ -3948,7 +3948,8 @@ gud-lldb-def-python-completion-function
    "print('gud-completions: ('); "
    "[print(f'\"{sl.GetStringAtIndex(i)}\" ') "
    "  for i in range(sl.GetSize())]; "
-   "print(')')")
+   "print(')')"
+   "\n\nexit()")
   "LLDB command to define a Python function for completion.
 Must be a single line.")

then it works. (This means that it no longer needs to be a single line and can use indentation and stuff.)

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?

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

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

> then it works. (This means that it no longer needs to be a single line
> and can use indentation and stuff.)

Thanks for looking at this!

Your solution works here, too, with lldb 17. What a fiddly mess. The
last lines in the LLDB buffer then look like

exit()
... >>> (lldb)

So, in the attached patch, I've sent something in addition after that,
to make it look a bit prettier.

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch v2 --]
[-- Type: text/x-patch, Size: 7142 bytes --]

From e1ef4ddd5952f5e25851bc6f5fba1ce8f9d498fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd.moellmann@gmail.com>
Date: Wed, 18 Oct 2023 09:24:45 +0200
Subject: [PATCH] Gud LLDB completions (bug#66604)

* etc/emacs_lldb.py: Remove xcomplete.
* lisp/progmodes/gud.el: Implement lldb command completions.
---
 etc/emacs_lldb.py     | 30 --------------
 lisp/progmodes/gud.el | 91 ++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 89 insertions(+), 32 deletions(-)

diff --git a/etc/emacs_lldb.py b/etc/emacs_lldb.py
index f2c7a7987c7..fa8d95d7b5b 100644
--- a/etc/emacs_lldb.py
+++ b/etc/emacs_lldb.py
@@ -203,35 +203,6 @@ def xdebug_print(debugger, command, result, internal_dict):
     """Print Lisp_Objects using safe_debug_print()"""
     debugger.HandleCommand(f"expr safe_debug_print({command})")
 
-# According to SBCommanInterpreter.cpp, the return value of
-# HandleCompletions is as follows:
-#
-# Index 1 to the end contain all the completions.
-#
-# At index 0:
-#
-# If all completions have a common prefix, this is the shortest
-# completion, with the common prefix removed from it.
-#
-# If it is the completion for a whole word, a space is added at the
-# end.
-#
-# So, the prefix is what could be added to make the command partially
-# complete.
-#
-# If there is no common prefix, index 0 has an empty string "".
-
-def xcomplete(debugger, command, result, internal_dict):
-    """Print completions for COMMAND."""
-    interpreter = debugger.GetCommandInterpreter()
-    string_list = lldb.SBStringList()
-    interpreter.HandleCompletion(command, len(command), len(command),
-                                 -1, string_list)
-    list = ""
-    for i in range(string_list.GetSize()):
-        list += '"' + string_list.GetStringAtIndex(i) + '" '
-    result.AppendMessage("(" + list + ")")
-
 \f
 ########################################################################
 #                             Formatters
@@ -336,7 +307,6 @@ def enable_type_category(debugger, category):
 def __lldb_init_module(debugger, internal_dict):
     define_command(debugger, xbacktrace)
     define_command(debugger, xdebug_print)
-    define_command(debugger, xcomplete)
     define_type_summary(debugger, "Lisp_Object", type_summary_Lisp_Object)
     define_type_synthetic(debugger, "Lisp_Object", Lisp_Object_Provider)
     enable_type_category(debugger, "Emacs")
diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index ea5a3580629..3a694642e48 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -3850,7 +3850,7 @@ gud-tooltip-tips
 
 \f
 ;; 'gud-lldb-history' and 'gud-gud-lldb-command-name' are required
-;; because gud-symbol uses their values if they are present.  Their
+;; because 'gud-symbol' uses their values if they are present.  Their
 ;; names are deduced from the minor-mode name.
 (defvar gud-lldb-history nil)
 
@@ -3859,7 +3859,7 @@ gud-gud-lldb-command-name
   :type 'string)
 
 (defun gud-lldb-marker-filter (string)
-  "Deduce interesting stuff from output STRING."
+  "Deduce interesting stuff from process output STRING."
   (cond (;; Process 72668 stopped
          ;; * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
          ;;     frame #0: ...) at emacs.c:1310:9 [opt]
@@ -3879,6 +3879,86 @@ gud-lldb-marker-filter
          (setq gud-overlay-arrow-position nil)))
   string)
 
+;; According to SBCommanInterpreter.cpp, the return value of
+;; HandleCompletions is as follows:
+;;
+;; Index 1 to the end contain all the completions.
+;;
+;; At index 0:
+;;
+;; If all completions have a common prefix, this is the shortest
+;; completion, with the common prefix removed from it.
+;;
+;; If it is the completion for a whole word, a space is added at the
+;; end.
+;;
+;; So, the prefix is what could be added to make the command partially
+;; complete.
+;;
+;; If there is no common prefix, index 0 has an empty string "".
+
+(defun gud-lldb-fetch-completions ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((process (get-buffer-process gud-comint-buffer))
+         (start (process-mark process))
+         (end (point))
+         (to-complete (buffer-substring-no-properties start end))
+         (output-buffer (get-buffer-create "*lldb-completions*")))
+    ;; Send the completion command with output to our buffer
+    (with-current-buffer output-buffer
+      (erase-buffer))
+    (comint-redirect-send-command-to-process
+     (format "script --language python -- gud_complete('%s')"
+             to-complete)
+     output-buffer process nil t)
+    ;; Wait for output
+    (unwind-protect
+        (while (not comint-redirect-completed)
+          (accept-process-output process))
+      (comint-redirect-cleanup))
+    ;; Process the completion output.
+    (with-current-buffer output-buffer
+      (goto-char (point-min))
+      (when (search-forward "gud-completions:" nil t)
+        (read (current-buffer))))))
+
+(defun gud-lldb-completions (_context _command)
+  "Completion table for LLDB commands."
+  (gud-gdb-completions-1 (gud-lldb-fetch-completions)))
+
+(defun gud-lldb-completion-at-point ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((end (point))
+         (line-start (comint-line-beginning-position))
+         (start (save-excursion
+                  (skip-chars-backward "^ " line-start)
+                  (point))))
+    (list (copy-marker start t) end
+          (completion-table-dynamic
+           (apply-partially #'gud-lldb-completions
+                            (buffer-substring line-start start))))))
+
+(defvar gud-lldb-def-python-completion-function
+  (concat
+   "script --language python --\n"
+   "def gud_complete(c): "
+   "ci = lldb.debugger.GetCommandInterpreter(); "
+   "sl = lldb.SBStringList(); "
+   "ci.HandleCompletion(c, len(c), len(c),-1, sl); "
+   "print('gud-completions: ('); "
+   "[print(f'\"{sl.GetStringAtIndex(i)}\" ') "
+   "  for i in range(sl.GetSize())]; "
+   "print(')')"
+   "\n\nexit()")
+  "LLDB command to define a Python function for completion.
+Note that this is sensitive to LLDB versions.  The current
+form seems to work with LLDB versions 14, and 17.")
+
+(defun gud-lldb-initialize ()
+  "Initialize the LLDB process as needed for this debug session."
+  (gud-basic-call gud-lldb-def-python-completion-function)
+  (gud-basic-call "script --language python -- print('Gud initialized')"))
+
 ;;;###autoload
 (defun lldb (command-line)
   "Run lldb passing it COMMAND-LINE as arguments.
@@ -3979,11 +4059,18 @@ lldb
 	   nil
            "Run the program.")
 
+  (add-hook 'completion-at-point-functions
+            #'gud-lldb-completion-at-point
+            nil 'local)
+  (keymap-local-set "<tab>" #'completion-at-point)
+
   (gud-set-repeat-map-property 'gud-gdb-repeat-map)
   (setq comint-prompt-regexp (rx line-start "(lldb)" (0+ blank)))
+  (setq comint-process-echoes t)
   (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)
-- 
2.42.0

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

18 okt. 2023 kl. 16.42 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> So, in the attached patch, I've sent something in addition after that,
> to make it look a bit prettier.

Thank you, it works all right.

> Should be fixed in the attached patch.

This too.

By the way, I can confirm that changing default-directory (M-x cd) in the *gud* buffer to where the source is located allows Emacs to find the source of the current frame. Changing frame-format is probably the way forward here.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 18 okt. 2023 kl. 16.42 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> So, in the attached patch, I've sent something in addition after that,
>> to make it look a bit prettier.
>
> Thank you, it works all right.
>
>> Should be fixed in the attached patch.
>
> This too.

Does the attached also work?  It would have the advantage of being more
readable.  The Python part.

>
> By the way, I can confirm that changing default-directory (M-x cd) in
> the *gud* buffer to where the source is located allows Emacs to find
> the source of the current frame. Changing frame-format is probably the
> way forward here.

Good to know.  Thanks!

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

18 okt. 2023 kl. 17.23 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Does the attached also work?  It would have the advantage of being more
> readable.  The Python part.

Yes, it works.
A minor request is that if there is only a single completion, then a space should be added after completing the word. For example,

  (lldb) sett<TAB>

should add the 5 characters "ings " to the input.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]

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

> 18 okt. 2023 kl. 17.23 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Does the attached also work?  It would have the advantage of being more
>> readable.  The Python part.
>
> Yes, it works.
> A minor request is that if there is only a single completion, then a space should be added after completing the word. For example,
>
>   (lldb) sett<TAB>
>
> should add the 5 characters "ings " to the input.

Yeah, that's right.

Could ypu please try the attached patch?  This of works for me, but a
bit unnerving its that Corfu pops up after tryping 3 character with a
single candidate, but that's something I can live with, I guess.  Maybe
it's even normal, now that i think of it.

What completion are you using?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch adding space --]
[-- Type: text/x-patch, Size: 7329 bytes --]

From 36b4f27ee0a97880b9eb19c1f6f2c9f1f6b22437 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd.moellmann@gmail.com>
Date: Wed, 18 Oct 2023 09:24:45 +0200
Subject: [PATCH] Gud LLDB completions (bug#66604)

* etc/emacs_lldb.py: Remove xcomplete.
* lisp/progmodes/gud.el: Implement lldb command completions.
---
 etc/emacs_lldb.py     | 30 -------------
 lisp/progmodes/gud.el | 97 +++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 94 insertions(+), 33 deletions(-)

diff --git a/etc/emacs_lldb.py b/etc/emacs_lldb.py
index f2c7a7987c7..fa8d95d7b5b 100644
--- a/etc/emacs_lldb.py
+++ b/etc/emacs_lldb.py
@@ -203,35 +203,6 @@ def xdebug_print(debugger, command, result, internal_dict):
     """Print Lisp_Objects using safe_debug_print()"""
     debugger.HandleCommand(f"expr safe_debug_print({command})")
 
-# According to SBCommanInterpreter.cpp, the return value of
-# HandleCompletions is as follows:
-#
-# Index 1 to the end contain all the completions.
-#
-# At index 0:
-#
-# If all completions have a common prefix, this is the shortest
-# completion, with the common prefix removed from it.
-#
-# If it is the completion for a whole word, a space is added at the
-# end.
-#
-# So, the prefix is what could be added to make the command partially
-# complete.
-#
-# If there is no common prefix, index 0 has an empty string "".
-
-def xcomplete(debugger, command, result, internal_dict):
-    """Print completions for COMMAND."""
-    interpreter = debugger.GetCommandInterpreter()
-    string_list = lldb.SBStringList()
-    interpreter.HandleCompletion(command, len(command), len(command),
-                                 -1, string_list)
-    list = ""
-    for i in range(string_list.GetSize()):
-        list += '"' + string_list.GetStringAtIndex(i) + '" '
-    result.AppendMessage("(" + list + ")")
-
 \f
 ########################################################################
 #                             Formatters
@@ -336,7 +307,6 @@ def enable_type_category(debugger, category):
 def __lldb_init_module(debugger, internal_dict):
     define_command(debugger, xbacktrace)
     define_command(debugger, xdebug_print)
-    define_command(debugger, xcomplete)
     define_type_summary(debugger, "Lisp_Object", type_summary_Lisp_Object)
     define_type_synthetic(debugger, "Lisp_Object", Lisp_Object_Provider)
     enable_type_category(debugger, "Emacs")
diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index ea5a3580629..5470c0ef11f 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -3850,7 +3850,7 @@ gud-tooltip-tips
 
 \f
 ;; 'gud-lldb-history' and 'gud-gud-lldb-command-name' are required
-;; because gud-symbol uses their values if they are present.  Their
+;; because 'gud-symbol' uses their values if they are present.  Their
 ;; names are deduced from the minor-mode name.
 (defvar gud-lldb-history nil)
 
@@ -3859,7 +3859,7 @@ gud-gud-lldb-command-name
   :type 'string)
 
 (defun gud-lldb-marker-filter (string)
-  "Deduce interesting stuff from output STRING."
+  "Deduce interesting stuff from process output STRING."
   (cond (;; Process 72668 stopped
          ;; * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
          ;;     frame #0: ...) at emacs.c:1310:9 [opt]
@@ -3879,6 +3879,91 @@ gud-lldb-marker-filter
          (setq gud-overlay-arrow-position nil)))
   string)
 
+;; According to SBCommanInterpreter.cpp, the return value of
+;; HandleCompletions is as follows:
+;;
+;; Index 1 to the end contain all the completions.
+;;
+;; At index 0:
+;;
+;; If all completions have a common prefix, this is the shortest
+;; completion, with the common prefix removed from it.
+;;
+;; If it is the completion for a whole word, a space is added at the
+;; end.
+;;
+;; So, the prefix is what could be added to make the command partially
+;; complete.
+;;
+;; If there is no common prefix, index 0 has an empty string "".
+
+(defun gud-lldb-fetch-completions ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((process (get-buffer-process gud-comint-buffer))
+         (start (process-mark process))
+         (end (point))
+         (to-complete (buffer-substring-no-properties start end))
+         (output-buffer (get-buffer-create "*lldb-completions*")))
+    ;; Send the completion command with output to our buffer
+    (with-current-buffer output-buffer
+      (erase-buffer))
+    (comint-redirect-send-command-to-process
+     (format "script --language python -- gud_complete('%s')"
+             to-complete)
+     output-buffer process nil t)
+    ;; Wait for output
+    (unwind-protect
+        (while (not comint-redirect-completed)
+          (accept-process-output process))
+      (comint-redirect-cleanup))
+    ;; Process the completion output.
+    (with-current-buffer output-buffer
+      (goto-char (point-min))
+      (when (search-forward "gud-completions:" nil t)
+        (let ((completions (read (current-buffer))))
+          (if (string-suffix-p " " (car completions))
+              (list (concat (cl-second completions) " "))
+            (cdr completions)))))))
+
+(defun gud-lldb-completions (_context _command)
+  "Completion table for LLDB commands."
+  (gud-lldb-fetch-completions))
+
+(defun gud-lldb-completion-at-point ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((end (point))
+         (line-start (comint-line-beginning-position))
+         (start (save-excursion
+                  (skip-chars-backward "^ " line-start)
+                  (point))))
+    (list (copy-marker start t) end
+          (completion-table-dynamic
+           (apply-partially #'gud-lldb-completions
+                            (buffer-substring line-start start))))))
+
+(defvar gud-lldb-def-python-completion-function
+  "
+def gud_complete(s):
+    interpreter = lldb.debugger.GetCommandInterpreter()
+    string_list = lldb.SBStringList()
+    interpreter.HandleCompletion(s, len(s), len(s), -1, string_list)
+    print('gud-completions: (')
+    for i in range(string_list.GetSize()):
+        print(f'\"{string_list.GetStringAtIndex(i)}\" ')
+    print(')')
+"
+  "LLDB command to define a Python function for completion.")
+
+(defun gud-lldb-send-python (python)
+  (gud-basic-call "script --language python --")
+  (mapc #'gud-basic-call (split-string python "\n"))
+  (gud-basic-call "exit()"))
+
+(defun gud-lldb-initialize ()
+  "Initialize the LLDB process as needed for this debug session."
+  (gud-lldb-send-python gud-lldb-def-python-completion-function)
+  (gud-basic-call "script --language python -- print('Gud initialized')"))
+
 ;;;###autoload
 (defun lldb (command-line)
   "Run lldb passing it COMMAND-LINE as arguments.
@@ -3979,11 +4064,17 @@ lldb
 	   nil
            "Run the program.")
 
+  (add-hook 'completion-at-point-functions
+            #'gud-lldb-completion-at-point
+            nil 'local)
+  (keymap-local-set "<tab>" #'completion-at-point)
+
   (gud-set-repeat-map-property 'gud-gdb-repeat-map)
   (setq comint-prompt-regexp (rx line-start "(lldb)" (0+ blank)))
+  (setq comint-process-echoes t)
   (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)
-- 
2.42.0

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
>
>> 18 okt. 2023 kl. 17.23 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>>
>>> Does the attached also work?  It would have the advantage of being more
>>> readable.  The Python part.
>>
>> Yes, it works.
>> A minor request is that if there is only a single completion, then a space should be added after completing the word. For example,
>>
>>   (lldb) sett<TAB>
>>
>> should add the 5 characters "ings " to the input.
>
> Yeah, that's right.
>
> Could ypu please try the attached patch?  This of works for me, but a
> bit unnerving its that Corfu pops up after tryping 3 character with a
> single candidate, but that's something I can live with, I guess.  Maybe
> it's even normal, now that i think of it.
>
> What completion are you using?

Meanwhile I've cleaned this up, and committed it to master.
Thanks to you again, Matthias!

And closing...

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

18 okt. 2023 kl. 20.55 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Meanwhile I've cleaned this up, and committed it to master.

Thanks for the new feature! Completion works nicely now.

It's definitely usable at this stage and belongs in the tree, but the file.basename in the frame-format makes it a bit unfriendly to use for any project where all source files aren't in the current directory (ie, just about any project worth debugging). Please consider it a request high on the wish list!

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 18 okt. 2023 kl. 20.55 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Meanwhile I've cleaned this up, and committed it to master.
>
> Thanks for the new feature! Completion works nicely now.
>
> It's definitely usable at this stage and belongs in the tree, but the
> file.basename in the frame-format makes it a bit unfriendly to use for
> any project where all source files aren't in the current directory
> (ie, just about any project worth debugging). Please consider it a
> request high on the wish list!

Please git pull :-)

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

19 okt. 2023 kl. 12.48 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Please git pull :-)

Look at that. It actually works, and getting the column was a nice bonus! Bravo!

Some observations:

1. The command

  script --language python -- print('Gud initialized')

is apparently sent twice. Perhaps something simpler can be sent, and only once?

2. Sometimes there's an extra (second) space after the (lldb) prompt, typically after stopping. No idea where that comes from.

3. Please get rid of that `eval`! Just parse the frame info using a regexp.

Either come up with a format that is easy for both humans and computers to parse, or just computers (in which are that text in the buffer can be replaced with a human-friendly string).

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 19 okt. 2023 kl. 12.48 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Please git pull :-)
>
> Look at that. It actually works, and getting the column was a nice
> bonus! Bravo!

People tell me that I have two problems: not listening, and, ehm,
something else... Not true :-).

> Some observations:
>
> 1. The command
>
>   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, AFAIK.  Could you please paste the output you
see?

> 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?

> 3. Please get rid of that `eval`! Just parse the frame info using a regexp.
>
> Either come up with a format that is easy for both humans and
> computers to parse, or just computers (in which are that text in the
> buffer can be replaced with a human-friendly string).

Well...  That mechanism is for something I might add (much) later :-).
It's a bit overkill ATM, but you must admit that it's elegant :-).

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

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.

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

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

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.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

19 okt. 2023 kl. 15.08 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Could you
> please set completion-at-point-functions to nil in the lldb buffer, and
> see if that's also happening then?

Yes, that does not seem to affect the output at all.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 19 okt. 2023 kl. 15.08 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Could you
>> please set completion-at-point-functions to nil in the lldb buffer, and
>> see if that's also happening then?
>
> Yes, that does not seem to affect the output at all.

I don't seem to be able to reproduce this with emacs -Q.

Here is what I do:

  cd emacs/master/src
  ,/emacs -Q # this is a build with -O0 -g
  M-x lldb RET emacs RET

In gud-emacs:

  b redisplay_internal
  r -Q

then 'n', 'c' and so on. Does that look right?

That's on an M1 mac, BTW.  Can't try on my x86_64 mac because lldb
doesn't work there after the OCLP update to maxOS 14.  I'm mentioning
this because machine speed might matter in the communication emacs <->
lldb.  What machine are you using?

Could you try with a newer lldb? (brew install llvm, for example).

P.S., just FYI, since you seem to be using this, and might see it:

- There is still a problem with things like Corfu + invoking
completion-at-point manually.  This is interfering with comint
redirection, with the effect of printing completions to the gud buffer.

- There is a problem with the code in master if completion candidates
contain ')', like function names.  I have fixed that here.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

20 okt. 2023 kl. 08.04 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> I don't seem to be able to reproduce this with emacs -Q.
> 
> Here is what I do:
> 
>  cd emacs/master/src
>  ,/emacs -Q # this is a build with -O0 -g
>  M-x lldb RET emacs RET

What I did:

  DIR/emacs -Q   # built with -O2 -g
  M-x lldb RET lldb -p ‹PID› RET
  b redisplay_internal
  c

and the oddities show up when it stops.

This is on an x86-64 Mac (running 11.7 which is the newest supported version).

I prefer not building newer tools because the machine is a bit short on both cpu and disk space, and LLVM builds are known for their voracious appetite for both commodities.

> - There is a problem with the code in master if completion candidates
> contain ')', like function names.  I have fixed that here.

Good to hear!

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 20 okt. 2023 kl. 08.04 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> I don't seem to be able to reproduce this with emacs -Q.
>> 
>> Here is what I do:
>> 
>>  cd emacs/master/src
>>  ,/emacs -Q # this is a build with -O0 -g
>>  M-x lldb RET emacs RET
>
> What I did:
>
>   DIR/emacs -Q   # built with -O2 -g
>   M-x lldb RET lldb -p ‹PID› RET
>   b redisplay_internal
>   c
>
> and the oddities show up when it stops.

That's interesting, the -p PID seems to make the difference.  Could you
please confirm?  No idea what to make of that, ATM.

> This is on an x86-64 Mac (running 11.7 which is the newest supported version).
>
> I prefer not building newer tools because the machine is a bit short
> on both cpu and disk space, and LLVM builds are known for their
> voracious appetite for both commodities.

FWIW, Homebrew doesn't build it here when I install LLVM, du -h
/usr/local/Cellar/llvm says it's 1.8G.

>
>> - There is a problem with the code in master if completion candidates
>> contain ')', like function names.  I have fixed that here.
>
> Good to hear!

It's now on master.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

20 okt. 2023 kl. 13.12 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> That's interesting, the -p PID seems to make the difference.  Could you
> please confirm?  No idea what to make of that, ATM.

I get the same odd behaviour by starting lldb without arguments and then issuing

  attach ‹pid›
  b redisplay_internal
  c

but not when starting Emacs from inside lldb as per your recipe, so it's a matter of attaching vs spawning.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 20 okt. 2023 kl. 13.12 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> That's interesting, the -p PID seems to make the difference.  Could you
>> please confirm?  No idea what to make of that, ATM.
>
> I get the same odd behaviour by starting lldb without arguments and then issuing
>
>   attach ‹pid›
>   b redisplay_internal
>   c
>
> but not when starting Emacs from inside lldb as per your recipe, so it's a matter of attaching vs spawning.

Indeed. How strange.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
>
>> 20 okt. 2023 kl. 13.12 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>>
>>> That's interesting, the -p PID seems to make the difference.  Could you
>>> please confirm?  No idea what to make of that, ATM.
>>
>> I get the same odd behaviour by starting lldb without arguments and then issuing
>>
>>   attach ‹pid›
>>   b redisplay_internal
>>   c
>>
>> but not when starting Emacs from inside lldb as per your recipe, so it's a matter of attaching vs spawning.
>
> Indeed. How strange.

Strangeness A:

I do

  M-x lldb RET emacs RET

with a

  (trace-function 'gud-lldb-marker-filter)
  
to observe what the process filter sees.  I'm doing some stuff in lldb,
then kill the process, and attach to another running Emacs to see the
difference in what arrives in Emacs between the case of not attching to
a process and attaching to one.

Here is part of the trace output:

======================================================================
1 -> (gud-lldb-marker-filter "settings show use-color \n")
1 <- gud-lldb-marker-filter: "settings show use-color \n"
======================================================================
1 -> (gud-lldb-marker-filter "use-color (boolean) = false\n(lldb) ")
1 <- gud-lldb-marker-filter: "use-color (boolean) = false\n(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "process kill\n")
1 <- gud-lldb-marker-filter: "process kill\n"
======================================================================
1 -> (gud-lldb-marker-filter "Process 95787 exited with status = 9 (0x00000009) killed\n(lldb) ")
1 <- gud-lldb-marker-filter: "Process 95787 exited with status = 9 (0x00000009) killed\n(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "attach  95179\n")
1 <- gud-lldb-marker-filter: "attach  95179\n"
======================================================================
1 -> (gud-lldb-marker-filter "Process 95179 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP\n    frame #0: 0x000000018720a8b4 libsystem_kernel.dylib`mach_msg2_trap + 8\nlibsystem_kernel.dylib`mach_msg2_trap:\n->  0x18720a8b4 <+8>: ret    \n\nlibsystem_kernel.dylib`macx_swapon:\n    0x18720a8b8 <+0>: mov    x16, #-0x30               ; =-48 \n    0x18720a8bc <+4>: svc    #0x80\n    0x18720a8c0 <+8>: ret\n(lldb) ")
1 <- gud-lldb-marker-filter: "Process 95179 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP\n    frame #0: 0x000000018720a8b4 libsystem_kernel.dylib`mach_msg2_trap + 8\nlibsystem_kernel.dylib`mach_msg2_trap:\n->  0x18720a8b4 <+8>: ret    \n\nlibsystem_kernel.dylib`macx_swapon:\n    0x18720a8b8 <+0>: mov    x16, #-0x30               ; =-48 \n    0x18720a8bc <+4>: svc    #0x80\n    0x18720a8c0 <+8>: ret\n(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "n\n")
1 <- gud-lldb-marker-filter: "n\n"
======================================================================
1 -> (gud-lldb-marker-filter "(lldb) ")
1 <- gud-lldb-marker-filter: "(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "[1G[JProcess 95179 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over\n    frame #0: 0x000000018721cd30 libsystem_kernel.dylib`mach_msg2_internal + 80\nlibsystem_kernel.dylib`mach_msg2_internal:\n->  0x18721cd30 <+80>: cbz    w0, 0x18721cdd0           ; <+240>\n    0x18721cd34 <+84>: tbnz   w26, #0x6, 0x18721cd70    ; <+144>\n    0x18721cd38 <+88>: mov    w28, #0x7                 ; =7 \n    0x18721cd3c <+92>: movk   w28, #0x1000, lsl #16\n[1G[J(lldb)  [8G")
1 <- gud-lldb-marker-filter: "[1G[JProcess 95179 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over\n    frame #0: 0x000000018721cd30 libsystem_kernel.dylib`mach_msg2_internal + 80\nlibsystem_kernel.dylib`mach_msg2_internal:\n->  0x18721cd30 <+80>: cbz    w0, 0x18721cdd0           ; <+240>\n    0x18721cd34 <+84>: tbnz   w26, #0x6, 0x18721cd70    ; <+144>\n    0x18721cd38 <+88>: mov    w28, #0x7                 ; =7 \n    0x18721cd3c <+92>: movk   w28, #0x1000, lsl #16\n[1G[J(lldb)  [8G"
======================================================================
1 -> (gud-lldb-marker-filter "\n")
1 <- gud-lldb-marker-filter: "\n"
======================================================================
1 -> (gud-lldb-marker-filter "(lldb) ")
1 <- gud-lldb-marker-filter: "(lldb) "
======================================================================
1 -> (gud-lldb-marker-filter "[1G[JProcess 95179 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over\n    frame #0: 0x000000018721cd34 libsystem_kernel.dylib`mach_msg2_internal + 84\nlibsystem_kernel.dylib`mach_msg2_internal:\n->  0x18721cd34 <+84>: tbnz   w26, #0x6, 0x18721cd70    ; <+144>\n    0x18721cd38 <+88>: mov    w28, #0x7                 ; =7 \n    0x18721cd3c <+92>: movk   w28, #0x1000, lsl #16\n    0x18721cd40 <+96>: cmp    w0, w28\n[1G[J(lldb)  [8G")
1 <- gud-lldb-marker-filter: "[1G[JProcess 95179 stopped\n* thread #1, queue = 'com.apple.main-thread', stop reason = instruction step over\n    frame #0: 0x000000018721cd34 libsystem_kernel.dylib`mach_msg2_internal + 84\nlibsystem_kernel.dylib`mach_msg2_internal:\n->  0x18721cd34 <+84>: tbnz   w26, #0x6, 0x18721cd70    ; <+144>\n    0x18721cd38 <+88>: mov    w28, #0x7                 ; =7 \n    0x18721cd3c <+92>: movk   w28, #0x1000, lsl #16\n    0x18721cd40 <+96>: cmp    w0, w28\n[1G[J(lldb)  [8G"

Look at these escape sequences that suddenly appear when attaching to a
process! I don't even know what "<esc>[1G" and "<esc>[8G" do. I can't
find them in the list of ANSI sequences.

Xterm has something like that

CHA	Cursor Horizontal Absolute	CSI Ps G	Move cursor to Ps-th column of the active row (default=1).

But that makes no sense at all...

Don't know what happens after that that with the sequences in Emacs, but
this is already so weird that I need a pause :-)

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> w28, #0x7 ; =7 \n 0x18721cd3c <+92>: movk w28, #0x1000, lsl #16\n
> 0x18721cd40 <+96>: cmp w0, w28\n[1G[J(lldb) [8G"

Hm, what one cannot see in the mail, is that the prompt at the end is
actually "(lldb)  ^[[8G".  Note also the two spaces!

And what Emacs does afterwards, AFAICT now, is filter the escape
sequences out (see ansi-color-for-comint-mode.*).  Strangely, the 8G and
so on sequencess match the regexp used for that.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> w28, #0x7 ; =7 \n 0x18721cd3c <+92>: movk w28, #0x1000, lsl #16\n
>> 0x18721cd40 <+96>: cmp w0, w28\n[1G[J(lldb) [8G"
>
> Hm, what one cannot see in the mail, is that the prompt at the end is
> actually "(lldb)  ^[[8G".  Note also the two spaces!
>
> And what Emacs does afterwards, AFAICT now, is filter the escape
> sequences out (see ansi-color-for-comint-mode.*).  Strangely, the 8G and
> so on sequencess match the regexp used for that.

I'm now resasobly convinced that this is kind of a bug in LLDB.  It
doesn't check if it has an ANSI terminal sometimes, and sends ANSI
cursor movement sequences anyway.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

21 okt. 2023 kl. 12.32 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> I'm now resasobly convinced that this is kind of a bug in LLDB.  It
> doesn't check if it has an ANSI terminal sometimes, and sends ANSI
> cursor movement sequences anyway.

I'm not sure exactly when CHA first appeared; VT220 doesn't have it but VT510 does. (Even VT100 has ED.)
Of course we're not exactly happy with a terminal using any kind of editing sequences.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 21 okt. 2023 kl. 12.32 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> I'm now resasobly convinced that this is kind of a bug in LLDB.  It
>> doesn't check if it has an ANSI terminal sometimes, and sends ANSI
>> cursor movement sequences anyway.
>
> I'm not sure exactly when CHA first appeared; VT220 doesn't have it
> but VT510 does. (Even VT100 has ED.)  Of course we're not exactly
> happy with a terminal using any kind of editing sequences.

Yeah, but TERM is "dumb", so I think lldb shouldn't emit this.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

20 okt. 2023 kl. 19.28 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Look at these escape sequences that suddenly appear when attaching to a
> process! I don't even know what "<esc>[1G" and "<esc>[8G" do.

Fascinating! We should probably look into the source code producing it (libedit probably) but I wrote the attached monstrosity and it... seems to work. (Proof of concept only.)

It attempts to edit out the part of strings jumped over by CHA (CSI G), and it also edits out ED (CSI J) which is in this case just used to do exactly that immediately after CHA.


[-- Attachment #2: lldb-filter-cha.diff --]
[-- Type: application/octet-stream, Size: 2227 bytes --]

diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index 8518738d09e..245600a2f94 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -3871,6 +3871,42 @@ gud-lldb-stop
 
 (defun gud-lldb-marker-filter (string)
   "Deduce interesting stuff from process output STRING."
+  (let ((ofs 0))
+    (while (string-match (rx (* (not (in "\n\e")))
+                             (group "\e[")
+                             (? (group (+ digit)))
+                             (group (in "GJ")))
+                         string ofs)
+      (let ((bol (match-beginning 0))
+            (seq-start (match-beginning 1))
+            (arg (and (match-beginning 2)
+                      (string-to-number (match-string 2 string))))
+            (op-char (aref string (match-beginning 3)))
+            (seq-end (match-end 0)))
+        (cond ((eq op-char ?G)
+               ;; Move to absolute column. Argument is 1-based.
+               (let* ((goal-col (1- (or arg 1)))
+                      (current-col (current-column))
+                      (prefix-len (- seq-start bol))
+                      (eff-col (+ current-col prefix-len))
+                      (rel-move-left (- eff-col goal-col))
+                      (del-prefix (max 0 (min prefix-len rel-move-left)))
+                      (elide-start (- seq-start del-prefix))
+                      (elide-end seq-end)
+                      (del-chars (- rel-move-left del-prefix)))
+                 ;; FIXME: insert extra spaces if we move beyond eff-col
+                 (when (> del-chars 0)
+                   (delete-char (- del-chars)))
+                 (setq string
+                       (concat (substring string 0 elide-start)
+                               (substring string elide-end)))
+                 (setq ofs (+ bol (- prefix-len del-prefix)))))
+              ((eq op-char ?J)
+               ;; Erase in display
+               ;; FIXME
+               (setq string (concat (substring string 0 seq-start)
+                                    (substring string seq-end)))
+               (setq ofs seq-start))))))
   (cond
    ;; gud-info: (function-name args...)
    ((string-match (rx line-start (0+ blank) "gud-info:" (0+ blank)

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 20 okt. 2023 kl. 19.28 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Look at these escape sequences that suddenly appear when attaching to a
>> process! I don't even know what "<esc>[1G" and "<esc>[8G" do.
>
> Fascinating! We should probably look into the source code producing it
> (libedit probably) but I wrote the attached monstrosity and
> it... seems to work. (Proof of concept only.)

Yeah, I've actually looked at the sources :-). There is an EditLine.cpp
which has functions for this sort of stuff, but I couldn't find out
where in LLDB it is actually called in the offending case.

> It attempts to edit out the part of strings jumped over by CHA (CSI
> G), and it also edits out ED (CSI J) which is in this case just used
> to do exactly that immediately after CHA.

H, don't know.  SHould we really do that?  I mean, I don't oppose it,
es. if someone else does it :-). It just feels weird...

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> H, don't know.  SHould we really do that?  I mean, I don't oppose it,
> es. if someone else does it :-). It just feels weird...

Since the problem won't go away any time soon, I've now comitted
something maximally simple to work around it.  Could you please confirm
that it works for you?

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

23 okt. 2023 kl. 07.31 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Since the problem won't go away any time soon, I've now comitted
> something maximally simple to work around it.  Could you please confirm
> that it works for you?

It didn't really: the pattern was far too ad-hoc and it didn't even handle the test case we were talking about (b redisplay_internal; c).

It's now been made slightly more capable.

I wasn't kidding about the `eval` needing to go, though -- it really does. Would you oblige?

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 23 okt. 2023 kl. 07.31 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Since the problem won't go away any time soon, I've now comitted
>> something maximally simple to work around it.  Could you please confirm
>> that it works for you?
>
> It didn't really: the pattern was far too ad-hoc and it didn't even
> handle the test case we were talking about (b redisplay_internal; c).

Ok. Good that I asked.

> It's now been made sleightly more capable.

Fine. I wouldn't have done it.

> I wasn't kidding about the `eval` needing to go, though -- it really
> does. Would you oblige?

So, you're not kidding, I'm impressed :-).  IOW, that came across a bit
weird.  But no harm done.

You could have looked a few lines above what you insrted, though.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

23 okt. 2023 kl. 19.57 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

>> It's now been made sleightly more capable.
> 
> Fine. I wouldn't have done it.

I know.

> You could have looked a few lines above what you insrted, though.

Sorry, I haven't kept up with your pace at all. My sincere apologies!

There's one annoyance though. Normally, lldb shows frame information as

    frame #0: 0x000000010182f09c emacs`redisplay_internal at xdisp.c:16687:8 [opt]

but now we get the less informative and much less readable

    gud-info: (gud-lldb-stop :file ////Users/mattias/emacs/src/xdisp.c/// :line 16687 :column 8)

Surely we can have it both ways -- keep the standard frame-format and append some machine-readable stuff on a separate line which is then removed in the filter function so that the user doesn't need to see it?

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> There's one annoyance though. Normally, lldb shows frame information as
>
>     frame #0: 0x000000010182f09c emacs`redisplay_internal at xdisp.c:16687:8 [opt]
>
> but now we get the less informative and much less readable
>
>     gud-info: (gud-lldb-stop :file ////Users/mattias/emacs/src/xdisp.c/// :line 16687 :column 8)
>
> Surely we can have it both ways -- keep the standard frame-format and
> append some machine-readable stuff on a separate line which is then
> removed in the filter function so that the user doesn't need to see
> it?

That would also be my preference, but I haven't found out how to do it.

The idea would have been to append the Gud format to frame-format, so
that the possibly user-defined frame-format stays visible. I found the
output of "settings show frame-format" too difficult to parse in the
general case, and LLDB's Python API didn't give me a clue how to get at
the value of frame-format so that I could perhaps produce something
that's easier to handle.

So, that's an area for improvement.

Another area for improvement is possibly remote debugging, BTW. I can't
get remote debugging to work between two macs, so I don't know how LLDB
behaves when debugging remotely.

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

24 okt. 2023 kl. 06.35 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> The idea would have been to append the Gud format to frame-format, so
> that the possibly user-defined frame-format stays visible. I found the
> output of "settings show frame-format" too difficult to parse in the
> general case, and LLDB's Python API didn't give me a clue how to get at
> the value of frame-format so that I could perhaps produce something
> that's easier to handle.

I'm sure there's a better way, but this seems to work:

deb = lldb.debugger
inst = deb.GetInstanceName()
ff0 = deb.GetInternalVariableValue("frame-format", inst).GetStringAtIndex(0)
ff1 = ff0[:-1] + '!gud file ${line.file.fullpath}\\n"'
deb.SetInternalVariable("frame-format", ff1, inst)

The GetInternalVariableValue method returns an lldb.SBStringList with the actual string as its first element. For some reason this string is in quoted form and the newline is escaped as well, so we peel off the last quote before gluing on the rest.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

On 24.10.23 10:47, Mattias Engdegård wrote:
> 24 okt. 2023 kl. 06.35 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
> 
>> The idea would have been to append the Gud format to frame-format, so
>> that the possibly user-defined frame-format stays visible. I found the
>> output of "settings show frame-format" too difficult to parse in the
>> general case, and LLDB's Python API didn't give me a clue how to get at
>> the value of frame-format so that I could perhaps produce something
>> that's easier to handle.
> 
> I'm sure there's a better way, but this seems to work:
> 
> deb = lldb.debugger
> inst = deb.GetInstanceName()
> ff0 = deb.GetInternalVariableValue("frame-format", inst).GetStringAtIndex(0)
> ff1 = ff0[:-1] + '!gud file ${line.file.fullpath}\\n"'
> deb.SetInternalVariable("frame-format", ff1, inst)
> 
> The GetInternalVariableValue method returns an lldb.SBStringList with the actual string as its first element. For some reason this string is in quoted form and the newline is escaped as well, so we peel off the last quote before gluing on the rest.

That looks good, indeed!

Will you give it a try?

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

24 okt. 2023 kl. 10.52 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Will you give it a try?

I made a feeble attempt.
It would be nice if we could blast all the Python stuff to lldb in one go; it would make initialisation a lot quicker.

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 24 okt. 2023 kl. 10.52 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Will you give it a try?
>
> I made a feeble attempt.

Nice!

> It would be nice if we could blast all the Python stuff to lldb in one go; it would make initialisation a lot quicker.

Hm, maybe we could write all the stuff to a temporary file, and then
"command source <that file>", WDYT?

bug#66604: [PATCH] Gud LLDB completions

[Mattias Engdegård]

24 okt. 2023 kl. 12.27 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> Hm, maybe we could write all the stuff to a temporary file, and then
> "command source <that file>"

Yes, but would make it more difficult to run lldb remote, wouldn't it?

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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

> 24 okt. 2023 kl. 12.27 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> Hm, maybe we could write all the stuff to a temporary file, and then
>> "command source <that file>"
>
> Yes, but would make it more difficult to run lldb remote, wouldn't it?

I don't think so.

There are two cases, depending on what running lldb remote means:

1. Remote debugging in the lldb sense. Here, lldb runs locally and
connects to an llb-server running somwhere else. I don't think that's a
problem.

2. We run lldb on a remote machine using Tramp. For example

  C-x C-f /ssh:remote:some-file RET
  M-x lldb

In this case, we have to oake sure that we write the commands file
on the right machine, but I think that should already work, modulo bugs.

BTW, I filed bug#66738 now, after building from a fresh master. Could
you please also have a look?

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

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

> 18 okt. 2023 kl. 16.42 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:
>
>> So, in the attached patch, I've sent something in addition after that,
>> to make it look a bit prettier.
>
> Thank you, it works all right.
>
>> Should be fixed in the attached patch.
>
> This too.
>
> By the way, I can confirm that changing default-directory (M-x cd) in
> the *gud* buffer to where the source is located allows Emacs to find
> the source of the current frame. Changing frame-format is probably the
> way forward here.

And the attachment forgotten, of course


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch v3 --]
[-- Type: text/x-patch, Size: 7186 bytes --]

From c8e335ede44ffa1f7f65ba141cbf9866b2db83c0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd.moellmann@gmail.com>
Date: Wed, 18 Oct 2023 09:24:45 +0200
Subject: [PATCH] Gud LLDB completions (bug#66604)

* etc/emacs_lldb.py: Remove xcomplete.
* lisp/progmodes/gud.el: Implement lldb command completions.
---
 etc/emacs_lldb.py     | 30 --------------
 lisp/progmodes/gud.el | 94 +++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 91 insertions(+), 33 deletions(-)

diff --git a/etc/emacs_lldb.py b/etc/emacs_lldb.py
index f2c7a7987c7..fa8d95d7b5b 100644
--- a/etc/emacs_lldb.py
+++ b/etc/emacs_lldb.py
@@ -203,35 +203,6 @@ def xdebug_print(debugger, command, result, internal_dict):
     """Print Lisp_Objects using safe_debug_print()"""
     debugger.HandleCommand(f"expr safe_debug_print({command})")
 
-# According to SBCommanInterpreter.cpp, the return value of
-# HandleCompletions is as follows:
-#
-# Index 1 to the end contain all the completions.
-#
-# At index 0:
-#
-# If all completions have a common prefix, this is the shortest
-# completion, with the common prefix removed from it.
-#
-# If it is the completion for a whole word, a space is added at the
-# end.
-#
-# So, the prefix is what could be added to make the command partially
-# complete.
-#
-# If there is no common prefix, index 0 has an empty string "".
-
-def xcomplete(debugger, command, result, internal_dict):
-    """Print completions for COMMAND."""
-    interpreter = debugger.GetCommandInterpreter()
-    string_list = lldb.SBStringList()
-    interpreter.HandleCompletion(command, len(command), len(command),
-                                 -1, string_list)
-    list = ""
-    for i in range(string_list.GetSize()):
-        list += '"' + string_list.GetStringAtIndex(i) + '" '
-    result.AppendMessage("(" + list + ")")
-
 \f
 ########################################################################
 #                             Formatters
@@ -336,7 +307,6 @@ def enable_type_category(debugger, category):
 def __lldb_init_module(debugger, internal_dict):
     define_command(debugger, xbacktrace)
     define_command(debugger, xdebug_print)
-    define_command(debugger, xcomplete)
     define_type_summary(debugger, "Lisp_Object", type_summary_Lisp_Object)
     define_type_synthetic(debugger, "Lisp_Object", Lisp_Object_Provider)
     enable_type_category(debugger, "Emacs")
diff --git a/lisp/progmodes/gud.el b/lisp/progmodes/gud.el
index ea5a3580629..71adbcf1599 100644
--- a/lisp/progmodes/gud.el
+++ b/lisp/progmodes/gud.el
@@ -3850,7 +3850,7 @@ gud-tooltip-tips
 
 \f
 ;; 'gud-lldb-history' and 'gud-gud-lldb-command-name' are required
-;; because gud-symbol uses their values if they are present.  Their
+;; because 'gud-symbol' uses their values if they are present.  Their
 ;; names are deduced from the minor-mode name.
 (defvar gud-lldb-history nil)
 
@@ -3859,7 +3859,7 @@ gud-gud-lldb-command-name
   :type 'string)
 
 (defun gud-lldb-marker-filter (string)
-  "Deduce interesting stuff from output STRING."
+  "Deduce interesting stuff from process output STRING."
   (cond (;; Process 72668 stopped
          ;; * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
          ;;     frame #0: ...) at emacs.c:1310:9 [opt]
@@ -3879,6 +3879,88 @@ gud-lldb-marker-filter
          (setq gud-overlay-arrow-position nil)))
   string)
 
+;; According to SBCommanInterpreter.cpp, the return value of
+;; HandleCompletions is as follows:
+;;
+;; Index 1 to the end contain all the completions.
+;;
+;; At index 0:
+;;
+;; If all completions have a common prefix, this is the shortest
+;; completion, with the common prefix removed from it.
+;;
+;; If it is the completion for a whole word, a space is added at the
+;; end.
+;;
+;; So, the prefix is what could be added to make the command partially
+;; complete.
+;;
+;; If there is no common prefix, index 0 has an empty string "".
+
+(defun gud-lldb-fetch-completions ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((process (get-buffer-process gud-comint-buffer))
+         (start (process-mark process))
+         (end (point))
+         (to-complete (buffer-substring-no-properties start end))
+         (output-buffer (get-buffer-create "*lldb-completions*")))
+    ;; Send the completion command with output to our buffer
+    (with-current-buffer output-buffer
+      (erase-buffer))
+    (comint-redirect-send-command-to-process
+     (format "script --language python -- gud_complete('%s')"
+             to-complete)
+     output-buffer process nil t)
+    ;; Wait for output
+    (unwind-protect
+        (while (not comint-redirect-completed)
+          (accept-process-output process))
+      (comint-redirect-cleanup))
+    ;; Process the completion output.
+    (with-current-buffer output-buffer
+      (goto-char (point-min))
+      (when (search-forward "gud-completions:" nil t)
+        (read (current-buffer))))))
+
+(defun gud-lldb-completions (_context _command)
+  "Completion table for LLDB commands."
+  (gud-gdb-completions-1 (gud-lldb-fetch-completions)))
+
+(defun gud-lldb-completion-at-point ()
+  "Return the data to complete the LLDB command before point."
+  (let* ((end (point))
+         (line-start (comint-line-beginning-position))
+         (start (save-excursion
+                  (skip-chars-backward "^ " line-start)
+                  (point))))
+    (list (copy-marker start t) end
+          (completion-table-dynamic
+           (apply-partially #'gud-lldb-completions
+                            (buffer-substring line-start start))))))
+
+(defvar gud-lldb-def-python-completion-function
+  "
+def gud_complete(s):
+    interpreter = lldb.debugger.GetCommandInterpreter()
+    string_list = lldb.SBStringList()
+    interpreter.HandleCompletion(s, len(s), len(s), -1, string_list)
+    print('gud-completions: (')
+    for i in range(string_list.GetSize()):
+        print(f'\"{string_list.GetStringAtIndex(i)}\" ')
+    print(')')
+"
+  "LLDB command to define a Python function for completion.")
+
+(defun gud-lldb-send-python (python)
+  (gud-basic-call "script --language python --")
+  (mapc #'gud-basic-call (split-string python "\n"))
+  (gud-basic-call "exit()"))
+
+(defun gud-lldb-initialize ()
+  "Initialize the LLDB process as needed for this debug session."
+  (gud-lldb-send-python gud-lldb-def-python-completion-function)
+  (gud-basic-call "script --language python -- print('Gud initialized')"))
+
 ;;;###autoload
 (defun lldb (command-line)
   "Run lldb passing it COMMAND-LINE as arguments.
@@ -3979,11 +4061,17 @@ lldb
 	   nil
            "Run the program.")
 
+  (add-hook 'completion-at-point-functions
+            #'gud-lldb-completion-at-point
+            nil 'local)
+  (keymap-local-set "<tab>" #'completion-at-point)
+
   (gud-set-repeat-map-property 'gud-gdb-repeat-map)
   (setq comint-prompt-regexp (rx line-start "(lldb)" (0+ blank)))
+  (setq comint-process-echoes t)
   (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)
-- 
2.42.0

bug#66604: [PATCH] Gud LLDB completions

[Visuwesh]

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

bug#66604: [PATCH] Gud LLDB completions

[Gerd Möllmann]

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