GNU bug report logs -
#23897
25.1.50; Argument at point not being highlighted in eldoc hints
Previous Next
Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>
Date: Tue, 5 Jul 2016 15:27:01 UTC
Severity: normal
Found in version 25.1.50
Done: Kaushal Modi <kaushal.modi <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Here's some more debug ..
If you eval the below (completely override eldoc-minibuffer-message for
debug purpose):
(defun eldoc-minibuffer-message (format-string &rest args)
"Display messages in the mode-line when in the minibuffer.
Otherwise work like `message'."
(setq args '(#("0123456789" 0 5 (face font-lock-keyword-face))))
(let ((message-log-max 1000))
(message "debug: format-string = %S" format-string)
(message "debug: args = %S" args))
(unless (minibufferp)
(apply 'message format-string args)))
Then while in emacs-lisp-mode, with cursor after any keyword like defun or
setq or anything will show "0123456789" in the echo area. BUT the whole
face will be font-lock-keyword-face instead of just the first five chars.
Image: http://i.imgur.com/1tsp1rt.png
Here's the outcome of the same eldoc-minibuffer-message hack in emacs-25
build
http://i.imgur.com/1TfRxpx.png
This time, the first 5 chars only have the font-lock-keyword-face as
expected.
Now back to the master build, when I evaluate the below:
(let ((format-string "%s")
(args '(#("0123456789" 0 5 (face font-lock-keyword-face)))))
(apply #'message format-string args))
I get:
#("0123456789" 0 10 (face font-lock-keyword-face))
!! Notice that the end point 5 got updated to 10 by itself !!
On emacs-25 build, evalling the same keeps the end point at 5.
====
An unrelated thing, elisp related, that I don't understand is that
- The face-formatted string shown in the minibuffer when "(apply 'message
format-string args)" is called in the eldoc-minibuffer-message function.
- But "#("0123456789" 0 10 (face font-lock-keyword-face))" (in master
build) is shown verbatim without any face-formatting in the minibuffer when
the above let form (which has the exact same apply form with the exact same
message arguments) is evaluated.
Why is that?
Nonetheless this difference in behavior when evaluating let form is what
made me realize that the message function returns the end pointer updated
from 5 to 10 in the master build.
--
--
Kaushal Modi
[Message part 2 (text/html, inline)]
This bug report was last modified 8 years and 319 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.