|
From: | Ernesto Alfonso |
Subject: | bug#32676: Feature request |
Date: | Fri, 14 Sep 2018 09:40:41 -0700 |
> 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-errorbuffer 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:> 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 aredifferent 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 linehighlighting, 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.ErnestoOn Thu, Sep 13, 2018, 9:44 AM Eli Zaretskii <eliz@gnu.org> wrote:> From: Ernesto Alfonso <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 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?
highlight-line.gif
Description: GIF image
[Prev in Thread] | Current Thread | [Next in Thread] |