GNU bug report logs - #41781
27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer

Previous Next

Full log

View this message in rfc822 format

From: Daniel Koning <dk <at> danielkoning.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41781 <at> debbugs.gnu.org
Subject: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer
Date: Mon, 22 Jun 2020 19:08:57 -0500

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> When eldoc is activated in the minibuffer and uses the elisp backend
> because we're reading an elisp expression, then the syntax-table should
> also be set accordingly, indeed (not only for eldoc but also for
> forward-sexp, ...).
>
> Looks like a bug in the corresponding function (`read-expression` or nearby).

OK, I've attached another patch for that function.

>>> For one, the elisp-mode.el function `elisp--current-symbol' isn't
>>> wrapped in a `with-syntax-table', unlike other similar definitions
>>> in the same file. I think anyone invoking this function could
>>> reasonably expect it to observe elisp syntax, so that's what my tiny
>>> patch addresses.
>
> It's probably OK to do it as in your patch, yes.
> 
If you change `read--expression', I don't know whether you'll think it
makes sense to add the extra overhead to `elisp--current-symbol'. It
does have a silent dependency on the syntax table, which is arguably an
inherent bug. But it's an internal function which only (right now) gets
called in one place.

> I'm pretty sure just calling the major will break something.
> I can't offhand tell you what, tho.  Writing the comment was faster than
> trying it out and then seeing how to fix the corresponding problems.

I can confirm that it suffers from the fairly significant drawback of
not working at all. Since the major replaces the minibuffer-specific
keymap, nothing ends up bound to `exit-minibuffer', so you can't even
enter an expression (or do anything else, like history paging). You
could bind `overriding-local-map' at the top of the function, but with
that and the syntax table you're getting close to implementing a de
facto new mode inside the de jure old one. At that point it might as
well be a real custom major mode, as you suggested. And then there's the
possibility that some people's `emacs-lisp-mode-hook' might contain code
that assumes it's in a real buffer and misbehaves in the minibuffer.

On the other hand, you could do what eshell does for `eshell-command'
and turn on its major mode in the minibuffer while selectively binding
C-j, C-m, M-p, etc., inside the setup hook. I don't like this design at
all: if I were to make changes to my `minibuffer-local-map' bindings,
eshell would silently ignore them. Any custom mode for minibuffer input
should inherit an existing minibuffer keymap, in my book at least.

Daniel

[0001-lisp-simple.el-read-expression-Set-syntax-table.patch (text/x-patch, attachment)]

Previous Next

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