bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Dmitry Gutov]

next-error-function in *compile* or *grep* works in a certain way:

- It doesn't open the locations when the *compile* buffer is selected,
  it just jumps between them in that buffer.

- When *compile* is visible but displayed a different window, pressing
  C-x ` will never display the "next error" on top of *compile*. So the
  latter always stays visible.

Neither is true of change-log-next-error.

I think we need more consistency in this.

In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2015-05-02 on axl
Windowing system distributor `The X.Org Foundation', version 11.0.11601901
System Description:	Ubuntu 14.10

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Ted Zlatanov]

On Sun, 03 May 2015 17:04:00 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote: 

DG> next-error-function in *compile* or *grep* works in a certain way:
DG> - It doesn't open the locations when the *compile* buffer is selected,
DG>   it just jumps between them in that buffer.

DG> - When *compile* is visible but displayed a different window, pressing
DG>   C-x ` will never display the "next error" on top of *compile*. So the
DG>   latter always stays visible.

DG> Neither is true of change-log-next-error.

DG> I think we need more consistency in this.

Is the question whether `next-error' should jump to files directly like
a bookmark or jump between navigation bookmarks that then have to be
explicitly activated with RET or something else?

I always prefer the latter, personally.

Ted

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Dmitry Gutov]

On 05/05/2015 01:18 AM, Ted Zlatanov wrote:

> Is the question whether `next-error' should jump to files directly like
> a bookmark or jump between navigation bookmarks that then have to be
> explicitly activated with RET or something else?

I guess it would be hard to create those "bookmarks" in a ChangeLog 
buffer anyway. So maybe this part is not fixable.

The second problem is more of an issue for me, and I don't see any heavy 
obstacles.

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Juri Linkov]

> next-error-function in *compile* or *grep* works in a certain way:
>
> - It doesn't open the locations when the *compile* buffer is selected,
>   it just jumps between them in that buffer.
>
> - When *compile* is visible but displayed a different window, pressing
>   C-x ` will never display the "next error" on top of *compile*. So the
>   latter always stays visible.
>
> Neither is true of change-log-next-error.
>
> I think we need more consistency in this.

This is finally implemented.

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 17 Apr 2018 23:55:06 +0300
> Cc: 20493-done@debbugs.gnu.org
> 
> > next-error-function in *compile* or *grep* works in a certain way:
> >
> > - It doesn't open the locations when the *compile* buffer is selected,
> >   it just jumps between them in that buffer.
> >
> > - When *compile* is visible but displayed a different window, pressing
> >   C-x ` will never display the "next error" on top of *compile*. So the
> >   latter always stays visible.
> >
> > Neither is true of change-log-next-error.
> >
> > I think we need more consistency in this.
> 
> This is finally implemented.

Thanks, but I think the documentation that accompanies these changes
should be augmented/improved:

  . next-error-select-buffer should be documented in the Emacs manual
  . the doc string of next-error-select-buffer should be expanded to
    explain the effect of selecting a buffer.  The current text is
    quite cryptic, IMO: "set it as the last used."  The meaning of
    "last used" in this context should be explained.
  . next-error-find-buffer-function should perhaps be mentioned in the
    Emacs manual and/or the ELisp manual.
  . the doc string of next-error-find-buffer-function should describe
    the arguments with which it is called, what possible values it can
    return, and the meaning of each returned value.

TIA

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Juri Linkov]

>> This is finally implemented.
>
> Thanks, but I think the documentation that accompanies these changes
> should be augmented/improved:
>
>   . next-error-select-buffer should be documented in the Emacs manual
>   . the doc string of next-error-select-buffer should be expanded to
>     explain the effect of selecting a buffer.  The current text is
>     quite cryptic, IMO: "set it as the last used."  The meaning of
>     "last used" in this context should be explained.
>   . next-error-find-buffer-function should perhaps be mentioned in the
>     Emacs manual and/or the ELisp manual.
>   . the doc string of next-error-find-buffer-function should describe
>     the arguments with which it is called, what possible values it can
>     return, and the meaning of each returned value.

Done.  I'll try not to forget about updating the documentation and NEWS
for future changes.

bug#20493: 25.0.50; next-error in change-log-mode can hide its buffer

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 20493@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Sat, 21 Apr 2018 22:53:05 +0300
> 
> >   . next-error-select-buffer should be documented in the Emacs manual
> >   . the doc string of next-error-select-buffer should be expanded to
> >     explain the effect of selecting a buffer.  The current text is
> >     quite cryptic, IMO: "set it as the last used."  The meaning of
> >     "last used" in this context should be explained.
> >   . next-error-find-buffer-function should perhaps be mentioned in the
> >     Emacs manual and/or the ELisp manual.
> >   . the doc string of next-error-find-buffer-function should describe
> >     the arguments with which it is called, what possible values it can
> >     return, and the meaning of each returned value.
> 
> Done.  I'll try not to forget about updating the documentation and NEWS
> for future changes.

Thanks.

When you describe new commands and variables, please make sure they
are indexed (I added index entries for the ones you documented in this
changeset).