bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32676: Feature request


From: Ernesto Alfonso
Subject: bug#32676: Feature request
Date: Thu, 13 Sep 2018 09:14:41 -0700

Replied all to the wrong thread -- removing emacs-devel

On Thu, Sep 13, 2018 at 9:10 AM Ernesto Alfonso <erjoalgo@gmail.com> wrote:
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.


13-Sep-2018-08:41:46.png


global hl line: no highlighting on next-error buffer if it is not current:

global-hl-line.gif

hl-line with next-buffer as current: highlighting not preserved after movement commands
hl-line-scrolling-on-next-buffer.gif

Thanks,

Ernesto

On Thu, Sep 13, 2018 at 12:10 AM Ernesto Alfonso <erjoalgo@gmail.com> wrote:
Dear maintainers,

I recently made feature request along with a patch and sent it to gnu-emacs@gnu.org based on the contributor guidelends.

I wanted to provide a bit more context on the motivation behind this patch.

When scrolling through compilation errors, for some users the small fringe arrow indicator that appears next to the current error in the next-error buffer next to the error message can be hard to find quickly without without strain. I personally often find myself reading the wrong error message when fixing compilation errors.

This enhancement adds a customizable option to highlight the current error message in the next-error buffer in addition to the fringe arrow indicator. This makes for a visually more pleasing experience when locating the next-error current error message.

I include a demo below where I'm scrolling through several errors in a small c++ program.

For the implementation, I used the suggestion in Drew's answer on emacs stackexchange where another user raised the same concern about 2 years ago. 

The new behavior is off by default, and the font used to highlight the errors may also be customized.

Please let me know if the patch can be improved or what are the next steps in this review, and I look forward to this enhancement being part of the next emacs release.

demo.gif

Thanks,

Ernesto

reply via email to

[Prev in Thread] Current Thread [Next in Thread]