GNU bug report logs - #38384
(next|previous)-buffer silent about not switching

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38384 in the body.
You can then email your comments to 38384 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 13:08:12 +0100

[Message part 1 (text/plain, inline)]

Package: emacs
Severity: minor
Tags: patch
X-Debbugs-Cc: rudalics <at> gmx.at

In some circumstances, next-buffer and previous-buffer do not have any
buffer to switch to, and in that case they silently do nothing.  (Strictly
speaking, they call switch-to-(next|prev)-buffer, which do nothing and
return nil).

I think they should throw a user-error, to inform the user about the
situation.

[Message part 2 (text/html, inline)]

[window.patch (application/octet-stream, attachment)]

Message #8 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>, 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 14:42:08 +0100

> In some circumstances, next-buffer and previous-buffer do not have any
> buffer to switch to, and in that case they silently do nothing.  (Strictly
> speaking, they call switch-to-(next|prev)-buffer, which do nothing and
> return nil).
>
> I think they should throw a user-error, to inform the user about the
> situation.

Right.  Please install your patch.

martin

Message #13 received at 38384-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 38384-done <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 15:05:45 +0100

[Message part 1 (text/plain, inline)]

Committed as e495dbea7035bcb1f26ed82f0d56a5abc90974fa

[Message part 2 (text/html, inline)]

Message #16 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 17:42:45 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 26 Nov 2019 13:08:12 +0100
> 
> In some circumstances, next-buffer and previous-buffer do not have any buffer to switch to, and in that case
> they silently do nothing.  (Strictly speaking, they call switch-to-(next|prev)-buffer, which do nothing and return
> nil).
> 
> I think they should throw a user-error, to inform the user about the situation.

Could that disrupt noninteractive calls?

Message #19 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 16:54:56 +0100

[Message part 1 (text/plain, inline)]

On Tue, Nov 26, 2019 at 4:42 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Could that disrupt noninteractive calls?

Yes, that's why added the notice in NEWS in the "Incompatible Lisp Changes".

But, on one hand, programs should perhaps be using
switch-to-(prev|next)-buffer. AFAICS, next-buffer and previous-buffer
aren't even documented in the Elisp manual (they are briefly mentioned in
the Emacs manual).

 And on the other, if code is using (next|prev)-buffer, silently getting
the same buffer is likely a subtle bug anyway. At least now they get notice.

[Message part 2 (text/html, inline)]

Message #22 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 17:00:35 +0100

[Message part 1 (text/plain, inline)]

After a cursory glance, I find only one instance of (next-buffer) called
from elisp in our sources, and it's in mode-line-next-buffer.  And in that
case, clicking on the buffer name in the modeline and getting a message "no
next buffer" seems like an improvement to me over the silent treatment ;-)

[Message part 2 (text/html, inline)]

Message #25 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 18:00:27 +0100

>> Could that disrupt noninteractive calls?
>
> Yes, that's why added the notice in NEWS in the "Incompatible Lisp Changes".
>
> But, on one hand, programs should perhaps be using
> switch-to-(prev|next)-buffer. AFAICS, next-buffer and previous-buffer
> aren't even documented in the Elisp manual (they are briefly mentioned in
> the Emacs manual).
>
>   And on the other, if code is using (next|prev)-buffer, silently getting
> the same buffer is likely a subtle bug anyway. At least now they get notice.

Right.  'previous-buffer' and 'next-buffer' are intended for interactive use
only.  Maybe we should add appropriate warnings to their doc-strings.

martin

Message #28 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 18:00:39 +0100

> After a cursory glance, I find only one instance of (next-buffer) called
> from elisp in our sources, and it's in mode-line-next-buffer.  And in that
> case, clicking on the buffer name in the modeline and getting a message "no
> next buffer" seems like an improvement to me over the silent treatment ;-)

Right again.  The same holds for 'mode-line-previous-buffer'.

martin

Message #31 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 20:03:04 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 26 Nov 2019 16:54:56 +0100
> Cc: 38384 <at> debbugs.gnu.org
> 
> > Could that disrupt noninteractive calls?
> 
> Yes, that's why added the notice in NEWS in the "Incompatible Lisp Changes".

Then how about signaling user-error only in interactive calls?

> But, on one hand, programs should perhaps be using switch-to-(prev|next)-buffer. AFAICS, next-buffer and
> previous-buffer aren't even documented in the Elisp manual (they are briefly mentioned in the Emacs
> manual).
> 
>  And on the other, if code is using (next|prev)-buffer, silently getting the same buffer is likely a subtle bug
> anyway. At least now they get notice.

IMO, if we can improve the diagnostics only in interactive
invocations, we have all the advantages without any disadvantages (and
can move this out of the "incompatible changes" section).

