From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form. Date: Sat, 26 Oct 2024 14:35:10 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18255"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 73880@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 26 16:35:51 2024 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 1t4htO-0004YI-6E for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 26 Oct 2024 16:35:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t4ht7-0000go-75; Sat, 26 Oct 2024 10:35:33 -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 1t4ht4-0000gQ-9s for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 10:35:30 -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 1t4ht4-0001d3-0Y for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 10:35:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=Y/PxFJjw3SDuDg/BMZ6cDASHJQdLIiLyzZFX604gJSM=; b=EnVsEx4bBqwHrQ7z1bK9ExrRAwvnebuDSVGwzP+uEMhfmKjMgUfj/s3NGMMXEJVjA9E8qdCOJNynmbD3j0PhxB9LQptA3avTJmiR1l6GFuwKysYLRHVY7XdwESEkjtEq8YRQGx86QUJ0QFDSzTBhRx8huSX0lwa51SFdBADOqsvYCsXT7/V1PpgpBagrsTw7cyaYu1/K0LtR68i5HtfNz6PNK+MCADDivJoKGTh6gBDCFjuDH88ogtxEhsDp+d2oBNZe3sP5xT1mq7YgczW7Oc14iuNMC/7PfZDIWUWEuLqIRCQI5bG51NUW6BIbN7mTP0s3yr0krESB7EESWv+4Mg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t4hta-0000xz-9x for bug-gnu-emacs@gnu.org; Sat, 26 Oct 2024 10:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Oct 2024 14:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73880 X-GNU-PR-Package: emacs Original-Received: via spool by 73880-submit@debbugs.gnu.org id=B73880.17299533613709 (code B ref 73880); Sat, 26 Oct 2024 14:36:02 +0000 Original-Received: (at 73880) by debbugs.gnu.org; 26 Oct 2024 14:36:01 +0000 Original-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 Original-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 Original-Received: (qmail 89297 invoked by uid 3782); 26 Oct 2024 16:35:10 +0200 Original-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 Original-Received: (qmail 1567 invoked by uid 1000); 26 Oct 2024 14:35:10 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:294276 Archived-At: 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).