bug#32676: [PATCH] Add option to highlight the 'next-error' error message

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Ernesto Alfonso]

In addition to a fringe arrow, ‘next-error’ error may optionally
highlight the current error message in the ‘next-error’ buffer.
---
 doc/emacs/building.texi |  2 ++
 etc/NEWS                |  5 +++++
 lisp/simple.el          | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 41 insertions(+)

diff --git a/doc/emacs/building.texi b/doc/emacs/building.texi
index 496c4275bc..e0d14c14d8 100644
--- a/doc/emacs/building.texi
+++ b/doc/emacs/building.texi
@@ -199,6 +199,8 @@ Compilation Mode
 @kindex M-g n
 @kindex C-x `
 @findex next-error
+@findex next-error-message
+@vindex next-error-message-highlight-p
 @vindex next-error-highlight
   To visit errors sequentially, type @w{@kbd{C-x `}}
 (@code{next-error}), or equivalently @kbd{M-g M-n} or @kbd{M-g n}.
diff --git a/etc/NEWS b/etc/NEWS
index ff65a5520d..a8d3400d8f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -607,6 +607,11 @@ error.
 It can be used to set any buffer as the next one to be used by
 'next-error' and 'previous-error'.
 
++++
+*** New customizable variable 'next-error-message-highlight-p'
+In addition to a fringe arrow, ‘next-error’ error may now optionally
+highlight the current error message in the ‘next-error’ buffer.
+
 ** nxml-mode
 
 ---
diff --git a/lisp/simple.el b/lisp/simple.el
index 0ccf2f1d22..c1298965cc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -105,6 +105,23 @@ next-error-recenter
   :group 'next-error
   :version "23.1")
 
+(defcustom next-error-message-highlight-p nil
+  "If non-nil, highlight the current error message in the ‘next-error’ buffer"
+  :type 'boolean
+  :group 'next-error
+  :version "27.1")
+
+(defface next-error-message
+  '((t (:inherit highlight)))
+  "Face used to highlight the current error message in the ‘next-error’ buffer"
+  :group 'next-error
+  :version "27.1")
+
+(defvar next-error-message-highlight-overlay
+  nil
+  "Overlay highlighting the current error message in the ‘next-error’ buffer")
+(make-variable-buffer-local 'next-error-message-highlight-overlay)
+
 (defcustom next-error-hook nil
   "List of hook functions run by `next-error' after visiting source file."
   :type 'hook
@@ -421,6 +438,23 @@ next-error-follow-mode-post-command-hook
 	  (next-error-no-select 0))
       (error t))))
 
