GNU bug report logs -
#32676
[PATCH] Add option to highlight the 'next-error' error message
Previous Next
Reported by: Ernesto Alfonso <erjoalgo <at> gmail.com>
Date: Mon, 10 Sep 2018 05:24:02 UTC
Severity: wishlist
Tags: fixed, patch
Fixed in version 28.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #29 received at 32676 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Attaching the last gif as an inline/attachment instead of an external link.
This was the attempt to use hl-line-range-function. It did not work for me.
On Thu, Sep 13, 2018 at 11:18 AM Ernesto Alfonso <erjoalgo <at> gmail.com> wrote:
> > 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
> <https://drive.google.com/file/d/0ByCqoLLtc4gqSS1pZTQ2WGZWdHI5Qml6MTd1MUFSQm45WjFF/view?usp=drivesdk>
>
>
>
>
>
> > 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 <eliz <at> gnu.org> wrote:
>
>> > From: Ernesto Alfonso <erjoalgo <at> gmail.com>
>> > Date: Thu, 13 Sep 2018 08:02:48 -0700
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>, 32676 <at> 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?
>>
>
[Message part 2 (text/html, inline)]
[highlight-line.gif (image/gif, attachment)]
This bug report was last modified 4 years and 251 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.