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

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

bug#41781: closed (27.0.91; [PATCH] Eldoc describes the wrong function w


From: GNU bug Tracking System
Subject: bug#41781: closed (27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer)
Date: Sat, 08 Aug 2020 08:11:02 +0000

Your message dated Sat, 08 Aug 2020 11:09:58 +0300
with message-id <83a6z57e3t.fsf@gnu.org>
and subject line Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong 
function when reading an expression from the minibuffer
has caused the debbugs.gnu.org bug report #41781,
regarding 27.0.91; [PATCH] Eldoc describes the wrong function when reading an 
expression from the minibuffer
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
41781: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41781
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Date: Tue, 09 Jun 2020 21:56:14 -0500
Severity: minor
Tags: patch

The Eldoc message shows the documentation for the wrong function (or no
documentation at all) in this specific situation:

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

Function names as described in (b) are not only legal but quite common
in third-party code. There aren't many in the standard distribution, but
you'll notice a few here and there. Try this:

(require 'pcvs)
(call-interactively #'eval-expression)
-----
Eval: (cvs-mode!
-----

The mode line shows the documentation for `cvs-mode' (without the !),
which is a different function and has a different lambda list.

This is happening because the syntax table in the minibuffer never gets
changed to the elisp table, which acknowledges all the valid symbol
characters as part of the "symbol" class.

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.

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? Is there a problem
with specialized major modes in the minibuffer? I hereby kick the can
over to whoever knows more.

Daniel

Attachment: 0001-lisp-progmodes-elisp-mode.el-elisp-current-symbol-Se.patch
Description: elisp--current-symbol patch


--- End Message ---
--- Begin Message --- Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Date: Sat, 08 Aug 2020 11:09:58 +0300
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Daniel Koning <dk@danielkoning.com>,  monnier@iro.umontreal.ca,
>   41781@debbugs.gnu.org
> Date: Wed, 05 Aug 2020 17:59:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Daniel Koning <dk@danielkoning.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  41781@debbugs.gnu.org
> >> Date: Mon, 22 Jun 2020 19:08:57 -0500
> >> 
> >> OK, I've attached another patch for that function.
> >
> > Thanks, I installed this on the master branch.
> 
> I've only skimmed this thread, but it seems like the patch that was
> installed fixed the problem that was being discussed?  It's a bit
> unclear...
> 
> So should this bug report be closed?

I think it should be closed, indeed, so I have now done so.

Thanks.


--- End Message ---

reply via email to

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