+(defun next-error-message-highlight ()
+  "Highlight the current error message in the ‘next-error’ buffer."
+  (when next-error-message-highlight-p
+    (with-current-buffer next-error-last-buffer
+      (when next-error-message-highlight-overlay
+        (delete-overlay next-error-message-highlight-overlay))
+      (save-excursion
+        (goto-char compilation-current-error)
+        (let ((ol (make-overlay (line-beginning-position) (line-end-position))))
+          ;; do not override region highlighting
+          (overlay-put ol 'priority -50)
+          (overlay-put ol 'face 'next-error-message)
+          (overlay-put ol 'window (get-buffer-window))
+          (setf next-error-message-highlight-overlay ol))))))
+
+(add-hook 'next-error-hook 'next-error-message-highlight)
+
 \f
 ;;;
 
-- 
2.11.0

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1.1: Type: text/plain, Size: 1397 bytes --]

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
<https://emacs.stackexchange.com/a/13137/2846> 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.

[image: demo.gif]

Thanks,

Ernesto

[-- Attachment #1.2: Type: text/html, Size: 1927 bytes --]

[-- Attachment #2: demo.gif --]
[-- Type: image/gif, Size: 442888 bytes --]

bug#32676: Feature request

[Eli Zaretskii]

[Please don't cross-post to emacs-devel.]

> From: Ernesto Alfonso <erjoalgo@gmail.com>
> Date: Thu, 13 Sep 2018 00:10:09 -0700
> 
> I recently made feature request along with a patch and sent it to gnu-emacs@gnu.org based on the
> contributor guidelends.

Thank you for your contribution.

I didn't yet have time to review your changes in detail, but one
question immediately popped up in my mind: why not use hl-line for
this?  I believe this was suggested in the stackexchange discussion,
but for some reason not followed up.

bug#32676: Feature request

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

> [Please don't cross-post to emacs-devel.]
>
>> From: Ernesto Alfonso <erjoalgo@gmail.com>
>> Date: Thu, 13 Sep 2018 00:10:09 -0700
>> 
>> I recently made feature request along with a patch and sent it to gnu-emacs@gnu.org based on the
>> contributor guidelends.
>
> Thank you for your contribution.
>
> I didn't yet have time to review your changes in detail, but one
> question immediately popped up in my mind: why not use hl-line for
> this?  I believe this was suggested in the stackexchange discussion,
> but for some reason not followed up.

Iʼve been using display-line-numbers + line-number-current-line face
for this, but hl-line works even better.

Robert

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1.1: Type: text/plain, Size: 2087 bytes --]

Hi Eli,

I first tried using hl-line, and my patch did use hl-line as a reference.

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.

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.

Below is an example of diverging point and compilation-current-error
markers:


[image: 13-Sep-2018-07:41:28.png]

*Markers can be independent until 'next-error is invoked, which moves point
to the next error, but they can diverge between calls to next-error.

Thanks,

Ernesto

On Thu, Sep 13, 2018 at 7:14 AM Robert Pluim <rpluim@gmail.com> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> > [Please don't cross-post to emacs-devel.]
> >
> >> From: Ernesto Alfonso <erjoalgo@gmail.com>
> >> Date: Thu, 13 Sep 2018 00:10:09 -0700
> >>
> >> I recently made feature request along with a patch and sent it to
> gnu-emacs@gnu.org based on the
> >> contributor guidelends.
> >
> > Thank you for your contribution.
> >
> > I didn't yet have time to review your changes in detail, but one
> > question immediately popped up in my mind: why not use hl-line for
> > this?  I believe this was suggested in the stackexchange discussion,
> > but for some reason not followed up.
>
> Iʼve been using display-line-numbers + line-number-current-line face
> for this, but hl-line works even better.
>
> Robert
>

[-- Attachment #1.2: Type: text/html, Size: 3000 bytes --]

[-- Attachment #2: 13-Sep-2018-07:41:28.png --]
[-- Type: image/png, Size: 50299 bytes --]

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1.1: Type: text/plain, Size: 2455 bytes --]

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.
>
>
> [image: 13-Sep-2018-08:41:46.png]
>
>
> global hl line: no highlighting on next-error buffer if it is not current:
>
> [image: global-hl-line.gif]
>
> hl-line with next-buffer as current: highlighting not preserved after
> movement commands
> [image: 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
>> <https://emacs.stackexchange.com/a/13137/2846> 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.
>>
>> [image: demo.gif]
>>
>> Thanks,
>>
>> Ernesto
>>
>

[-- Attachment #1.2: Type: text/html, Size: 3739 bytes --]

[-- Attachment #2: global-hl-line.gif --]
[-- Type: image/gif, Size: 488685 bytes --]

[-- Attachment #3: hl-line-scrolling-on-next-buffer.gif --]
[-- Type: image/gif, Size: 449293 bytes --]

[-- Attachment #4: 13-Sep-2018-08:41:46.png --]
[-- Type: image/png, Size: 30270 bytes --]

bug#32676: Feature request

[Eli Zaretskii]

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

bug#32676: Feature request

[Ernesto Alfonso]

[-- 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 --]

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1.1: Type: text/plain, Size: 4994 bytes --]

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@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@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 #1.2: Type: text/html, Size: 7932 bytes --]

[-- Attachment #2: highlight-line.gif --]
[-- Type: image/gif, Size: 730363 bytes --]

bug#32676: Feature request

[Juri Linkov]

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

Do I understand correctly that your proposed feature is like next-error-highlight,
but instead of highlighting the error locus, it highlights the error message?
Then I don't understand how it relates to compilation-highlight-regexp and
compilation-highlight-overlay?

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

>
>
> Do I understand correctly that your proposed feature is like
> next-error-highlight,
> but instead of highlighting the error locus, it highlights the error
> message?

Yes, although I don't think it's important to support a timer to turn off
highlighting like next-error-highlight does since the error locus
highlighting might get in the user's way in source buffers, but not in the
next-error buffer.

 Then I don't understand how it relates to compilation-highlight-regexp and
> compilation-highlight-overlay?


I don't see a reference to compilation-highlight-regexp or
compilation-highlight-overlay in my patch or in this thread. Although I did
use compilation-current-error to find the mark at the error message
location, which I think is not appropriate since that would be
compilation-specific, and I think it should be (point) instead. Is this
what you mean?

Ernesto



On Sat, Sep 15, 2018 at 4:49 PM Juri Linkov <juri@linkov.net> wrote:

> > 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.
>
> Do I understand correctly that your proposed feature is like
> next-error-highlight,
> but instead of highlighting the error locus, it highlights the error
> message?
> Then I don't understand how it relates to compilation-highlight-regexp and
> compilation-highlight-overlay?
>

[-- Attachment #2: Type: text/html, Size: 2151 bytes --]

bug#32676: Feature request

[Juri Linkov]

>> Do I understand correctly that your proposed feature is like
>> next-error-highlight,
>> but instead of highlighting the error locus, it highlights the error
>> message?
>
> Yes, although I don't think it's important to support a timer to turn off
> highlighting like next-error-highlight does since the error locus
> highlighting might get in the user's way in source buffers, but not in the
> next-error buffer.

I agree that a timer is not necessary in next-error-last-buffer.
I just wanted to emphasize that your new customization could be like
next-error-highlight defcustom (but without a timer option).

> I don't see a reference to compilation-highlight-regexp or
> compilation-highlight-overlay in my patch or in this thread. Although I did
> use compilation-current-error to find the mark at the error message
> location, which I think is not appropriate since that would be
> compilation-specific, and I think it should be (point) instead. Is this
> what you mean?

I guess you need to highlight exactly the same place from where
the error was visited.  It looks like (point) is always located
at this place because compilation-next-error-function sets
overlay-arrow-position to (point-marker), so it should be the
right place to highlight indeed.

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]

> I agree that a timer is not necessary in next-error-last-buffer.
> I just wanted to emphasize that your new customization could be like
> next-error-highlight defcustom (but without a timer option).

Yes.

It looks like (point) is always located
> at this place because compilation-next-error-function sets
> overlay-arrow-position to (point-marker), so it should be the
> right place to highlight indeed.

Yes. I tried replacing compilation-current-error with point and it works as
expected. I am not sure how I would update the patch.


While searching for this thread, I came across another time qhwn a user
made a query for the same feature I am proposing.

https://groups.google.com/forum/#!topic/gnu.emacs.help/q1QucyB1Nzw

It provides another explanation of why hl-line doesn't work well in this
case.

Ernesto
On Sun, Sep 16, 2018 at 4:38 PM Juri Linkov <juri@linkov.net> wrote:

> >> Do I understand correctly that your proposed feature is like
> >> next-error-highlight,
> >> but instead of highlighting the error locus, it highlights the error
> >> message?
> >
> > Yes, although I don't think it's important to support a timer to turn off
> > highlighting like next-error-highlight does since the error locus
> > highlighting might get in the user's way in source buffers, but not in
> the
> > next-error buffer.
>
> I agree that a timer is not necessary in next-error-last-buffer.
> I just wanted to emphasize that your new customization could be like
> next-error-highlight defcustom (but without a timer option).
>
> > I don't see a reference to compilation-highlight-regexp or
> > compilation-highlight-overlay in my patch or in this thread. Although I
> did
> > use compilation-current-error to find the mark at the error message
> > location, which I think is not appropriate since that would be
> > compilation-specific, and I think it should be (point) instead. Is this
> > what you mean?
>
> I guess you need to highlight exactly the same place from where
> the error was visited.  It looks like (point) is always located
> at this place because compilation-next-error-function sets
> overlay-arrow-position to (point-marker), so it should be the
> right place to highlight indeed.
>

[-- Attachment #2: Type: text/html, Size: 3206 bytes --]

bug#32676: Feature request

[Ernesto Alfonso]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

I'd like to know if this patch is still being considered?

Ernesto

On Tue, Sep 18, 2018 at 1:51 AM Ernesto Alfonso <erjoalgo@gmail.com> wrote:

>
> I agree that a timer is not necessary in next-error-last-buffer.
>> I just wanted to emphasize that your new customization could be like
>> next-error-highlight defcustom (but without a timer option).
>
> Yes.
>
> It looks like (point) is always located
>> at this place because compilation-next-error-function sets
>> overlay-arrow-position to (point-marker), so it should be the
>> right place to highlight indeed.
>
> Yes. I tried replacing compilation-current-error with point and it works
> as expected. I am not sure how I would update the patch.
>
>
> While searching for this thread, I came across another time qhwn a user
> made a query for the same feature I am proposing.
>
> https://groups.google.com/forum/#!topic/gnu.emacs.help/q1QucyB1Nzw
>
> It provides another explanation of why hl-line doesn't work well in this
> case.
>
> Ernesto
> On Sun, Sep 16, 2018 at 4:38 PM Juri Linkov <juri@linkov.net> wrote:
>
>> >> Do I understand correctly that your proposed feature is like
>> >> next-error-highlight,
>> >> but instead of highlighting the error locus, it highlights the error
>> >> message?
>> >
>> > Yes, although I don't think it's important to support a timer to turn
>> off
>> > highlighting like next-error-highlight does since the error locus
>> > highlighting might get in the user's way in source buffers, but not in
>> the
>> > next-error buffer.
>>
>> I agree that a timer is not necessary in next-error-last-buffer.
>> I just wanted to emphasize that your new customization could be like
>> next-error-highlight defcustom (but without a timer option).
>>
>> > I don't see a reference to compilation-highlight-regexp or
>> > compilation-highlight-overlay in my patch or in this thread. Although I
>> did
>> > use compilation-current-error to find the mark at the error message
>> > location, which I think is not appropriate since that would be
>> > compilation-specific, and I think it should be (point) instead. Is this
>> > what you mean?
>>
>> I guess you need to highlight exactly the same place from where
>> the error was visited.  It looks like (point) is always located
>> at this place because compilation-next-error-function sets
>> overlay-arrow-position to (point-marker), so it should be the
>> right place to highlight indeed.
>>
>

[-- Attachment #2: Type: text/html, Size: 3717 bytes --]

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Juri Linkov]

> I'd like to know if this patch is still being considered?

Why not?  Your patch provides a helpful feature.  I see only 2 problems
with its latest version:

1. compilation-current-error should be generalized not to be too
   compilation-specific;

2. next-error-hook should not be used for core features,
   you could call next-error-message-highlight directly
   from next-error-found.

PS: maybe a better name for defcustom would be next-error-message-highlight,
    not next-error-message-highlight-p, to be more future-proof,
    for the case when someone might want to add more choices later
    (e.g. fringe, timers, etc.)

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Robert Pluim <rpluim@gmail.com>,  32676@debbugs.gnu.org
> Date: Mon, 08 Apr 2019 22:36:38 +0300
> 
> > I'd like to know if this patch is still being considered?
> 
> Why not?  Your patch provides a helpful feature.  I see only 2 problems
> with its latest version:
> 
> 1. compilation-current-error should be generalized not to be too
>    compilation-specific;
> 
> 2. next-error-hook should not be used for core features,
>    you could call next-error-message-highlight directly
>    from next-error-found.

3. A contribution this size needs legal paperwork for us to be able to
accept it.  Ernesto, would you like to start the paperwork now?

Thanks.

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Stefan Kangas]

Hi Ernesto,

To accept your contribution to Emacs, we need to you to assign
copyright to the FSF.  You can read more about the reasons why here:
https://www.gnu.org/licenses/why-assign.html

Before we can make any progress with this patch, I think we need to
clarify that point.  Would you be willing to sign such paperwork?

Thanks in advance.

Best regards,
Stefan Kangas

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Robert Pluim <rpluim@gmail.com>,  32676@debbugs.gnu.org
>> Date: Mon, 08 Apr 2019 22:36:38 +0300
>> 
>> > I'd like to know if this patch is still being considered?
>> 
>> Why not?  Your patch provides a helpful feature.  I see only 2 problems
>> with its latest version:
>> 
>> 1. compilation-current-error should be generalized not to be too
>>    compilation-specific;
>> 
>> 2. next-error-hook should not be used for core features,
>>    you could call next-error-message-highlight directly
>>    from next-error-found.
>
> 3. A contribution this size needs legal paperwork for us to be able to
> accept it.  Ernesto, would you like to start the paperwork now?
>
> Thanks.

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> To accept your contribution to Emacs, we need to you to assign
> copyright to the FSF.  You can read more about the reasons why here:
> https://www.gnu.org/licenses/why-assign.html
>
> Before we can make any progress with this patch, I think we need to
> clarify that point.  Would you be willing to sign such paperwork?

This was half a year ago, and I can't see Ernesto in the copyright
assignment file.

Ernesto?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Ernesto Alfonso]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

Sorry about the delay, I will get back to this soon.

Ernesto

On Mon, Aug 10, 2020 at 5:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stefan Kangas <stefan@marxist.se> writes:
>
> > To accept your contribution to Emacs, we need to you to assign
> > copyright to the FSF.  You can read more about the reasons why here:
> > https://www.gnu.org/licenses/why-assign.html
> >
> > Before we can make any progress with this patch, I think we need to
> > clarify that point.  Would you be willing to sign such paperwork?
>
> This was half a year ago, and I can't see Ernesto in the copyright
> assignment file.
>
> Ernesto?
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 1340 bytes --]

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Ernesto Alfonso]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

I currently work for Google, and my understanding is that Google has a
special agreement with the FSF. Please let me know if this is correct or if
I still need to provide a copyright assignment.

Also, I am not sure if this patch is still applicable.

Thanks,

Ernesto

On Mon, Aug 10, 2020 at 10:00 AM Ernesto Alfonso <erjoalgo@gmail.com> wrote:

> Sorry about the delay, I will get back to this soon.
>
> Ernesto
>
> On Mon, Aug 10, 2020 at 5:38 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
>> Stefan Kangas <stefan@marxist.se> writes:
>>
>> > To accept your contribution to Emacs, we need to you to assign
>> > copyright to the FSF.  You can read more about the reasons why here:
>> > https://www.gnu.org/licenses/why-assign.html
>> >
>> > Before we can make any progress with this patch, I think we need to
>> > clarify that point.  Would you be willing to sign such paperwork?
>>
>> This was half a year ago, and I can't see Ernesto in the copyright
>> assignment file.
>>
>> Ernesto?
>>
>> --
>> (domestic pets only, the antidote for overdose, milk.)
>>    bloggy blog: http://lars.ingebrigtsen.no
>>
>

[-- Attachment #2: Type: text/html, Size: 2054 bytes --]

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Stefan Kangas]

Hi Ernesto,

Thanks for following up on this.

Ernesto Alfonso <erjoalgo@gmail.com> writes:

> I currently work for Google, and my understanding is that Google has a
> special agreement with the FSF. Please let me know if this is correct
> or if I still need to provide a copyright assignment.

Someone else will have to answer this.

> Also, I am not sure if this patch is still applicable.

In what way?  From reading the discussion, it seems like the feature was
considered useful, but there were some additional comments before it was
ready.  I copied in those comments below.  Could you have a look at
them?

Thanks in advance.

Juri Linkov <juri@linkov.net> writes:

>> I'd like to know if this patch is still being considered?
>
> Why not?  Your patch provides a helpful feature.  I see only 2 problems
> with its latest version:
>
> 1. compilation-current-error should be generalized not to be too
>    compilation-specific;
>
> 2. next-error-hook should not be used for core features,
>    you could call next-error-message-highlight directly
>    from next-error-found.
>
> PS: maybe a better name for defcustom would be next-error-message-highlight,
>     not next-error-message-highlight-p, to be more future-proof,
>     for the case when someone might want to add more choices later
>     (e.g. fringe, timers, etc.)

Best regards,
Stefan Kangas

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> I'd like to know if this patch is still being considered?
>
> Why not?  Your patch provides a helpful feature.  I see only 2 problems
> with its latest version:

I've now applied the patch (after reworking slightly), and it seems to
work well, so I've pushed it to Emacs 28.

> 1. compilation-current-error should be generalized not to be too
>    compilation-specific;

Reading the code, it looks like that variable is always set, even in
grep buffers and the like?  So it's a bad name, but...

Is there a different variable that should be used instead?

> 2. next-error-hook should not be used for core features,
>    you could call next-error-message-highlight directly
>    from next-error-found.

Fixes.

> PS: maybe a better name for defcustom would be next-error-message-highlight,
>     not next-error-message-highlight-p, to be more future-proof,
>     for the case when someone might want to add more choices later
>     (e.g. fringe, timers, etc.)

And this.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Juri Linkov]

> I've now applied the patch (after reworking slightly), and it seems to
> work well, so I've pushed it to Emacs 28.
>
>> 1. compilation-current-error should be generalized not to be too
>>    compilation-specific;
>
> Reading the code, it looks like that variable is always set, even in
> grep buffers and the like?  So it's a bad name, but...

Unsurprisingly, now using occur fails with the error

  next-error-found: Symbol’s value as variable is void: compilation-current-error

and when compile.el is loaded, occur fails with the error

  next-error-found: Wrong type argument: integer-or-marker-p, nil

This fails only when next-error-message-highlight is customized to t,
so there is no need to revert the patch, but it should be fixed ASAP.

> Is there a different variable that should be used instead?

I can't find another variable.  Maybe a new variable should be created,
with a name like next-error-current.

Then compilation-current-error could be declared as an obsolete alias.
Or maybe there is no need to remove the old variable, so they both
could be used: compilation-current-error in compilation-mode,
and next-error-current elsewhere.

PS: I see compilation-current-error is used also in
next-error-follow-mode-post-command-hook, and it works fine
when 'C-c C-f' (next-error-follow-minor-mode)
in enabled in occur buffers.

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Is there a different variable that should be used instead?
>
> I can't find another variable.  Maybe a new variable should be created,
> with a name like next-error-current.

Re-reading the code, we don't really need the variable at all.  The call
to the highlighting function has been moved into the C-x ` command,
after all, so we already know what buffer to use, and where point is.

So I've now changed this to just highlight the current line in the
"error buffer", which seems to work fine in the couple of use cases I
tried.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

>>> Is there a different variable that should be used instead?
>>
>> I can't find another variable.  Maybe a new variable should be created,
>> with a name like next-error-current.
>
> Re-reading the code, we don't really need the variable at all.  The call
> to the highlighting function has been moved into the C-x ` command,
> after all, so we already know what buffer to use, and where point is.
>
> So I've now changed this to just highlight the current line in the
> "error buffer", which seems to work fine in the couple of use cases I
> tried.

Simplicity is the hallmark of truth :-)

Surprisingly, this feature works everywhere, even in diff-mode.
But when using next-error on an empty line in diff-mode, its highlighting
is too short to notice - only 1 character wide.  Maybe the next-error-message
face should extend to the end of the window like hl-line-mode face does?

I tried to add the attribute ':extend t' to the next-error-message face,
but it has no effect.  Maybe because currently highlighting is not added
to the trailing newline.  Indeed, with this patch it works:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: next-error-message-extend.patch --]
[-- Type: text/x-diff, Size: 928 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index bd19969341..97f6d4837e 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -125,7 +125,7 @@ next-error-message-highlight
   :version "28.1")
 
 (defface next-error-message
-  '((t (:inherit highlight)))
+  '((t (:inherit highlight :extend t)))
   "Face used to highlight the current error message in the `next-error' buffer."
   :group 'next-error
   :version "28.1")
@@ -484,7 +484,7 @@ next-error-message-highlight
     (with-current-buffer error-buffer
       (when next-error--message-highlight-overlay
         (delete-overlay next-error--message-highlight-overlay))
-      (let ((ol (make-overlay (line-beginning-position) (line-end-position))))
+      (let ((ol (make-overlay (line-beginning-position) (1+ (line-end-position)))))
         ;; do not override region highlighting
         (overlay-put ol 'priority -50)
         (overlay-put ol 'face 'next-error-message)

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> I tried to add the attribute ':extend t' to the next-error-message face,
> but it has no effect.  Maybe because currently highlighting is not added
> to the trailing newline.  Indeed, with this patch it works:

Makes sense; go ahead and apply.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

>> I tried to add the attribute ':extend t' to the next-error-message face,
>> but it has no effect.  Maybe because currently highlighting is not added
>> to the trailing newline.  Indeed, with this patch it works:
>
> Makes sense; go ahead and apply.

Now pushed.  After a day of using it, I realized this feature paved the way
to another very useful feature: when the highlighting overlay is not removed
after going to the next occurrence, and leaves the highlighting
on all visited lines, this provides an overview what lines were
already visited, and what lines not yet visited - like visited links
are highlighted differently in browsers.  This patch builds this feature
on the top of the initial patch:


[-- Attachment #2: next-error-message-highlight-keep.patch --]
[-- Type: text/x-diff, Size: 1354 bytes --]

diff --git a/lisp/simple.el b/lisp/simple.el
index 97f6d4837e..c2e5ff4c5a 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -119,8 +119,12 @@ next-error-recenter
   :version "23.1")
 
 (defcustom next-error-message-highlight nil
-  "If non-nil, highlight the current error message in the `next-error' buffer."
-  :type 'boolean
+  "If non-nil, highlight the current error message in the `next-error' buffer.
+If the value is `keep', highlighting is permanent, so all visited error
+messages are highlighted; this helps to see what messages were visited."
+  :type '(choice (const :tag "Highlight the current error" t)
+                 (const :tag "Highlight all visited errors" keep)
+                 (const :tag "No highlighting" nil))
   :group 'next-error
   :version "28.1")
 
@@ -482,7 +486,8 @@ next-error-message-highlight
   "Highlight the current error message in the ‘next-error’ buffer."
   (when next-error-message-highlight
     (with-current-buffer error-buffer
-      (when next-error--message-highlight-overlay
+      (when (and next-error--message-highlight-overlay
+                 (not (eq next-error-message-highlight 'keep)))
         (delete-overlay next-error--message-highlight-overlay))
       (let ((ol (make-overlay (line-beginning-position) (1+ (line-end-position)))))
         ;; do not override region highlighting

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Now pushed.  After a day of using it, I realized this feature paved the way
> to another very useful feature: when the highlighting overlay is not removed
> after going to the next occurrence, and leaves the highlighting
> on all visited lines, this provides an overview what lines were
> already visited, and what lines not yet visited - like visited links
> are highlighted differently in browsers.

That sounds like a good idea.  Go ahead and push, if you haven't
already.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Juri Linkov]

> I tried to add the attribute ':extend t' to the next-error-message face,
> but it has no effect.  Maybe because currently highlighting is not added
> to the trailing newline.  Indeed, with this patch it works:
>
> diff --git a/lisp/simple.el b/lisp/simple.el
>  (defface next-error-message
> -  '((t (:inherit highlight)))
> +  '((t (:inherit highlight :extend t)))

BTW, I noticed that org-mode has a special variable that
puts the face over the trailing newlines for headings.
I propose to mention in the docstring that it's possibly
to extend the face:

diff --git a/lisp/org/org.el b/lisp/org/org.el
index 1ab8ab6888..c1b8ec9d24 100644
--- a/lisp/org/org.el
+++ b/lisp/org/org.el
@@ -3685,7 +3685,8 @@ org-fontify-emphasized-text
 (defcustom org-fontify-whole-heading-line nil
   "Non-nil means fontify the whole line for headings.
 This is useful when setting a background color for the
-org-level-* faces."
+org-level-* faces and extending it to the edge of the window
+by using the face attribute `:extend'."
   :group 'org-appearance
   :type 'boolean)
 

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Kévin Le Gouguec]

Juri Linkov <juri@linkov.net> writes:

> BTW, I noticed that org-mode has a special variable that
> puts the face over the trailing newlines for headings.
> I propose to mention in the docstring that it's possibly
> to extend the face:

Please see bug#42184 and the related discussion on emacs-orgmode[1]:
this has been fixed (by adding the :extend attribute to the heading
faces when the variable is set, in addition to putting this face on the
newline) in the latest patch version of Org 9.3, which (fingers crossed)
should make it to Emacs 27.2.

[1] https://orgmode.org/list/87r1tez9dx.fsf_-_@gmail.com/

bug#32676: [PATCH] Add option to highlight the 'next-error' error message

[Juri Linkov]

>> BTW, I noticed that org-mode has a special variable that
>> puts the face over the trailing newlines for headings.
>> I propose to mention in the docstring that it's possibly
>> to extend the face:
>
> Please see bug#42184 and the related discussion on emacs-orgmode[1]:
> this has been fixed (by adding the :extend attribute to the heading
> faces when the variable is set, in addition to putting this face on the
> newline) in the latest patch version of Org 9.3, which (fingers crossed)
> should make it to Emacs 27.2.
>
> [1] https://orgmode.org/list/87r1tez9dx.fsf_-_@gmail.com/

Thanks, hope it will be released in Emacs 27.2,
also waiting when it will arrive to Emacs 28.

BTW, could you suggest how a background color can be set
to all org-level-faces at once, not each face separately?
Should something like this be added to the init file:

  (mapc (lambda (f) (set-face-background f "gray95")) org-level-faces)

or something simpler is available?

bug#32676: Updating Org for 27.2 (was: bug#32676: [PATCH] Add option to highlight the 'next-error' error message)

[Kévin Le Gouguec]

Juri Linkov <juri@linkov.net> writes:

> Thanks, hope it will be released in Emacs 27.2,
> also waiting when it will arrive to Emacs 28.

With 9.3.8 (released in September), Org 9.3 is as stable as it well ever
be, since the maintenance branch is now 9.4.  So AFAIK it's "just" a
matter for Org maintainers to find some time to update Org on the
emacs-27 branch.

(I filed bug#43268 because I'd love all those bugfixes to land in 27.2;
I don't know if there's anything more I can do to help.  Worg has
extensive documentation[1] about the synchronization process so I guess
I could try to make a patch, but I don't know how useful that would be;
the process seems to have its share of pitfalls[2]…)

> BTW, could you suggest how a background color can be set
> to all org-level-faces at once, not each face separately?
> Should something like this be added to the init file:
>
>   (mapc (lambda (f) (set-face-background f "gray95")) org-level-faces)
>
> or something simpler is available?

I'm not aware of anything simpler, sorry :/ (but I haven't spent that
much time hacking on Org, so I might have missed something…)


[1] https://code.orgmode.org/bzg/worg/src/c63e53f7b1245d36ab30cbdc685a92ca9fca277e/org-maintenance.org#synchronization-org-and-upstream-emacs

[2] Cf. e.g. 2020-11-02 "Recover the contents of the schemas.xml file"
    (cd69a50648)

bug#32676: Updating Org for 27.2

[Juri Linkov]

>> Thanks, hope it will be released in Emacs 27.2,
>> also waiting when it will arrive to Emacs 28.
>
> With 9.3.8 (released in September), Org 9.3 is as stable as it well ever
> be, since the maintenance branch is now 9.4.  So AFAIK it's "just" a
> matter for Org maintainers to find some time to update Org on the
> emacs-27 branch.
>
> (I filed bug#43268 because I'd love all those bugfixes to land in 27.2;
> I don't know if there's anything more I can do to help.  Worg has
> extensive documentation[1] about the synchronization process so I guess
> I could try to make a patch, but I don't know how useful that would be;
> the process seems to have its share of pitfalls[2]…)

Do you know if the synchronization process will override the changes
made in master?  If I fix an issue in bug#44524 and will commit the fix
to Emacs master in the subdir emacs/lisp/org, won't the synchronization
process of the recent Org version override my fix?

bug#32676: Updating Org for 27.2

[Kévin Le Gouguec]

Juri Linkov <juri@linkov.net> writes:

> Do you know if the synchronization process will override the changes
> made in master?  If I fix an issue in bug#44524 and will commit the fix
> to Emacs master in the subdir emacs/lisp/org, won't the synchronization
> process of the recent Org version override my fix?

The document I referred to covers this situation (§ Backporting changes
from upstream Emacs), but I don't know if there are automated checks in
place to make sure no commits are missed.

IIUC, Org maintainers prefer for changes to be submitted to
emacs-orgmode@gnu.org; they only occasionally dive into
bug-gnu-emacs@gnu.org to look for open Org issues.

bug#32676: Updating Org for 27.2

[Kyle Meyer]

Kévin Le Gouguec writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> Do you know if the synchronization process will override the changes
>> made in master?  If I fix an issue in bug#44524 and will commit the fix
>> to Emacs master in the subdir emacs/lisp/org, won't the synchronization
>> process of the recent Org version override my fix?
>
> The document I referred to covers this situation (§ Backporting changes
> from upstream Emacs), but I don't know if there are automated checks in
> place to make sure no commits are missed.

No, there's not.  I check at least once a week and propagate (or
otherwise deal with) any commits from the Emacs repo that touch Org
files.  I have a fairly dumb system for it, but I think it's worked well
enough [*] in terms of catching commits.  It's essentially just a
command (described in the document you're referring to, I believe) that
does

    git log <last commit ported>..<branch> -- <org files>

to get a list of commits that go into an Org checklist.  The
occasionally time consuming part is dealing with the conflicts and with
commits on Emacs's end that don't maintain compatibility with the
minimal Emacs version that Org supports.

  [*] That's not to say that I think the current system of porting and
      then syncing via manual copying is a good one.  I look forward to
      $something better, but in the meantime things need to stay afloat.

At any rate, since 2015, I have notes on all the commits considered.  I
moved these from my personal notes repo to a dedicated repo in 2019.  In
case it's helpful, I've just pushed it to
<https://git.kyleam.com/orgmode-backport-notes/>.

If you're worried a commit didn't get considered, you can first check in
the Org repo with

  $ git log --grep=<full commit ID from Emacs repo>

since the commit messages use a consistent format that includes the full
hash.  As an example:

    Backport commit dd16e46bb from Emacs

    ; Prefer https to http in more URLs
    dd16e46bb9d0099baea06d780ad8f62728addc2e
    Stefan Kangas
    Sat Oct 24 20:23:27 2020 +0200

If you don't see it there, you can look into the notes file referred to
above, which should contain some information about why the commit wasn't
applied and what was done instead (with an Org commit reference).  (Now
that it's public, going forward I'll try to make the descriptions a
little less of a brain dump.)

That said...

> IIUC, Org maintainers prefer for changes to be submitted to
> emacs-orgmode@gnu.org; they only occasionally dive into
> bug-gnu-emacs@gnu.org to look for open Org issues.

...submitting patches on the Org list is of course appreciated,
particularly for things that target Org rather than being part of a
tree-wide cleanup.

bug#32676: Updating Org for 27.2

[Juri Linkov]

> The document I referred to covers this situation (§ Backporting changes
> from upstream Emacs), but I don't know if there are automated checks in
> place to make sure no commits are missed.
>
> IIUC, Org maintainers prefer for changes to be submitted to
> emacs-orgmode@gnu.org; they only occasionally dive into
> bug-gnu-emacs@gnu.org to look for open Org issues.

Thanks for pointing to emacs-orgmode@gnu.org.  Surprisingly, I see
my bug report on the Org list, maybe this is because I added

  Package: emacs,org-mode

to the bug report.  Since there is no reply to my bug report, I pushed
the fix to Emacs master as commit 79d04ae13f.  Thanks to Kyle
we don't have to worry about the commit arriving to the Org repo.

Whereas it seems fine to fix bugs in the Emacs repo, submitting
patches for new features indeed needs to be discussed on the Org list.

bug#32676: Updating Org for 27.2

[Glenn Morris]

Juri Linkov wrote:

> Thanks for pointing to emacs-orgmode@gnu.org.  Surprisingly, I see
> my bug report on the Org list, maybe this is because I added
>
>   Package: emacs,org-mode
>
> to the bug report.

I don't know what you thought adding a Package line to a bug report does,
but it sends the report to the maintainers of the specified package(s).

This was stated in the acknowledgement email that was sent to you:
https://debbugs.gnu.org/cgi/bugreport.cgi?msg=4;bug=44524

Org-mode is defined as a debbugs.gnu package with address emacs-orgmode@gnu.org.
It has been for years, but there was never any interest shown from the
Org side in using it, and now they have their own bug system (of course).
I see no reason for anyone to report Org issues to bug-gnu-emacs.