From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ernesto Alfonso Newsgroups: gmane.emacs.bugs Subject: bug#32676: Feature request Date: Thu, 13 Sep 2018 11:18:13 -0700 Message-ID: References: <20180910050802.25922-1-erjoalgo@gmail.com> <83a7ollcq2.fsf@gnu.org> <874let1o3k.fsf@gmail.com> <831s9xl54b.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009b51f40575c4bb16" X-Trace: blaine.gmane.org 1536862655 24495 195.159.176.226 (13 Sep 2018 18:17:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Sep 2018 18:17:35 +0000 (UTC) Cc: rpluim@gmail.com, 32676@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 13 20:17:31 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g0WBG-0006GC-MA for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Sep 2018 20:17:30 +0200 Original-Received: from localhost ([::1]:43825 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0WDN-0006HB-0k for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Sep 2018 14:19:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g0WDB-0006EH-8I for bug-gnu-emacs@gnu.org; Thu, 13 Sep 2018 14:19:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g0WCv-0007bi-Ky for bug-gnu-emacs@gnu.org; Thu, 13 Sep 2018 14:19:21 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35325) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g0WCk-0007Xm-RI for bug-gnu-emacs@gnu.org; Thu, 13 Sep 2018 14:19:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g0WCk-0000XL-HY for bug-gnu-emacs@gnu.org; Thu, 13 Sep 2018 14:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ernesto Alfonso Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Sep 2018 18:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32676 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 32676-submit@debbugs.gnu.org id=B32676.15368627142017 (code B ref 32676); Thu, 13 Sep 2018 18:19:02 +0000 Original-Received: (at 32676) by debbugs.gnu.org; 13 Sep 2018 18:18:34 +0000 Original-Received: from localhost ([127.0.0.1]:39583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g0WCH-0000WT-JU for submit@debbugs.gnu.org; Thu, 13 Sep 2018 14:18:34 -0400 Original-Received: from mail-wr1-f42.google.com ([209.85.221.42]:39196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g0WCF-0000WF-7i for 32676@debbugs.gnu.org; Thu, 13 Sep 2018 14:18:31 -0400 Original-Received: by mail-wr1-f42.google.com with SMTP id s14-v6so7375689wrw.6 for <32676@debbugs.gnu.org>; Thu, 13 Sep 2018 11:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YaQUWZ/hz27OHDQ8UScOBE2UMDCAwUU7uIe0XZ1sySA=; b=TXS46nAcgBXLrAJb3d86QnxjKztlfq4Y0Cf1vx3G8k+crnI7JnXkbKcFMvoN4GWdCd fRx6aAmvvIAaIeQn6W8RH7dXrm2IdYV83l4/8Ud6YJlfrVEkc8SuLaFDhVT8n+3s/9+7 UlFYZxjkfo9b1xEkcH4lJjJDh+tbEfA1W+jl3jfJ4WLct8qO5Vf2TNQIruN4V+OQmlxJ doq+8FdBvCzP9aKwvNZ9/HYWvxWJTubcjI6auV84cGiwO2ighHQOH5mfl4jVhkaAuKOw iLI7Jz7OtgAxRaWLZpd5RazCDsk7af4rqfuo4EkmbpFxtZUZvhokEnJhGt51mGe11lIV P2PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YaQUWZ/hz27OHDQ8UScOBE2UMDCAwUU7uIe0XZ1sySA=; b=BAqM/BLLhVbcnWAsOfhywHOZRGjEqC+nNx/m7129iVC7/nkKs4/1daEjoeoV8xTbfw djsPh9wy3PnCBODAP61lcTETXyZ03on8C5CgOOekHSvl5urAmX0Alm+dqgMODHqlaBpM TBT0MNuxQdymZyJZh11Hlr04a8xmtcP3rp4rnUCnI39cVp68nC2MarNEnrj3R8tiP1sI VMPakgCs4yeKgugfXWDHHnmLIvGa9odLsuTGTTGedRTqO7YFk8M2gV7/Pl/QYI8GTNKB nAb7/6s4FAQVrGHqv/z8LtbFxuA3kvitvOF6d3PGJSpFlz1Vz1lEReWrZifwVnngECTc 4woA== X-Gm-Message-State: APzg51DFfJJxqMdjE+2ozyrfiJc2GUKejOnkeCTAvbAKsMOu4WpZIg2E OxClxIOt/3IQJJ4+Wt6dIAIINboUu1uja3OsZ4A= X-Google-Smtp-Source: ANB0VdYnsss/x6FHcHLP2+BP8hYabaflCYB0BWjOgHIk85HfqTJWP9li4DNSQLU2qW0YAb+06szIba8uIwqPCas/2zA= X-Received: by 2002:adf:b202:: with SMTP id u2-v6mr6269185wra.19.1536862705109; Thu, 13 Sep 2018 11:18:25 -0700 (PDT) In-Reply-To: <831s9xl54b.fsf@gnu.org> 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:150295 Archived-At: --0000000000009b51f40575c4bb16 Content-Type: text/plain; charset="UTF-8" > You should be able to fix this problem by setting > hl-line-range-function to a suitable function (which should be quite > simple, AFAIU). Not really. I tried, setting hl-line-range-function to the next-error buffer message line after turning on hl-line: > (with-current-buffer next-error-last-buffer > (make-variable-buffer-local 'hl-line-range-function) > (setf hl-line-range-function > (lambda () > (save-excursion > (goto-char compilation-current-error) > (let ((range > (cons (line-beginning-position) (line-end-position)))) > (message "hl-line-range-function caled. range is %s" range) > range))))) See gif below where hl-line-function is not called after commands invoked outside of the next-error buffer: highlight-line.gif > Basically, the difference is that hl-line uses post-command-hooks to track the current line and put an overlay > on it, whereas in this case highlighting only changes whenever next-error-hook is invoked. >> >> Is this really important? Those are just implementation details, no? No, this is exactly the reason why hl-line-range-function doesn't work in the above example. These are different concepts with different hooks involved that are invoked under different conditions. post-command-hook means hook is invoked after movement commands, which should not affect err msg line highlighting, it also means that it may not necessarily be invoked upon next-error. hl-line-mode hooks: > (if hl-line-mode > (progn > ;; In case `kill-all-local-variables' is called. > (add-hook 'change-major-mode-hook #'hl-line-unhighlight nil t) > (hl-line-highlight) > (setq hl-line-overlay-buffer (current-buffer)) > (add-hook 'post-command-hook #'hl-line-highlight nil t) > (add-hook 'post-command-hook #'hl-line-maybe-unhighlight nil t)) > (remove-hook 'post-command-hook #'hl-line-highlight t) > (hl-line-unhighlight) > (remove-hook 'change-major-mode-hook #'hl-line-unhighlight t) > (remove-hook 'post-command-hook #'hl-line-maybe-unhighlight t))) Whereas for this enhancement, the only event that affects highlight region is next-error. Additionally, hl-line and error message highlight and face should be independent: the user may want current-line highlighting in addition to error message highlighting. Ernesto On Thu, Sep 13, 2018, 9:44 AM Eli Zaretskii wrote: > > From: Ernesto Alfonso > > Date: Thu, 13 Sep 2018 08:02:48 -0700 > > Cc: Eli Zaretskii , 32676@debbugs.gnu.org > > > > The problem is that there are two independent* markers, point, and a > marker at the beginning of the current > > error line in the next error buffer, for example > compilation-current-error, where the fringe arrow is displayed. > > > > In the same way that the user can move around the point in the > next-error buffer between calls to > > {next,previous}-error without affecting the location of the fringe > arrow, the user should also be able to move > > point around without affecting highlighting of the current error message > (for example, to kill part of an error > > message in the compilation buffer), since this is really a visual > enhancement to the fringe arrow. > > You should be able to fix this problem by setting > hl-line-range-function to a suitable function (which should be quite > simple, AFAIU). > > > Another problem with hl-line is what the original poster pointed out in > the screenshot below: hl-line only > > highlights on the current buffer's window, so if the user were to switch > to the source code buffer (or if he > > wasn't there in the first place, e.g. by having invokied next-error form > the source code buffer via a key > > binding) then highlighting of error messages is either lost or never > happens. > > This is only true for the global-hl-line-mode; the local mode's > highlight is "sticky" by default, and shows even in non-selected > windows. > > Moreover, you can customize the global mode so that its highlight is > sticky as well (not that I see why would you want to in this case). > > > Basically, the difference is that hl-line uses post-command-hooks to > track the current line and put an overlay > > on it, whereas in this case highlighting only changes whenever > next-error-hook is invoked. > > Is this really important? Those are just implementation details, no? > --0000000000009b51f40575c4bb16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> You should be able to = fix this problem by setting
> hl-line-range-function to a suit= able function (which should be quite
> simple, AFAIU).

