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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 73880 <at> debbugs.gnu.org
Subject: bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form.
Date: Sun, 27 Oct 2024 03:44:46 +0200

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!

Previous Next

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