From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.bugs Subject: bug#23897: 25.1.50; Argument at point not being highlighted in eldoc hints Date: Thu, 07 Jul 2016 22:19:19 +0000 Message-ID: References: <577E80BF.7030304@gmx.at> <83h9c1jkrl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ceb945ec2a205371314c6 X-Trace: ger.gmane.org 1467930026 15341 80.91.229.3 (7 Jul 2016 22:20:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2016 22:20:26 +0000 (UTC) Cc: 23897@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 08 00:20:16 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bLHea-0005tU-GA for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Jul 2016 00:20:16 +0200 Original-Received: from localhost ([::1]:42577 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLHeZ-00046T-RF for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Jul 2016 18:20:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLHeR-00044t-Qk for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2016 18:20:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLHeM-0007ox-UM for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2016 18:20:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLHeM-0007os-Qr for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2016 18:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bLHeM-0007Gl-Hc for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2016 18:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kaushal Modi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jul 2016 22:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23897 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23897-submit@debbugs.gnu.org id=B23897.146792997727898 (code B ref 23897); Thu, 07 Jul 2016 22:20:02 +0000 Original-Received: (at 23897) by debbugs.gnu.org; 7 Jul 2016 22:19:37 +0000 Original-Received: from localhost ([127.0.0.1]:41606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLHdx-0007Fu-1N for submit@debbugs.gnu.org; Thu, 07 Jul 2016 18:19:37 -0400 Original-Received: from mail-oi0-f43.google.com ([209.85.218.43]:35676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bLHdv-0007Ff-15 for 23897@debbugs.gnu.org; Thu, 07 Jul 2016 18:19:35 -0400 Original-Received: by mail-oi0-f43.google.com with SMTP id r2so42707560oih.2 for <23897@debbugs.gnu.org>; Thu, 07 Jul 2016 15:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TFWNRkvs8JHcHpbzlKDtjNdb5cb+d2yGypTMGQTrypw=; b=krP9uyx6jcgG63I4G2hPyDesBAoLG63wY6nG7m6F47Vkh9dL4ty3bUwKyX3hf6vgL/ HWQhjmkfn0q7x+NjiPwyu/dxTvPfUwvKDEMM/F2cjE/iMwcATjpfT/a4OX6MEP1b/Yjk rNy5RSrJ3Ob6RPkD6mNebc0C8CPiM+HtFUWoQa8Yg7mY5gQHS+4/O9YclW+UucXgk2PP fPCQEHMF8i3TfkDQo7wn1CaMdbhhNI014xLsz31iOOOW5bYffLp58rDFF9Oct+osFuWA aUh8Ojs05VzmTAYofCLDPBV4j/8zPMUC0/wQSUeuHSlgqbSAgnx9Uu1MMMGIXzuDlTNS krHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TFWNRkvs8JHcHpbzlKDtjNdb5cb+d2yGypTMGQTrypw=; b=hfkv993emLT3osFImfIbe0KNEogzEDINRkqQZrQHzmpoPDaxa/VnatMbVHqvtgGO20 r7FRFXoU3Jjk/pJBeMooTaIgpyaREK7BCTYkvjx0N8hsP+jgWYbHN5EVUxsKoKbI1jzv tiK7g1M2HGAJg+jRU//q3t1bF82QCFf1mXneUG/5tKzFHOOwVG15MSKSmoUb6EZUcmsm wvRpKk5+XzM8Zr/dtIxzOhG/KnhKRuoksm2Py4AZlIfUnuuTWWwZlmJL5KJHLDrScvv6 aXOVQcxrTrkOaKKC2j28m7EnUbZ9rnak6NWmMgHbh7Ltb5GVaq9szyvIgRWINphe/9+e sPYw== X-Gm-Message-State: ALyK8tK23ggoUoP1oSnMYv8VmmoVjQombSl0sm1gPl0TX8vzW05SFvKR5uyTNjkBaW4EyOdhSe6yp9Vvz+mRyg== X-Received: by 10.202.172.146 with SMTP id v140mr1530555oie.98.1467929969212; Thu, 07 Jul 2016 15:19:29 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120608 Archived-At: --001a113ceb945ec2a205371314c6 Content-Type: text/plain; charset=UTF-8 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 --001a113ceb945ec2a205371314c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here's some more debug ..

If you ev= al the below (completely override eldoc-minibuffer-message for debug purpos= e):

(defun eldoc-minibuffer-message (format-s= tring &rest args)
=C2=A0 "Display messages in the mode-l= ine when in the minibuffer.
Otherwise work like `message'.&qu= ot;
=C2=A0 (setq args '(#("0123456789" 0 5 (face fo= nt-lock-keyword-face))))
=C2=A0 (let ((message-log-max 1000))
=C2=A0 =C2=A0 (message "debug: format-string =3D %S" forma= t-string)
=C2=A0 =C2=A0 (message "debug: args =3D %S" a= rgs))
=C2=A0 (unless (minibufferp)
=C2=A0 =C2=A0 (apply= 'message format-string args)))

Then whi= le 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 f= ace will be font-lock-keyword-face instead of just the first five chars.

Here's the outcome of t= he same eldoc-minibuffer-message hack in emacs-25 build

This time, the fi= rst 5 chars only have the font-lock-keyword-face as expected.

Now back to the master build, when I evaluate th= e below:

(let ((format-string "%s")=
=C2=A0 =C2=A0 =C2=A0 (args '(#("0123456789" 0 5 (f= ace font-lock-keyword-face)))))
=C2=A0 (apply #'message forma= t-string args))

I get:

<= div>#("0123456789" 0 10 (face font-lock-keyword-face))
<= div>
!! Notice that the end point 5 got updated to 10 by itse= lf !!

On emacs-25 build, evalling the same keeps t= he end point at 5.

=3D=3D=3D=3D

An unrelated thing, elisp related, that I don't understand is th= at=C2=A0

- The face-formatted string shown in the = minibuffer when "(apply 'message f= ormat-string args)" is called in the eldoc-minibuffer-message function= .
- But "#("0123456789" 0 10 (face font-lock-ke= yword-face))" (in master build) is shown verbatim without any face-for= matting in the minibuffer when the above let form (which has the exact same= apply form with the exact same message arguments) is evaluated.=C2=A0
=C2=A0
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.=C2=A0=C2= =A0

--

--
Kaushal Modi

--001a113ceb945ec2a205371314c6--