GNU bug report logs - #73880
Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form.

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Sat, 19 Oct 2024 13:10:02 UTC

Severity: normal

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Mackenzie <acm <at> muc.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: acm <at> muc.de, 73880 <at> debbugs.gnu.org
Subject: Re: bug#73880: Master: emacs-lisp-mode: Tab completion for a
 function position fails in a `let' form.
Date: Mon, 28 Oct 2024 12:12:25 +0000
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).




This bug report was last modified 205 days ago.

Previous Next


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