bug#23897: 25.1.50; Argument at point not being highlighted in eldoc hints

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 07 Jul 2016 22:19:19 +0000
> Cc: 23897@debbugs.gnu.org, rudalics@gmx.at, dgutov@yandex.ru
> 
> Here's some more debug ..

Thanks.

For the future, please always try to find the simplest way to
demonstrate a problem, and preferably as close to the lowest-level
function that still exhibits it.  In particular, various fancy
constructs using 'apply', 'funcall', let alone cl-lib stuff are a
distraction that should only be present if the problem doesn't show
without them.

Specifically, in this case, the simplest way to demonstrate the
problem is this:

  (format "%s" (concat (propertize "01234" 'face 'bold) "56789"))
    => #("0123456789" 0 10 (face bold))

Clearly, the "0 10" part is not what is expected.

This has the advantage of showing that the problem is inside the
'format' primitive (you used 'message', but that just calls 'format'
and then displays the result, as you can see from its source).  Also,
propertize is a much simpler way of constructing a string with
properties than using the #("0123456789" 0 5 (face FACE)) read syntax.

> 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?

The "#("0123456789" 0 10 (face font-lock-keyword-face))" stuff doesn't
have the face applied, that's why.  The face will be applied when it
is read by the Lisp reader.

(Avoiding these tricky constructs as much as possible is one way of
not getting distracted by unrelated issues.)

Thanks.