Message #34 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 20:04:19 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 26 Nov 2019 17:00:35 +0100
> Cc: 38384 <at> debbugs.gnu.org
> 
> After a cursory glance, I find only one instance of (next-buffer) called from elisp in our sources, and it's in
> mode-line-next-buffer.  And in that case, clicking on the buffer name in the modeline and getting a message
> "no next buffer" seems like an improvement to me over the silent treatment ;-)

Granted, I'm worried mainly about code outside of the Emacs tree.

Message #37 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 19:23:55 +0100

[Message part 1 (text/plain, inline)]

On Tue, Nov 26, 2019 at 7:04 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> Granted, I'm worried mainly about code outside of the Emacs tree.

Even before my patch, both functions can in some situations signal
user-error without checking for interactive use.

  (cond
   ((window-minibuffer-p)
    (user-error "Cannot switch buffers in minibuffer window"))
   ((eq (window-dedicated-p) t)
    (user-error "Window is strongly dedicated to its buffer"))

[Message part 2 (text/html, inline)]

Message #40 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 20:44:15 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 26 Nov 2019 19:23:55 +0100
> Cc: 38384 <at> debbugs.gnu.org
> 
> On Tue, Nov 26, 2019 at 7:04 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Granted, I'm worried mainly about code outside of the Emacs tree.
> 
> Even before my patch, both functions can in some situations signal user-error without checking for interactive
> use.
> 
>   (cond
>    ((window-minibuffer-p)
>     (user-error "Cannot switch buffers in minibuffer window"))
>    ((eq (window-dedicated-p) t)
>     (user-error "Window is strongly dedicated to its buffer"))

I don't see how this is relevant to the issue at hand, what did I
miss?

Message #43 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 19:51:50 +0100

[Message part 1 (text/plain, inline)]

On Tue, Nov 26, 2019 at 7:44 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> I don't see how this is relevant to the issue at hand, what did I
> miss?

Sorry, I fail to see how could it not be relevant. Lisp code calling
(next|previous)-buffer already has to defend itself against a user-error.
My code just adds one specific case (that of the window's buffer list
having only one buffer) in which user-error is also signaled. Am I missing
something?

[Message part 2 (text/html, inline)]

Message #46 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 21:37:02 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 26 Nov 2019 19:51:50 +0100
> Cc: 38384 <at> debbugs.gnu.org
> 
> > I don't see how this is relevant to the issue at hand, what did I
> > miss?
> 
> Sorry, I fail to see how could it not be relevant. Lisp code calling (next|previous)-buffer already has to defend
> itself against a user-error. My code just adds one specific case (that of the window's buffer list having only one
> buffer) in which user-error is also signaled. Am I missing something?

We previously signaled user-error in situations where we couldn't
continue at all.  Your addition is in a situation where nothing
particularly bad happened, so from the POV of a caller, we are now
signaling a user-error gratuitously.  I'm bothered only by the change
whereby we signal a user-error with the purpose of attracting the
user's attention, not because we cannot continue.

Message #49 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 20:56:42 +0100

[Message part 1 (text/plain, inline)]

On Tue, Nov 26, 2019 at 8:36 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> We previously signaled user-error in situations where we couldn't
> continue at all.  Your addition is in a situation where nothing
> particularly bad happened, so from the POV of a caller, we are now
> signaling a user-error gratuitously.  I'm bothered only by the change
> whereby we signal a user-error with the purpose of attracting the
> user's attention, not because we cannot continue.

I don't really see much difference.

In the two cases that already signal user-error, "continuing" would mean
doing nothing; there would be no other bad consequence. In the case I've
changed, continuing means the same: doing nothing. In all three cases,
signaling, instead of continuing, is purely to attract the user's attention.

In my opinion, such code should call switch-to-(prev|next)-buffer instead.

Anyway, there's no point in arguing this; if you feel strongly that the
last case should depend on called-interactively-p, I'll change it. But I
think we should instead leave it as it is and educate code writers to use
the documented calls instead of the user-level commands.

[Message part 2 (text/html, inline)]

Message #52 received at 38384 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 38384 <at> debbugs.gnu.org
Subject: Re: bug#38384: (next|previous)-buffer silent about not switching
Date: Tue, 26 Nov 2019 22:07:35 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 26 Nov 2019 20:56:42 +0100
> Cc: 38384 <at> debbugs.gnu.org
> 
> > We previously signaled user-error in situations where we couldn't
> > continue at all.  Your addition is in a situation where nothing
> > particularly bad happened, so from the POV of a caller, we are now
> > signaling a user-error gratuitously.  I'm bothered only by the change
> > whereby we signal a user-error with the purpose of attracting the
> > user's attention, not because we cannot continue.
> 
> I don't really see much difference.

Well, I do.

> Anyway, there's no point in arguing this; if you feel strongly that the last case should depend on
> called-interactively-p, I'll change it.

Please do, and thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.