From: Dmitry Gutov <dmitry@gutov.dev>
To: Alan Mackenzie <acm@muc.de>
Cc: 73880@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 [thread overview]
Message-ID: <a324dde9-59da-4e02-984d-2fa5e39fee6a@gutov.dev> (raw)
In-Reply-To: <Zxz-HuF8HXLNWaon@MAC.fritz.box>
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!
next prev parent reply other threads:[~2024-10-27 1:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-19 13:09 bug#73880: Master: emacs-lisp-mode: Tab completion for a function position fails in a `let' form Alan Mackenzie
2024-10-20 10:54 ` Alan Mackenzie
2024-10-26 1:50 ` Dmitry Gutov
2024-10-26 14:35 ` Alan Mackenzie
2024-10-27 1:44 ` Dmitry Gutov [this message]
2024-10-28 12:12 ` Alan Mackenzie
2024-10-29 0:15 ` Dmitry Gutov
2024-10-26 22:09 ` Alan Mackenzie
2024-10-27 1:29 ` Dmitry Gutov
2024-10-28 11:19 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a324dde9-59da-4e02-984d-2fa5e39fee6a@gutov.dev \
--to=dmitry@gutov.dev \
--cc=73880@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).