From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 19 09:09:45 2024 Received: (at submit) by debbugs.gnu.org; 19 Oct 2024 13:09:45 +0000 Received: from localhost ([127.0.0.1]:41848 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t29DF-0007IN-3a for submit@debbugs.gnu.org; Sat, 19 Oct 2024 09:09:45 -0400 Received: from lists.gnu.org ([209.51.188.17]:45548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t29DD-0007IE-4K for submit@debbugs.gnu.org; Sat, 19 Oct 2024 09:09:43 -0400 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 1t29Cn-0002VD-CR for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 09:09:17 -0400 Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t29Cl-0004XM-J7 for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 09:09:17 -0400 Received: (qmail 56257 invoked by uid 3782); 19 Oct 2024 15:09:01 +0200 Received: from muc.de (p4fe15415.dip0.t-ipconnect.de [79.225.84.21]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 19 Oct 2024 15:09:00 +0200 Received: (qmail 14716 invoked by uid 1000); 19 Oct 2024 13:09:00 -0000 Date: Sat, 19 Oct 2024 13:09:00 +0000 To: bug-gnu-emacs@gnu.org Subject: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Emacs. In a recent master version, for example this commit: commit 5340fdaade1f8fe7af08293619cca89ae0796fcf (HEAD -> master, origin/master, origin/HEAD) Author: Alan Mackenzie Date: Wed Oct 16 13:17:26 2024 +0000 CC Mode: Fix dodgy lisp `let' form. , start emacs -Q, followed by entering the following incomplete form: (defun foo () (let ( ) (match-b With point after match-b, type M-TAB. This should complete to match-beginning or show that function as a completion option. Instead it signals the error "No match". This is a bug. It would seem the completion function elisp-completion-at-point thinks it is completing a variable symbol rather than a function symbol. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 20 06:54:57 2024 Received: (at 73880) by debbugs.gnu.org; 20 Oct 2024 10:54:57 +0000 Received: from localhost ([127.0.0.1]:45988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2TaK-0000QY-Tk for submit@debbugs.gnu.org; Sun, 20 Oct 2024 06:54:57 -0400 Received: from mail.muc.de ([193.149.48.3]:21038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2TaI-0000QE-Mu for 73880@debbugs.gnu.org; Sun, 20 Oct 2024 06:54:55 -0400 Received: (qmail 34942 invoked by uid 3782); 20 Oct 2024 12:54:22 +0200 Received: from muc.de (pd953a8ba.dip0.t-ipconnect.de [217.83.168.186]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 20 Oct 2024 12:54:22 +0200 Received: (qmail 29302 invoked by uid 1000); 20 Oct 2024 10:54:22 -0000 Date: Sun, 20 Oct 2024 10:54:22 +0000 To: 73880@debbugs.gnu.org Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: Dmitry Gutov , acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Dmitry and Emacs. On Sat, Oct 19, 2024 at 13:09:00 +0000, Alan Mackenzie wrote: > Hello, Emacs. > In a recent master version, for example this commit: > commit 5340fdaade1f8fe7af08293619cca89ae0796fcf (HEAD -> master, origin/master, origin/HEAD) > Author: Alan Mackenzie > Date: Wed Oct 16 13:17:26 2024 +0000 > CC Mode: Fix dodgy lisp `let' form. > , start emacs -Q, followed by entering the following incomplete form: > (defun foo () > (let ( > ) > (match-b > With point after match-b, type M-TAB. This should complete to > match-beginning or show that function as a completion option. Instead > it signals the error "No match". This is a bug. > It would seem the completion function elisp-completion-at-point thinks > it is completing a variable symbol rather than a function symbol. This is indeed the case. The following patch fixes this by checking that the symbol being completed begins within the binding list. It also adds a test into elisp-mode-tests.el. Dmitry, could you check the patch is OK, please, before I commit it. Thanks! diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index 2f931daedc7..3233447a996 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -760,7 +760,8 @@ elisp-completion-at-point (forward-sexp) (intern-soft (buffer-substring pt (point)))))))) - (error nil)))) + (error nil))) + (parent-end (point))) (pcase parent ;; FIXME: Rather than hardcode special cases here, ;; we should use something like a symbol-property. @@ -784,18 +785,35 @@ elisp-completion-at-point (list t (elisp--completion-local-symbols) :predicate (lambda (sym) (get sym 'error-conditions)))) - ((and (or ?\( 'let 'let* 'cond 'cond* 'bind*) - (guard (save-excursion - (goto-char (1- beg)) - (when (eq parent ?\() - (up-list -1)) - (forward-symbol -1) - (or - (looking-at - "\\_<\\(let\\*?\\|bind\\*\\)\\_>") - (and (not (eq parent ?\()) + ((or + (and (or 'let 'let*) + (guard (save-excursion + (goto-char parent-end) + (forward-comment (point-max)) + (let ((bindings-end + (condition-case nil + (progn (forward-list) + (point)) + (error (point-max))))) + (and + (< beg bindings-end) + (progn + (goto-char (1- beg)) + (forward-symbol -1) (looking-at - "\\_")))))) + "\\_"))))))) + (and (or ?\( 'cond 'cond* 'bind*) + (guard (save-excursion + (goto-char (1- beg)) + (when (eq parent ?\() + (up-list -1)) + (forward-symbol -1) + (or + (looking-at + "\\_<\\(let\\*?\\|bind\\*\\)\\_>") + (and (not (eq parent ?\()) + (looking-at + "\\_"))))))) (list t (elisp--completion-local-symbols) :predicate #'elisp--shorthand-aware-boundp :company-kind (lambda (_) 'variable) diff --git a/test/lisp/progmodes/elisp-mode-tests.el b/test/lisp/progmodes/elisp-mode-tests.el index 591c32a8271..45714b3e7d9 100644 --- a/test/lisp/progmodes/elisp-mode-tests.el +++ b/test/lisp/progmodes/elisp-mode-tests.el @@ -109,6 +109,14 @@ elisp--test-completions (should (member "backup-inhibited" comps)) (should-not (member "backup-buffer" comps)))))) +(ert-deftest elisp-completes-functions-after-empty-let-bindings () + (with-temp-buffer + (emacs-lisp-mode) + (insert "(let () (ba") + (let ((comps (elisp--test-completions))) + (should (member "backup-buffer" comps)) + (should-not (member "backup-inhibited" comps))))) + (ert-deftest elisp-completes-functions-after-let-bindings-2 () (with-temp-buffer (emacs-lisp-mode) -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 25 21:51:01 2024 Received: (at 73880) by debbugs.gnu.org; 26 Oct 2024 01:51:01 +0000 Received: from localhost ([127.0.0.1]:39968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4VxE-0005iv-Fu for submit@debbugs.gnu.org; Fri, 25 Oct 2024 21:51:00 -0400 Received: from fhigh-a2-smtp.messagingengine.com ([103.168.172.153]:47361) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4VxB-0005if-HL for 73880@debbugs.gnu.org; Fri, 25 Oct 2024 21:50:58 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 264B711401C0; Fri, 25 Oct 2024 21:50:19 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Fri, 25 Oct 2024 21:50:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1729907419; x=1729993819; bh=B/BaNlO1JGapqVpMFeWP0GXz7P+2U002fKjq61sA+MI=; b= XrzJ1PSZEWy14GiYuiCivHAyYBHQ4t0/8Mbkme0ADzxtTxMs6OKX1oXxFtoTDhHX WGESS0GpUNwtWnsro8Ue8i9YUcCHlQ/vtkQld4xK8ZEK27Q20C5gugYVT09Q/VKa +vllLZZ7Mc5V+RRUBx1GENqyJAWNC/ArJkuA21CWoXEXt5GVEbHQ8My9+ea/O92+ peSxVF6YwwfdcHCjb+FQQ7VtBXjZQ+aQSPWGY0CQMTKWMXvUeoqTR07Aaqp9jy3x L6rFM1SbKUuJG6y5ZN/v9ekZd9+eLc0pOnTCaGm7HQbzq2KoucqkGxwH6FCda9lu tyRYWqdomPkIDbd7U5TZXQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1729907419; x= 1729993819; bh=B/BaNlO1JGapqVpMFeWP0GXz7P+2U002fKjq61sA+MI=; b=U OFj8J/uIecb4hl9cklwyLz5fFJhrqLSt5m+y9X61P5l5iXHqLfRDBdKFB7WdqhCR 0+snRZh5R+B980YEsaab27wTQ0MIPeW2MjCug8XXrh02nhUEEjXMaEX/LcMqE8i0 eeShh5tCoKRrmmrC2ZT8LoEwgtjH58qA6g1i37xKn7Nnx3tfhrYh0U8F3gZG+L1B l2blP/G0BHh+7mLRJhb6mFLadnZgx9jycJ5y/d3p37/yTry8i4iaPG5IHquQWJpD RMq+4YRcQHd08unvvc18OiSbAdkJoUDW8355SdYpE8utCEr0i7+CI2pJFqwcoI9m 7Dfpx6QTeXwflOtSOkxHQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejfedgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfhfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicuifhuthhovhcu oegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnheptdfhuedvtd evleegueelvedvjeevheffveevhedvuefftdefhfdvueeggfetgfdtnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtoh hvrdguvghvpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphht thhopegrtghmsehmuhgtrdguvgdprhgtphhtthhopeejfeekkedtseguvggssghughhsrd hgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 25 Oct 2024 21:50:17 -0400 (EDT) Message-ID: Date: Sat, 26 Oct 2024 04:50:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. To: Alan Mackenzie , 73880@debbugs.gnu.org References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Alan! Sorry about the late response. On 20/10/2024 13:54, Alan Mackenzie wrote: > Hello, Dmitry and Emacs. > > On Sat, Oct 19, 2024 at 13:09:00 +0000, Alan Mackenzie wrote: >> Hello, Emacs. > >> In a recent master version, for example this commit: > >> commit 5340fdaade1f8fe7af08293619cca89ae0796fcf (HEAD -> master, origin/master, origin/HEAD) >> Author: Alan Mackenzie >> Date: Wed Oct 16 13:17:26 2024 +0000 > >> CC Mode: Fix dodgy lisp `let' form. > >> , start emacs -Q, followed by entering the following incomplete form: > >> (defun foo () >> (let ( >> ) >> (match-b > >> With point after match-b, type M-TAB. This should complete to >> match-beginning or show that function as a completion option. Instead >> it signals the error "No match". This is a bug. > >> It would seem the completion function elisp-completion-at-point thinks >> it is completing a variable symbol rather than a function symbol. > > This is indeed the case. The following patch fixes this by checking > that the symbol being completed begins within the binding list. It also > adds a test into elisp-mode-tests.el. The test looks good, but for the fix itself maybe we could have something shorter. Could you try the below one-liner? It seems like the problem is the (forward-symbol -1) skipping over the empty parens. This satisfies the test, at least. BTW, I had to move the corresponding piece of code to a separate function to debug it. Too bad edebug doesn't know how to jump into the 'guard' clauses. diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index 2f931daedc7..eab9b2d8ede 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -789,7 +789,7 @@ elisp-completion-at-point (goto-char (1- beg)) (when (eq parent ?\() (up-list -1)) - (forward-symbol -1) + (skip-syntax-backward " w_") (or (looking-at "\\_<\\(let\\*?\\|bind\\*\\)\\_>") From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 10:36:01 2024 Received: (at 73880) by debbugs.gnu.org; 26 Oct 2024 14:36:01 +0000 Received: from localhost ([127.0.0.1]:42233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4htY-0000xj-AH for submit@debbugs.gnu.org; Sat, 26 Oct 2024 10:36:00 -0400 Received: from mail.muc.de ([193.149.48.3]:25455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4htP-0000rl-C3 for 73880@debbugs.gnu.org; Sat, 26 Oct 2024 10:35:57 -0400 Received: (qmail 89297 invoked by uid 3782); 26 Oct 2024 16:35:10 +0200 Received: from muc.de (pd953aac8.dip0.t-ipconnect.de [217.83.170.200]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 26 Oct 2024 16:35:10 +0200 Received: (qmail 1567 invoked by uid 1000); 26 Oct 2024 14:35:10 -0000 Date: Sat, 26 Oct 2024 14:35:10 +0000 To: Dmitry Gutov Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: acm@muc.de, 73880@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Dmitry. On Sat, Oct 26, 2024 at 04:50:15 +0300, Dmitry Gutov wrote: > Hi Alan! > Sorry about the late response. No problem! > On 20/10/2024 13:54, Alan Mackenzie wrote: > > Hello, Dmitry and Emacs. > > On Sat, Oct 19, 2024 at 13:09:00 +0000, Alan Mackenzie wrote: > >> Hello, Emacs. > >> In a recent master version, for example this commit: > >> commit 5340fdaade1f8fe7af08293619cca89ae0796fcf (HEAD -> master, origin/master, origin/HEAD) > >> Author: Alan Mackenzie > >> Date: Wed Oct 16 13:17:26 2024 +0000 > >> CC Mode: Fix dodgy lisp `let' form. > >> , start emacs -Q, followed by entering the following incomplete form: > >> (defun foo () > >> (let ( > >> ) > >> (match-b > >> With point after match-b, type M-TAB. This should complete to > >> match-beginning or show that function as a completion option. Instead > >> it signals the error "No match". This is a bug. > >> It would seem the completion function elisp-completion-at-point thinks > >> it is completing a variable symbol rather than a function symbol. > > This is indeed the case. The following patch fixes this by checking > > that the symbol being completed begins within the binding list. It also > > adds a test into elisp-mode-tests.el. > The test looks good, but for the fix itself maybe we could have > something shorter. I wasn't happy with the length of my patch, either. But .... > Could you try the below one-liner? It seems like the problem is the > (forward-symbol -1) skipping over the empty parens. Yes. I haven't tried it out your patch yet, but surely it will fail when there are comments in the `let' form. For that matter, forward-symbol doesn't handle comments, either. > This satisfies the test, at least. OK. I've just looked at another form which doesn't work optimally, namely: `(let (match-b .. Here a M-TAB ought to signal "No match", but instead offers the two functions. If the backquote is removed, it works as it should. elisp-completion-at-point seems to be an approximate function which works most of the time. To make it work all the time would involve incorporating a substantial bit of the byte-compiler into it. So I don't know if it's worth doing that. But the `(let\*? form is so common (~469 occurrences in Emacs) it might be worth fixing. > BTW, I had to move the corresponding piece of code to a separate > function to debug it. Too bad edebug doesn't know how to jump into the > 'guard' clauses. Yes, I had that problem, too. Looking at the edebug spec for pcase, it seems that guard is meant to be handled, and probably is at the top level. But inside an `and' or `or' clause, it isn't. The documentation (on elisp page "Specification List") says that edebug specs are capable of handling "recursive processing of forms" amongst other things, so I think it should be possible, though not necessarily easy. Are you going to raise a bug report for this or should I? ;-) > diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el > index 2f931daedc7..eab9b2d8ede 100644 > --- a/lisp/progmodes/elisp-mode.el > +++ b/lisp/progmodes/elisp-mode.el > @@ -789,7 +789,7 @@ elisp-completion-at-point > (goto-char (1- beg)) > (when (eq parent ?\() > (up-list -1)) > - (forward-symbol -1) > + (skip-syntax-backward " w_") > (or > (looking-at > "\\_<\\(let\\*?\\|bind\\*\\)\\_>") -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 18:10:27 2024 Received: (at 73880) by debbugs.gnu.org; 26 Oct 2024 22:10:27 +0000 Received: from localhost ([127.0.0.1]:42804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4ozL-0004yc-II for submit@debbugs.gnu.org; Sat, 26 Oct 2024 18:10:27 -0400 Received: from mail.muc.de ([193.149.48.3]:46368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4ozJ-0004yA-T7 for 73880@debbugs.gnu.org; Sat, 26 Oct 2024 18:10:26 -0400 Received: (qmail 15478 invoked by uid 3782); 27 Oct 2024 00:09:45 +0200 Received: from muc.de (pd953aac8.dip0.t-ipconnect.de [217.83.170.200]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 27 Oct 2024 00:09:44 +0200 Received: (qmail 3378 invoked by uid 1000); 26 Oct 2024 22:09:44 -0000 Date: Sat, 26 Oct 2024 22:09:44 +0000 To: Dmitry Gutov Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: acm@muc.de, 73880@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello again, Dmitry. On Sat, Oct 26, 2024 at 04:50:15 +0300, Dmitry Gutov wrote: > Hi Alan! [ .... ] > BTW, I had to move the corresponding piece of code to a separate > function to debug it. Too bad edebug doesn't know how to jump into the > 'guard' clauses. I found the bug in pcase.el causing this. The edebug spec element &interpose, which is used in pcase-PAT absolutely requires that the function it uses (in this case pcase--edebug-match-pat-args) must call PF. (See edebug.el around L1810.) What PF (internal function in edebug) does is join up edebug specs with what follows. pcase--edebug-match-pat-args fails to do this for most cases it deals with, including guard. As a result, there is no edebug instrumentation generated for the argument of guard. I'm going to raise a bug report for this (answering my question in my last post). In the meantime, here is a rough first draught of a fix. With it, I can debug the guard clauses in elisp-completion-at-point, though I seem to be triggering other problems (I get a message about a `_' argument being used after all). Enjoy! diff --git a/lisp/emacs-lisp/pcase.el b/lisp/emacs-lisp/pcase.el index 898d460c144..f600c62daa2 100644 --- a/lisp/emacs-lisp/pcase.el +++ b/lisp/emacs-lisp/pcase.el @@ -84,14 +84,28 @@ 'pcase-FUN (defun pcase--edebug-match-pat-args (head pf) ;; (cl-assert (null (cdr head))) (setq head (car head)) - (or (alist-get head '((quote sexp) +;;;; OLD STOUGH, 2024-10-26 + ;; (or +;;;; NEW STOUGH, 2024-10-26 + (let ((specs +;;;; END OF NEW STOUGH + (alist-get head '((quote sexp) (or &rest pcase-PAT) (and &rest pcase-PAT) (guard form) (pred &or ("not" pcase-FUN) pcase-FUN) (app pcase-FUN pcase-PAT))) +;;;; NEW STOUGH, 2024-10-26 + )) + (if specs + (funcall pf specs) +;;;; END OF NEW STOUGH (let ((me (pcase--get-macroexpander head))) - (funcall pf (and me (symbolp me) (edebug-get-spec me)))))) + (funcall pf (and me (symbolp me) (edebug-get-spec me))))) +;;;; NEW STOUGH, 2024-10-26 + ) +;;;; END OF NEW STOUGH + ) (defun pcase--get-macroexpander (s) "Return the macroexpander for pcase pattern head S, or nil." [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 21:29:54 2024 Received: (at 73880) by debbugs.gnu.org; 27 Oct 2024 01:29:54 +0000 Received: from localhost ([127.0.0.1]:43325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4s6L-0006Bz-WD for submit@debbugs.gnu.org; Sat, 26 Oct 2024 21:29:54 -0400 Received: from fhigh-a1-smtp.messagingengine.com ([103.168.172.152]:52801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4s6I-0006Bh-Ud for 73880@debbugs.gnu.org; Sat, 26 Oct 2024 21:29:52 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 185DF114013F; Sat, 26 Oct 2024 21:29:11 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Sat, 26 Oct 2024 21:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1729992551; x=1730078951; bh=dcbddnQdFv+2nPc43dTG5zDSWgKPDjylH76/BdXifXU=; b= DrOvP+yCEaXEuQS9n22f9Vlt9zJtl7UsH77sjfCvT21MNp7eiIKePlyI8FskFlCm DiupYbC7c15ZeLKzgNceRz4Xe0ACzkql3v2tr/S+4JekBJpnuRfCRBhErormk43J oy6XXvv5EU8ggGlNmgCif6OIa/JWOz3BsSwSvVq5DquDS3qkEpPO64DCh2iCMOeK /qK4ORHr3glRf74o1jC4KyB6xKncufWCBM1A6iUFVdGobKDjlGqSVSAI0TZG6Vxt ghncuSiTiUScsgRaaa0ui5mtT00R2CMLQRkDhjd/UbdI580dkBiovft6l/yZze0N kKqfvgBVu0gAd3Ad3f/R4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1729992551; x= 1730078951; bh=dcbddnQdFv+2nPc43dTG5zDSWgKPDjylH76/BdXifXU=; b=X V9wPGErzAvhHeaxAMXAijrVLWZI4b8LvCpNNoPZIO3yKmJzlpoyw8BTS2H213kRi jjbP/E5QCKNQw13PnCTSe0BZWrooh6aEAU9iP7+t60Zn8ZgmpaFvRSbz/4KVRs+t 4ZURTtQSmZ6086zE3MS3ft5BRkfy4znLvUkxmbsOAMRm/1/aijnEPIGOaHIQ4vgJ jZM7Iue+dda+myfjQXfd/mLTF3Cl0j1E27xNQal302VfyfRHAZbMrDmaA5cBLkG+ RgizolGns/lPNV6vzbJnshaS5KX2HYtHTxyJcIbFub7wWrWePwZel1dQFc7lirsC dKtEBFBW8sDbrBBzuNQOg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejhedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhv uceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeetudelje egheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuth hovhdruggvvhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtoheprggtmhesmhhutgdruggvpdhrtghpthhtohepjeefkeektdesuggvsggsuhhgsh drghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 26 Oct 2024 21:29:09 -0400 (EDT) Message-ID: Date: Sun, 27 Oct 2024 03:29:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. To: Alan Mackenzie References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: 73880@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 27/10/2024 01:09, Alan Mackenzie wrote: >> BTW, I had to move the corresponding piece of code to a separate >> function to debug it. Too bad edebug doesn't know how to jump into the >> 'guard' clauses. > I found the bug in pcase.el causing this. The edebug spec element > &interpose, which is used in pcase-PAT absolutely requires that the > function it uses (in this case pcase--edebug-match-pat-args) must call > PF. (See edebug.el around L1810.) > > What PF (internal function in edebug) does is join up edebug specs with > what follows. > > pcase--edebug-match-pat-args fails to do this for most cases it deals > with, including guard. As a result, there is no edebug instrumentation > generated for the argument of guard. > > I'm going to raise a bug report for this (answering my question in my > last post). In the meantime, here is a rough first draught of a fix. > With it, I can debug the guard clauses in elisp-completion-at-point, > though I seem to be triggering other problems (I get a message about a > `_' argument being used after all). Nice! It works, thank you. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 26 21:45:32 2024 Received: (at 73880) by debbugs.gnu.org; 27 Oct 2024 01:45:32 +0000 Received: from localhost ([127.0.0.1]:43340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4sLT-0006tQ-P2 for submit@debbugs.gnu.org; Sat, 26 Oct 2024 21:45:32 -0400 Received: from fout-a5-smtp.messagingengine.com ([103.168.172.148]:52843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t4sLR-0006tD-8P for 73880@debbugs.gnu.org; Sat, 26 Oct 2024 21:45:30 -0400 Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.phl.internal (Postfix) with ESMTP id 8C79E13801EF; Sat, 26 Oct 2024 21:44:49 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-02.internal (MEProxy); Sat, 26 Oct 2024 21:44:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1729993489; x=1730079889; bh=ihkBI6nLMqWqo2rMj/vg4BnssMyK/1YVuRvsGPHC5Ew=; b= LK1mk4UyhSIFdbAXAEOe4QyyXBgffnyyH9ETEwbWkPQNiial0ZcA/uNT5f7SjG6W 4+JmckBlNAww7zTWoeLNcE77wBDb0o0jI5CYMcsbHpSlylzzZWd2/5vCvWCAnuXG se6SsbMB/PFAVOili0OqH5nvcgma5jW3jHZo9Lz9BFMdyp1CCkeu2ld9t5D5gAAy EKdQlJ3zMD+Vinko5V+rKBzKWsrXZCmQRlLgug/V0CG8SeuOYUXIDhZCJb0YMNsH nTC0ZlItFFH14dK5OZ1D8pWf6hIkMts/AFcEeVLF/GVdn+eQrPkswn1gEK3QsG74 6jG3SWA97xf728VV9JBWQg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1729993489; x= 1730079889; bh=ihkBI6nLMqWqo2rMj/vg4BnssMyK/1YVuRvsGPHC5Ew=; b=I tFDNAa0nAACy9uWWZbAcYQDW7szT315jMog3rvPkSJ6brBFFmTT4WGiPiOk5kNRC /vnST074M11e1kFmlwGJKl+2P4hW1ePeQK1uZDrIemV4cU407ErruOxPP8yGPxVS y+2BEAT34UpxGxytim+MmpN+YUlVnO0sZVmtVO8Mnz5IlkUaic65yxOTj7QKoo3k m2gTExGlM21lMhcCQzdt+7A4FXYuiIKWtOP8XqqgSr3fJUssYmRxMDl3PZf2HKQ6 KQreiHa+RT8NRKOebR2HTENLcjsh/be4Xqcxu3Hu74+O0UOy9SK/pgvGnlPHBax1 +5Od3Ih6DKl+2bOwu/3YQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejhedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhv uceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeetudelje egheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuth hovhdruggvvhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtoheprggtmhesmhhutgdruggvpdhrtghpthhtohepjeefkeektdesuggvsggsuhhgsh drghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 26 Oct 2024 21:44:47 -0400 (EDT) Message-ID: Date: Sun, 27 Oct 2024 03:44:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. To: Alan Mackenzie References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: 73880@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Alan, On 26/10/2024 17:35, Alan Mackenzie wrote: > I haven't tried it out your patch yet, but surely it will fail when there > are comments in the `let' form. For that matter, forward-symbol doesn't > handle comments, either. I think it's only relevant if there's a comment between 'let' and the var-bindings form ('()' in our example), which must happen very rarely, if at all (since it requires moving the form to the next line). Any comments inside the var-bindings form won't get in our way, and any comment after it would just make the check fail, which seems good for our scenario. If skipping over comments really was needed, we could try (forward-comment -1) (skip-syntax-backward " >w_") But probably not. >> This satisfies the test, at least. > > OK. > > I've just looked at another form which doesn't work optimally, namely: > > `(let (match-b > > .. Here a M-TAB ought to signal "No match", but instead offers the two > functions. If the backquote is removed, it works as it should. This seems to be as designed: since the form is quoted, we can't be certain whether the symbol in function position is in fact a function, or whether it will be processed some other way - not necessarily evaluated. So we accept all kinds of known symbols. Perhaps this could be improved, but at least that's the original intent. >> BTW, I had to move the corresponding piece of code to a separate >> function to debug it. Too bad edebug doesn't know how to jump into the >> 'guard' clauses. > > Yes, I had that problem, too. Looking at the edebug spec for pcase, it > seems that guard is meant to be handled, and probably is at the top > level. But inside an `and' or `or' clause, it isn't. > > The documentation (on elisp page "Specification List") says that edebug > specs are capable of handling "recursive processing of forms" amongst > other things, so I think it should be possible, though not necessarily > easy. Are you going to raise a bug report for this or should I? ;-) Seems like you went ahead with the investigation, so thanks in advance! From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 07:19:56 2024 Received: (at 73880) by debbugs.gnu.org; 28 Oct 2024 11:19:56 +0000 Received: from localhost ([127.0.0.1]:52727 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5Nmt-0002Y8-Ni for submit@debbugs.gnu.org; Mon, 28 Oct 2024 07:19:56 -0400 Received: from mail.muc.de ([193.149.48.3]:53412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5Nmr-0002Xs-Ax for 73880@debbugs.gnu.org; Mon, 28 Oct 2024 07:19:54 -0400 Received: (qmail 68085 invoked by uid 3782); 28 Oct 2024 12:19:10 +0100 Received: from muc.de (p4fe15284.dip0.t-ipconnect.de [79.225.82.132]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 28 Oct 2024 12:19:09 +0100 Received: (qmail 7335 invoked by uid 1000); 28 Oct 2024 11:19:09 -0000 Date: Mon, 28 Oct 2024 11:19:09 +0000 To: Dmitry Gutov Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: 73880@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Dmitry. On Sun, Oct 27, 2024 at 03:29:08 +0200, Dmitry Gutov wrote: > On 27/10/2024 01:09, Alan Mackenzie wrote: > >> BTW, I had to move the corresponding piece of code to a separate > >> function to debug it. Too bad edebug doesn't know how to jump into the > >> 'guard' clauses. > > I found the bug in pcase.el causing this. The edebug spec element > > &interpose, which is used in pcase-PAT absolutely requires that the > > function it uses (in this case pcase--edebug-match-pat-args) must call > > PF. (See edebug.el around L1810.) > > What PF (internal function in edebug) does is join up edebug specs with > > what follows. > > pcase--edebug-match-pat-args fails to do this for most cases it deals > > with, including guard. As a result, there is no edebug instrumentation > > generated for the argument of guard. > > I'm going to raise a bug report for this (answering my question in my > > last post). In the meantime, here is a rough first draught of a fix. > > With it, I can debug the guard clauses in elisp-completion-at-point, > > though I seem to be triggering other problems (I get a message about a > > `_' argument being used after all). > Nice! It works, thank you. Thanks for testing it. I've now submitted bug#74052, complete with a patch, for this problem. [ 74052 is easy to remember - it's 66^2 * 17 :-] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 08:13:12 2024 Received: (at 73880) by debbugs.gnu.org; 28 Oct 2024 12:13:12 +0000 Received: from localhost ([127.0.0.1]:52818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5OcS-00053A-9V for submit@debbugs.gnu.org; Mon, 28 Oct 2024 08:13:12 -0400 Received: from mail.muc.de ([193.149.48.3]:15202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5OcP-00052t-Vd for 73880@debbugs.gnu.org; Mon, 28 Oct 2024 08:13:10 -0400 Received: (qmail 28464 invoked by uid 3782); 28 Oct 2024 13:12:26 +0100 Received: from muc.de (p4fe15284.dip0.t-ipconnect.de [79.225.82.132]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 28 Oct 2024 13:12:26 +0100 Received: (qmail 17060 invoked by uid 1000); 28 Oct 2024 12:12:25 -0000 Date: Mon, 28 Oct 2024 12:12:25 +0000 To: Dmitry Gutov Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880 Cc: acm@muc.de, 73880@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Dmitry. On Sun, Oct 27, 2024 at 03:44:46 +0200, Dmitry Gutov wrote: > Hi Alan, > On 26/10/2024 17:35, Alan Mackenzie wrote: > > I haven't tried it out your patch yet, but surely it will fail when there > > are comments in the `let' form. For that matter, forward-symbol doesn't > > handle comments, either. > I think it's only relevant if there's a comment between 'let' and the > var-bindings form ('()' in our example), which must happen very rarely, > if at all (since it requires moving the form to the next line). Any > comments inside the var-bindings form won't get in our way, and any > comment after it would just make the check fail, which seems good for > our scenario. Yes. I should have tried it out first before replying. As you say, comments inside the empty binding list or between binding list and first form don't prevent your patch from working. > If skipping over comments really was needed, we could try > (forward-comment -1) > (skip-syntax-backward " >w_") > But probably not. Indeed not! > >> This satisfies the test, at least. > > OK. > > I've just looked at another form which doesn't work optimally, namely: > > `(let (match-b > > .. Here a M-TAB ought to signal "No match", but instead offers the two > > functions. If the backquote is removed, it works as it should. > This seems to be as designed: since the form is quoted, we can't be > certain whether the symbol in function position is in fact a function, > or whether it will be processed some other way - not necessarily > evaluated. So we accept all kinds of known symbols. > Perhaps this could be improved, but at least that's the original intent. OK, I can understand that. For `(let and `(let*, it seems it's almost always going to be a form being generated in a macro. But if we were to special-case those, there are other symbols we could special-case too, and before long the function would be unmaintainably complicated, for relatively little gain. So I'll withdraw my complaint about `(let (match-b. I think your patch is better than my suggested fix, since it's much shorter and does the job. I would be happy if you committed it and closed the bug. Thanks! [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 28 20:16:04 2024 Received: (at 73880-done) by debbugs.gnu.org; 29 Oct 2024 00:16:04 +0000 Received: from localhost ([127.0.0.1]:55180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5Ztz-00051T-RG for submit@debbugs.gnu.org; Mon, 28 Oct 2024 20:16:04 -0400 Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]:33239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t5Ztv-00050t-PD for 73880-done@debbugs.gnu.org; Mon, 28 Oct 2024 20:16:02 -0400 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id 707F22540167; Mon, 28 Oct 2024 20:15:52 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Mon, 28 Oct 2024 20:15:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1730160952; x=1730247352; bh=NDseFX+iD4iTOEqKft7tnGH90GGHYsLlUZZ2kiKl7EU=; b= Zfw2ggqMu8bXrdceKaYFQVLYCVoi1c5i7Jozlm0dEXxaDygJ0koThC6Nq4oeSJWa JC5FaaFrmD+yXHuPbZAG2DyaHlpgxkKBePalld6i4dFBo25XBbiWPMspQXFnDAtg ZTTvT8tKJKYdUzy2lMasRpJV8tRHlgT1XL7NPZo04sI5ZLENEY90kc7RI1UQRmCQ JQNLCB6gajIft8qYXZObVR/AyI1iJG07B4wF0mKZCbpjZB39Qzya/pv4idtreCUd F7NNcpuqN5PxA9zRBDjSJPKHR1Be7hVxIWejvXLp4BhsMf1hJKC8NSQeabGHLI3Q /kCinndGz9LuRyW2j6dJ2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1730160952; x= 1730247352; bh=NDseFX+iD4iTOEqKft7tnGH90GGHYsLlUZZ2kiKl7EU=; b=f ZVrk2MphDRH8WfTp0JUUJqhm3J5aYBb4Wb9CSAaWBpTFKQ3MGIKs9pTY5oByPzWc 4ZqBXyN3W+2W1MFf7gQ58//uDkrA9goJYzXnim2yb8vo6OC/pRxTAPWhYnyuMi+Q w7GRnnSrJUFoaoTH0CEjKTHg0UA0cWRS3Pk+wdEk8nx1KIAFqJD4CKGjKUrd4KED SKU83cXhjm8QgOJF1SkMt5j7q+3r2cbyyCWYp4Zx/q0/WtIgkEkErSFmYjntvsRv YGimw/a0UIvL/+dLU2vwqAuOmwdNycsdXPMqD1uCyYxMylWa+GPLHOMhNl4SCq4a QkSDNoT5ttizHBK40a9Dg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdektddgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfiuhhtohhv uceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpeetudelje egheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuth hovhdruggvvhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtoheprggtmhesmhhutgdruggvpdhrtghpthhtohepjeefkeektddqughonhgvseguvg gssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Oct 2024 20:15:50 -0400 (EDT) Message-ID: <2ae4581c-c13c-428c-ad9e-9b911fa704b6@gutov.dev> Date: Tue, 29 Oct 2024 02:15:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. To: Alan Mackenzie References: Content-Language: en-US From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73880-done Cc: 73880-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Alan, On 28/10/2024 14:12, Alan Mackenzie wrote: > So I'll withdraw my complaint about `(let (match-b. > > I think your patch is better than my suggested fix, since it's much > shorter and does the job. I would be happy if you committed it and > closed the bug. Thanks for testing! Now pushed to master in commits 7681eacc399 and 41f347c1d1a, and closing. From unknown Thu Jun 19 14:06:12 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 26 Nov 2024 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator