From: Ernesto Alfonso <erjoalgo@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rpluim@gmail.com, 32676@debbugs.gnu.org
Subject: bug#32676: Feature request
Date: Thu, 13 Sep 2018 11:18:13 -0700 [thread overview]
Message-ID: <CAOckuXDZAGG=Tz+_xLuxOpFhZoa_XEmu+aR8CEW-EwJZ2yiVWw@mail.gmail.com> (raw)
In-Reply-To: <831s9xl54b.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 4586 bytes --]
> 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@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?
>
[-- Attachment #2: Type: text/html, Size: 7421 bytes --]
next prev parent reply other threads:[~2018-09-13 18:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 5:08 bug#32676: [PATCH] Add option to highlight the 'next-error' error message Ernesto Alfonso
2018-09-13 7:10 ` bug#32676: Feature request Ernesto Alfonso
2018-09-13 13:59 ` Eli Zaretskii
2018-09-13 14:14 ` Robert Pluim
2018-09-13 15:02 ` Ernesto Alfonso
2018-09-13 16:44 ` Eli Zaretskii
2018-09-13 18:18 ` Ernesto Alfonso [this message]
2018-09-14 16:40 ` Ernesto Alfonso
2018-09-15 23:05 ` Juri Linkov
2018-09-16 0:37 ` Ernesto Alfonso
2018-09-16 23:27 ` Juri Linkov
2018-09-18 8:51 ` Ernesto Alfonso
2019-04-07 21:56 ` Ernesto Alfonso
2019-04-08 19:36 ` bug#32676: [PATCH] Add option to highlight the 'next-error' error message Juri Linkov
2019-04-09 5:48 ` Eli Zaretskii
2020-02-29 15:40 ` Stefan Kangas
2020-08-10 12:38 ` Lars Ingebrigtsen
2020-08-10 14:00 ` Ernesto Alfonso
2020-09-03 5:00 ` Ernesto Alfonso
2020-09-03 10:40 ` Stefan Kangas
2020-10-14 5:47 ` Lars Ingebrigtsen
2020-10-14 19:30 ` Juri Linkov
2020-10-15 7:19 ` Lars Ingebrigtsen
2020-10-16 8:13 ` Juri Linkov
2020-10-16 14:48 ` Lars Ingebrigtsen
2020-10-17 20:24 ` Juri Linkov
2020-10-18 8:34 ` Lars Ingebrigtsen
2020-11-05 20:20 ` Juri Linkov
2020-11-05 22:05 ` Kévin Le Gouguec
2020-11-06 8:43 ` Juri Linkov
2020-11-06 22:06 ` bug#32676: Updating Org for 27.2 (was: bug#32676: [PATCH] Add option to highlight the 'next-error' error message) Kévin Le Gouguec
2020-11-09 9:03 ` bug#32676: Updating Org for 27.2 Juri Linkov
2020-11-09 12:17 ` Kévin Le Gouguec
2020-11-10 4:10 ` Kyle Meyer
2020-11-10 19:30 ` Juri Linkov
2020-11-10 20:02 ` Glenn Morris
[not found] ` <CAOckuXD4--GF0E=eMWf-T74rEjrjt4CWfx97OWWszRay3P-ujQ@mail.gmail.com>
2018-09-13 16:14 ` bug#32676: Feature request Ernesto Alfonso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOckuXDZAGG=Tz+_xLuxOpFhZoa_XEmu+aR8CEW-EwJZ2yiVWw@mail.gmail.com' \
--to=erjoalgo@gmail.com \
--cc=32676@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=rpluim@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.