[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: |
Eli Zaretskii |
Subject: |
bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer |
Date: |
Sat, 20 Jun 2020 10:49:14 +0300 |
Stefan, any comments?
> From: Daniel Koning <dk@danielkoning.com>
> Date: Tue, 09 Jun 2020 21:56:14 -0500
>
> 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
>
>
> [2:text/x-patch Hide
> Save:0001-lisp-progmodes-elisp-mode.el-elisp-current-symbol-Se.patch (1kB)]
>
> >From 1d4ed0e89b4ebc040609b7476128062685843c7f Mon Sep 17 00:00:00 2001
> From: Daniel Koning <dk@danielkoning.com>
> Date: Tue, 9 Jun 2020 19:24:11 -0500
> Subject: [PATCH] lisp/progmodes/elisp-mode.el (elisp--current-symbol): Set
> syntax table.
>
> Even if `elisp-current-symbol' is called from a buffer with a different
> active syntax table (such as the minibuffer in `read-from-minibuffer'),
> use `emacs-lisp-mode-syntax-table' to determine the symbol boundaries.
>
> Copyright-paperwork-exempt: yes
> ---
> lisp/progmodes/elisp-mode.el | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> index f39ecf9b7b..65c01b2ce1 100644
> --- a/lisp/progmodes/elisp-mode.el
> +++ b/lisp/progmodes/elisp-mode.el
> @@ -1615,10 +1615,11 @@ elisp--beginning-of-sexp
>
> ;; returns nil unless current word is an interned symbol.
> (defun elisp--current-symbol ()
> - (let ((c (char-after (point))))
> - (and c
> - (memq (char-syntax c) '(?w ?_))
> - (intern-soft (current-word)))))
> + (with-syntax-table emacs-lisp-mode-syntax-table
> + (let ((c (char-after (point))))
> + (and c
> + (memq (char-syntax c) '(?w ?_))
> + (intern-soft (current-word))))))
>
> (defun elisp-function-argstring (arglist)
> "Return ARGLIST as a string enclosed by ().
> --
> 2.20.1
>
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Daniel Koning, 2020/06/09
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer,
Eli Zaretskii <=
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Stefan Monnier, 2020/06/20
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Daniel Koning, 2020/06/22
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Stefan Monnier, 2020/06/23
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Daniel Koning, 2020/06/23
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Stefan Monnier, 2020/06/23
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Daniel Koning, 2020/06/23
- bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer, Stefan Monnier, 2020/06/23