bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when read


From: Stefan Monnier
Subject: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer
Date: Sat, 20 Jun 2020 12:51:19 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> (a) You're typing an elisp expression into `read-from-minibuffer', and
>> (b) the function name contains punctuation, such as ! or ?, whose
>> character class is "punctuation" and not "symbol" in the standard syntax
>> table.

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).

>> There are a couple different spots in the code to which you could
>> attribute this lapse. 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. This fixes the Eldoc problem.

It's probably OK to do it as in your patch, yes.  Switching the
syntax-table can mess up `syntax-ppss`, so it's better if we can avoid
it, but in this specific case it seems unlikely to lead to a problem.

>> But here's another weird thing further down the call stack.
>> `read--expression' has a FIXME comment saying to turn on
>> `emacs-lisp-mode' in the minibuffer -- which would also set the
>> appropriate syntax table -- but it doesn't actually do it. I guess that
>> must not work for whatever reason (since it has to have taken longer to
>> write the comment than it would have taken to add the code). Should it
>> be changed now so that it does set the major mode?

I'm probably to blame for the comment.
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.

>> Is there a problem with specialized major modes in the minibuffer?

There's the fact that it's not (never?) used, so it's a big unknown.
I think we *should* use major modes in the minibuffer (tho those major
modes will probably need to be custom tailored in most cases).
Any progress in that direction (e.g. just trying it to and reporting
the problems you encounter) will be welcome.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]