Not really. I tried, setting hl-line-range-function= to the next-error
buffer message line after turning on hl-line:<= /div>

> (with-current-buffer next-error-last-buffer
>=C2=A0 =C2=A0 =C2=A0(make-variable-buffer-local 'hl-line-r= ange-function)
>=C2=A0 =C2=A0 =C2=A0(setf hl-line-range-functi= on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda ()
<= div>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(save-excursion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(goto-cha= r compilation-current-error)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0(let ((range
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (cons (line-beginning-= position) (line-end-position))))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(message "hl-line-range-function cal= ed. range is %s" range)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0range)))))

See gif = below where hl-line-function is not called after commands invoked outside o= f the next-error buffer:



> Basically, the difference is that = hl-line uses post-command-hooks to track the current line and put an overla= y
> on it, whereas in this case highlighting only changes when= ever next-error-hook is invoked.
>>
>> Is t= his really important?=C2=A0 Those are just implementation details, no?

No, this is exactly the reason why hl-line-range= -function doesn't work in the above example. These are
differ= ent concepts with different hooks involved that are invoked under different= conditions.

post-command-hook means hook is invok= ed after movement commands, which should not affect err msg line
= highlighting, it also means that it may not necessarily be invoked upon nex= t-error.=C2=A0

hl-line-mode hooks:
>= =C2=A0 =C2=A0(if hl-line-mode
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(pro= gn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0;; In case `kill-all-loc= al-variables' is called.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(add-hook 'change-major-mode-hook #'hl-line-unhighlight nil t)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(hl-line-highlight)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq hl-line-overlay-buffer (curre= nt-buffer))
>=C2=A0 (add-hook 'post-command-hook #'hl-line-highlight nil t)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(add-hook 'post-command-hook #&#= 39;hl-line-maybe-unhighlight nil t))
>=C2=A0 =C2=A0 =C2=A0(rem= ove-hook 'post-command-hook #'hl-line-highlight t)
>= =C2=A0 =C2=A0 =C2=A0(hl-line-unhighlight)
>=C2=A0 =C2=A0 =C2= =A0(remove-hook 'change-major-mode-hook #'hl-line-unhighlight t)
>=C2=A0 =C2=A0 =C2=A0(remove-hook 'post-command-hook #'h= l-line-maybe-unhighlight t)))

Whereas for this enh= ancement, the only event that affects highlight region is next-error.
=

Additionally, hl-line and error message highlight and f= ace should be independent:
the user may want current-line highlig= hting in addition to error message highlighting.


= Ernesto
On Thu, Sep 13, 2018, 9:44 AM Eli Zaretskii <eliz@gnu.org> wrote:
erjoalgo= @gmail.com>
> Date: Thu, 13 Sep 2018 08:02:48 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>,= 32676@debbugs.gnu.org
>
> The problem is that there are two independent* markers, point, and a m= arker at the beginning of the current
> error line in the next error buffer, for example compilation-current-e= rror, where the fringe arrow is displayed.
>
> In the same way that the user can move around the point in the next-er= ror buffer between calls to
> {next,previous}-error without affecting the location of the fringe arr= ow, the user should also be able to move
> point around without affecting highlighting of the current error messa= ge (for example, to kill part of an error
> message in the compilation buffer), since this is really a visual enha= ncement to the fringe arrow.=C2=A0

You should be able to fix this problem by setting
hl-line-range-function to a suitable function (which should be quite
simple, AFAIU).

> Another problem with hl-line is what the original poster pointed out i= n the screenshot below: hl-line only
> highlights on the current buffer's window, so if the user were to = switch to the source code buffer (or if he
> wasn't there in the first place, e.g. by having invokied next-erro= r form the source code buffer via a key
> binding) then highlighting of error messages is either lost or never h= appens.

This is only true for the global-hl-line-mode; the local mode's
highlight is "sticky" by default, and shows even in non-selected<= br> windows.

Moreover, you can customize the global mode so that its highlight is
sticky as well (not that I see why would you want to in this case).

> Basically, the difference is that hl-line uses post-command-hooks to t= rack the current line and put an overlay
> on it, whereas in this case highlighting only changes whenever next-er= ror-hook is invoked.

Is this really important?=C2=A0 Those are just implementation details, no?<= br>
--0000000000009b51f40575c4bb16--