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