From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#66604: [PATCH] Gud LLDB completions Date: Wed, 18 Oct 2023 16:42:46 +0200 Message-ID: References: <13AC7AD2-230A-4FAC-81D9-75FBE53456F8@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3141"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66604@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 18 16:43:50 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qt7m1-0000aH-Ok for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 Oct 2023 16:43:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qt7lp-0005HM-UQ; Wed, 18 Oct 2023 10:43:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qt7lo-0005Gg-Nb for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 10:43:36 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qt7lo-0001o5-FE for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 10:43:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qt7mE-0002ZB-49 for bug-gnu-emacs@gnu.org; Wed, 18 Oct 2023 10:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Oct 2023 14:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66604 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66604-submit@debbugs.gnu.org id=B66604.16976402199820 (code B ref 66604); Wed, 18 Oct 2023 14:44:02 +0000 Original-Received: (at 66604) by debbugs.gnu.org; 18 Oct 2023 14:43:39 +0000 Original-Received: from localhost ([127.0.0.1]:34405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qt7lp-0002YI-4q for submit@debbugs.gnu.org; Wed, 18 Oct 2023 10:43:39 -0400 Original-Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]:53493) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qt7lZ-0002Xj-B0 for 66604@debbugs.gnu.org; Wed, 18 Oct 2023 10:43:36 -0400 Original-Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-9c2a0725825so588014366b.2 for <66604@debbugs.gnu.org>; Wed, 18 Oct 2023 07:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697640169; x=1698244969; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=uLqR6FmoD2RowdM+wui9RWNCZcwICoyVqeyfbgjnGVQ=; b=bIq/HGS0S1uoEGW653m8MjJpYdm21mqhLDlWigp1O8aVYW9DocsNhB81xeqHRUs9RT Bdr7EAmsYJTVNMNVkfylhmDI+MCAq1A7sWhkMuYwNy/ytrlo5dKJJwtlBgOvdE445EIG 3RCNjSO5hsb5nqqS4ZK8KKUc6f3T1Gg4AGcZzEQzkWjRiBA1WzbUNY34Ea9dqXUlZEL0 docVE3EBs0ILriOZSiu/3L8WXZ73rIC2LhAN7DJu/27ASkRZkaRTnA35Dbhw7/QF6GdN C1yB2olApOe+Rl5D5Rk7pz4qkdL+Dpv96hUXx4qrcHJOkweO989GkpzqMaqcAx5EkwJZ LO2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697640169; x=1698244969; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uLqR6FmoD2RowdM+wui9RWNCZcwICoyVqeyfbgjnGVQ=; b=Lbxc9ba3xNgEA/2DZJa819VKD0kVfwrTsepcqHqPEWX4+OP+55sRRpqzkgW+R8uusH 8Z6pabWrG0mEfubZZ1EhwfumnfiWXThtzTREt/hUBZV9MnZ8rIjVpuvPN0pcBstev08y 4K7slsmbGhhADUjk49T6hW5AU0Qp1LRXjqnk6k8w3otIHn5H7NZBu2MGpF9BKFI1roBL cNTetrNegvt8L4SOZZovXuUiOmYtrsE4mGJ8W7Mbb+jR/mCGpKFglAJlMzewwo/jZtpw +tzUY1eRD6fVOOt28uebjUgj7HIuTDl/ovV4viKR5GKba+N1TDJWys5ugwZXtB55UFk6 Bkwg== X-Gm-Message-State: AOJu0Ywg+0TSUEaiciOp5Bzw8CiavQ3DkofrCXa7C+F2XEcatNx3dKUP QwyYBZuVw01cU3msOtvf0Ca/ts+Kk3c= X-Google-Smtp-Source: AGHT+IF/peVAZ3nLFKnzGTSk4C/hh05atY/YRxEppSaoJgKXF5lpkNqyaPwCxGKkAlOm076nxIa3zQ== X-Received: by 2002:a17:906:9c83:b0:9be:b668:5700 with SMTP id fj3-20020a1709069c8300b009beb6685700mr4022450ejc.58.1697640168163; Wed, 18 Oct 2023 07:42:48 -0700 (PDT) Original-Received: from Mini.fritz.box (p4fe3a178.dip0.t-ipconnect.de. [79.227.161.120]) by smtp.gmail.com with ESMTPSA id hg17-20020a1709072cd100b00992e265495csm1787332ejc.212.2023.10.18.07.42.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 07:42:47 -0700 (PDT) In-Reply-To: <13AC7AD2-230A-4FAC-81D9-75FBE53456F8@gmail.com> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Wed, 18 Oct 2023 15:37:30 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:272657 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mattias Engdeg=C3=A5rd 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 ev= ery command sent to lldb is echoed: > > (lldb) b exec_byte_code > b exec_byte_code <--- echo > Breakpoint 1: where =3D 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. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Gud-LLDB-completions-bug-66604.patch Content-Description: patch v2 >From e1ef4ddd5952f5e25851bc6f5fba1ce8f9d498fb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= 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 + ")") - ######################################################################## # 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 ;; '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 "" #'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 --=-=-=--