GNU bug report logs - #23131
switch-to-buffer-other-frame problem

Previous Next

Package: emacs;

Reported by: jan <rtm443x <at> googlemail.com>

Date: Sun, 27 Mar 2016 23:38:01 UTC

Severity: minor

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Sun, 27 Mar 2016 23:38:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to jan <rtm443x <at> googlemail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 27 Mar 2016 23:38:02 GMT) Full text and rfc822 format available.

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

From: jan <rtm443x <at> googlemail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: switch-to-buffer-other-frame problem
Date: Mon, 28 Mar 2016 00:37:30 +0100
Running emacs 24.5.1 on windows.

Hi all,
switch-to-buffer-other-frame works but should prompt for the name of
the buffer to switch to. Per the help on that function "If called
interactively, prompt for the buffer name using the minibuffer". Well
it does but then refuses to recognise my buffer by name.

---------

e.g Start emacs, then drag a file (say sample.txt) onto it. File opens fine.

Type C-x 5 b

- minibuffer shows
"Switch to buffer in other frame (default *GNU Emacs*): "

I type "sam" [tab key for completion]

- minibuffer says
"Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]"

odd. If I remove the "sam" I just typed then type '?' to show the
buffer list, it opens a 2nd buffer at the bottom and shows

Possible completions are:
*GNU Emacs*
*Messages*
*scratch*

which does not show sample.txt, which is definitly there as I can see
it open in the buffer at the top.

As a workaround, I enter a nonexistent buffer name, the 2nd frame
opens, blank, I then do
C-x b
sam            <- I type this in
[tab for completion]
sample.txt  <- emacs autocompletes this
RET  <- to accept

and sample.txt is now shown in the other frame as I want. But this is
a workaround.

----------------

Having raised this with Eli, he says this is expected behaviour: "Yes,
it's a feature: Emacs doesn't offer you a buffer that is already
displayed in an existing window.  This was introduced in Emacs 24."

Well, a) this is not documented (see below) and b) I can't see any
rationale for this behaviour. Hiding this option does not assist the
user in any way I can see.

Also, the behaviour is apparently broken if the current buffer/window is split:

a. open sample.txt
b. C-x 2   -- split window in 2, top and bottom
c. C-x 5 b  -- try to get 2nd frame
d. sample.txt   -- type in full filename in minibuffer
e. 2nd frame does *not* appear, cursor jumps to top of split window,
even if was originally in bottom.

can reproduce?

jan


I said this behaviour isn't documented that I can see. Here's the full
docs for this function. It says nothing about hiding the current
buffer name:

-------
switch-to-buffer-other-frame is an interactive compiled Lisp function
in `window.el'.

It is bound to C-x 5 b.

(switch-to-buffer-other-frame BUFFER-OR-NAME &optional NORECORD)

Switch to buffer BUFFER-OR-NAME in another frame.
BUFFER-OR-NAME may be a buffer, a string (a buffer name), or
nil.  Return the buffer switched to.

If called interactively, prompt for the buffer name using the
minibuffer.  The variable `confirm-nonexistent-file-or-buffer'
determines whether to request confirmation before creating a new
buffer.

If BUFFER-OR-NAME is a string and does not identify an existing
buffer, create a new buffer with that name.  If BUFFER-OR-NAME is
nil, switch to the buffer returned by `other-buffer'.

Optional second arg NORECORD non-nil means do not put this
buffer at the front of the list of recently selected ones.

This uses the function `display-buffer' as a subroutine; see its
documentation for additional customization information.
-------




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Mon, 28 Mar 2016 11:23:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: jan <rtm443x <at> googlemail.com>, 23131 <at> debbugs.gnu.org
Subject: Re: bug#23131: switch-to-buffer-other-frame problem
Date: Mon, 28 Mar 2016 13:22:46 +0200
> e.g Start emacs, then drag a file (say sample.txt) onto it. File opens fine.
>
> Type C-x 5 b
>
> - minibuffer shows
> "Switch to buffer in other frame (default *GNU Emacs*):"
>
> I type "sam" [tab key for completion]
>
> - minibuffer says
> "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]"
>
> odd. If I remove the "sam" I just typed then type '?' to show the
> buffer list, it opens a 2nd buffer at the bottom and shows
>
> Possible completions are:
> *GNU Emacs*
> *Messages*
> *scratch*
>
> which does not show sample.txt, which is definitly there as I can see
> it open in the buffer at the top.

If, in this situation, you type C-x b, Emacs won't offer you sample.txt
as completion either.  Ditto for ‘switch-to-buffer-other-window’.  It's
difficult to say what the correct behavior should be.  I never use the
buffer switching commands, so I have no preference.  But I suppose that
some people would complain if C-x b offered them the buffer already
shown in the selected window as possible completion.  So where would you
draw the line?

Basically, to switch to a buffer already shown in a window W, I wouldn't
type C-x b but use C-x o to get there.  To show the buffer shown in W in
another window on the same frame, I'd type C-x 2 in W.  To show the
buffer shown in W in a window on another frame, I'd type C-x 5 2 in W.

> Also, the behaviour is apparently broken if the current buffer/window is split:
>
> a. open sample.txt
> b. C-x 2   -- split window in 2, top and bottom
> c. C-x 5 b  -- try to get 2nd frame
> d. sample.txt   -- type in full filename in minibuffer
> e. 2nd frame does *not* appear, cursor jumps to top of split window,
> even if was originally in bottom.
>
> can reproduce?

Why don't you just use C-x 5 2 here?  Anyway, this happens because of
the last two forms in

(defvar display-buffer--other-frame-action
  '((display-buffer-reuse-window
     display-buffer-pop-up-frame)
    (reusable-frames . 0)
    (inhibit-same-window . t))

which OT1H inhibit using the selected window and OTOH, since we have no
value for ‘reusable-frames’ to exclude the selected frame from the list
of reusable frames, allows reusing the window on the bottom.

If people think that it's worth fixing this, we would probably have to
invent a new alist entry like ‘inhibit-same-frame’.  That change might
be obtrusive though, so I would not ardently recommend it for emacs-25.

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Tue, 29 Mar 2016 08:36:02 GMT) Full text and rfc822 format available.

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

From: jan <rtm443x <at> googlemail.com>
To: martin rudalics <rudalics@-gmx.at>
Cc: 23131 <at> debbugs.gnu.org
Subject: Re: bug#23131: switch-to-buffer-other-frame problem
Date: Tue, 29 Mar 2016 09:35:16 +0100
Hi Martin,
please see below

On 28/03/2016, martin rudalics <rudalics <at> gmx.at> wrote:
>  > e.g Start emacs, then drag a file (say sample.txt) onto it. File opens
> fine.
>  >
>  > Type C-x 5 b
>  >
>  > - minibuffer shows
>  > "Switch to buffer in other frame (default *GNU Emacs*):"
>  >
>  > I type "sam" [tab key for completion]
>  >
>  > - minibuffer says
>  > "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]"
>  >
>  > odd. If I remove the "sam" I just typed then type '?' to show the
>  > buffer list, it opens a 2nd buffer at the bottom and shows
>  >
>  > Possible completions are:
>  > *GNU Emacs*
>  > *Messages*
>  > *scratch*
>  >
>  > which does not show sample.txt, which is definitly there as I can see
>  > it open in the buffer at the top.
>
> If, in this situation, you type C-x b, Emacs won't offer you sample.txt
> as completion either.  Ditto for ‘switch-to-buffer-other-window’.

I'd say that replication doesn't justify the behaviour.

> It's
> difficult to say what the correct behavior should be.  I never use the
> buffer switching commands, so I have no preference.  But I suppose that
> some people would complain if C-x b offered them the buffer already
> shown in the selected window as possible completion.

Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a
feature: Emacs doesn't offer you a buffer that is already displayed in
an existing window.  This was introduced in Emacs 24."

So it is new behaviour.
Therefore: 1) was it introduced deliberately? If so, why? (if the code
was the code made more complex by introducing a special case rather
than simplifiying it, doubly why?)

And: 2) this behaviour is not documented. My understanding is that
documentation omissions are considered bugs.

> So where would you draw the line?

To me it's about interface usability and stability.  Given the answer
to point (1), I'd be in a much better position to know where to draw
the line.

>
> Basically, to switch to a buffer already shown in a window W, I wouldn't
> type C-x b but use C-x o to get there.  To show the buffer shown in W in
> another window on the same frame, I'd type C-x 2 in W.  To show the
> buffer shown in W in a window on another frame, I'd type C-x 5 2 in W.
>
>  > Also, the behaviour is apparently broken if the current buffer/window is
> split:
>  >
>  > a. open sample.txt
>  > b. C-x 2   -- split window in 2, top and bottom
>  > c. C-x 5 b  -- try to get 2nd frame
>  > d. sample.txt   -- type in full filename in minibuffer
>  > e. 2nd frame does *not* appear, cursor jumps to top of split window,
>  > even if was originally in bottom.
>  >
>  > can reproduce?
>
> Why don't you just use C-x 5 2 here?

Heh. I'd forgotten that! Thanks!
But that doesn't change the original point of why the new behaviour.

> Anyway, this happens because of
> the last two forms in
>
> (defvar display-buffer--other-frame-action
>    '((display-buffer-reuse-window
>       display-buffer-pop-up-frame)
>      (reusable-frames . 0)
>      (inhibit-same-window . t))
>
> which OT1H inhibit using the selected window and OTOH, since we have no
> value for ‘reusable-frames’ to exclude the selected frame from the list
> of reusable frames, allows reusing the window on the bottom.
>
> If people think that it's worth fixing this, we would probably have to
> invent a new alist entry like ‘inhibit-same-frame’.  That change might
> be obtrusive though, so I would not ardently recommend it for emacs-25.

I don't know much about emacs internals so I'll buy the point that a
'fix' would be unnecessary work for the dev team for this case.

thanks

jan

>
> martin
>
>




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Tue, 29 Mar 2016 08:39:02 GMT) Full text and rfc822 format available.

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

From: jan <rtm443x <at> googlemail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 23131 <at> debbugs.gnu.org
Subject: Re: bug#23131: switch-to-buffer-other-frame problem
Date: Tue, 29 Mar 2016 09:38:37 +0100
Hi Martin,
please see below

On 28/03/2016, martin rudalics <rudalics <at> gmx.at> wrote:
>  > e.g Start emacs, then drag a file (say sample.txt) onto it. File opens
> fine.
>  >
>  > Type C-x 5 b
>  >
>  > - minibuffer shows
>  > "Switch to buffer in other frame (default *GNU Emacs*):"
>  >
>  > I type "sam" [tab key for completion]
>  >
>  > - minibuffer says
>  > "Switch to buffer in other frame (default *GNU Emacs*): sam[No Match]"
>  >
>  > odd. If I remove the "sam" I just typed then type '?' to show the
>  > buffer list, it opens a 2nd buffer at the bottom and shows
>  >
>  > Possible completions are:
>  > *GNU Emacs*
>  > *Messages*
>  > *scratch*
>  >
>  > which does not show sample.txt, which is definitly there as I can see
>  > it open in the buffer at the top.
>
> If, in this situation, you type C-x b, Emacs won't offer you sample.txt
> as completion either.  Ditto for ‘switch-to-buffer-other-window’.

I'd say that replication of (arguably questionable) behaviour doesn't
justify it.

> It's
> difficult to say what the correct behavior should be.  I never use the
> buffer switching commands, so I have no preference.  But I suppose that
> some people would complain if C-x b offered them the buffer already
> shown in the selected window as possible completion.

Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a
feature: Emacs doesn't offer you a buffer that is already displayed in
an existing window.  This was introduced in Emacs 24."

So it is new behaviour.
Therefore: 1) was it introduced deliberately? If so, why? (if the code
was the code made more complex by introducing a special case rather
than simplifiying it, doubly why?)

And: 2) this behaviour is not documented. My understanding is that
documentation omissions are considered bugs.

> So where would you draw the line?

To me it's about interface usability and stability.  Given the answer
to point (1), I'd be in a much better position to know where to draw
the line.

>
> Basically, to switch to a buffer already shown in a window W, I wouldn't
> type C-x b but use C-x o to get there.  To show the buffer shown in W in
> another window on the same frame, I'd type C-x 2 in W.  To show the
> buffer shown in W in a window on another frame, I'd type C-x 5 2 in W.
>
>  > Also, the behaviour is apparently broken if the current buffer/window is
> split:
>  >
>  > a. open sample.txt
>  > b. C-x 2   -- split window in 2, top and bottom
>  > c. C-x 5 b  -- try to get 2nd frame
>  > d. sample.txt   -- type in full filename in minibuffer
>  > e. 2nd frame does *not* appear, cursor jumps to top of split window,
>  > even if was originally in bottom.
>  >
>  > can reproduce?
>
> Why don't you just use C-x 5 2 here?

Heh. I'd forgotten that! Thanks!
But that doesn't change the original point of why the new behaviour.

> Anyway, this happens because of
> the last two forms in
>
> (defvar display-buffer--other-frame-action
>    '((display-buffer-reuse-window
>       display-buffer-pop-up-frame)
>      (reusable-frames . 0)
>      (inhibit-same-window . t))
>
> which OT1H inhibit using the selected window and OTOH, since we have no
> value for ‘reusable-frames’ to exclude the selected frame from the list
> of reusable frames, allows reusing the window on the bottom.
>
> If people think that it's worth fixing this, we would probably have to
> invent a new alist entry like ‘inhibit-same-frame’.  That change might
> be obtrusive though, so I would not ardently recommend it for emacs-25.

I don't know much about emacs internals so I'll buy the point that a
'fix' would be unnecessary work for the dev team for this latter case.

thanks

jan

>
> martin
>
>




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Tue, 29 Mar 2016 15:14:02 GMT) Full text and rfc822 format available.

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

From: martin rudalics <rudalics <at> gmx.at>
To: jan <rtm443x <at> googlemail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 23131 <at> debbugs.gnu.org
Subject: Re: bug#23131: switch-to-buffer-other-frame problem
Date: Tue, 29 Mar 2016 17:13:27 +0200
>> If, in this situation, you type C-x b, Emacs won't offer you sample.txt
>> as completion either.  Ditto for ‘switch-to-buffer-other-window’.
>
> I'd say that replication of (arguably questionable) behaviour doesn't
> justify it.

We'll have to wait until the respective author(s) explain the reasons
for the change.

>> It's
>> difficult to say what the correct behavior should be.  I never use the
>> buffer switching commands, so I have no preference.  But I suppose that
>> some people would complain if C-x b offered them the buffer already
>> shown in the selected window as possible completion.
>
> Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a
> feature: Emacs doesn't offer you a buffer that is already displayed in
> an existing window.  This was introduced in Emacs 24."

IIUC it was introduced in Emacs 23.

> So it is new behaviour.

Relatively so, since I can reproduce it with a seven years old build.
If I'm not mistaken the change is by Juri Linkov from 2008-04-22.

> Therefore: 1) was it introduced deliberately? If so, why? (if the code
> was the code made more complex by introducing a special case rather
> than simplifiying it, doubly why?)
>
> And: 2) this behaviour is not documented. My understanding is that
> documentation omissions are considered bugs.

Juri, what do you think?

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Fri, 01 Apr 2016 19:53:02 GMT) Full text and rfc822 format available.

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

From: Juri Linkov <juri <at> jurta.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jan <rtm443x <at> googlemail.com>, 23131 <at> debbugs.gnu.org
Subject: Re: bug#23131: switch-to-buffer-other-frame problem
Date: Fri, 01 Apr 2016 22:49:32 +0300
>>> If, in this situation, you type C-x b, Emacs won't offer you sample.txt
>>> as completion either.  Ditto for ‘switch-to-buffer-other-window’.
>>
>> I'd say that replication of (arguably questionable) behaviour doesn't
>> justify it.
>
> We'll have to wait until the respective author(s) explain the reasons
> for the change.
>
>>> It's
>>> difficult to say what the correct behavior should be.  I never use the
>>> buffer switching commands, so I have no preference.  But I suppose that
>>> some people would complain if C-x b offered them the buffer already
>>> shown in the selected window as possible completion.
>>
>> Well, Eli Zaretski said of this (I'd emailed him first) "Yes, it's a
>> feature: Emacs doesn't offer you a buffer that is already displayed in
>> an existing window.  This was introduced in Emacs 24."
>
> IIUC it was introduced in Emacs 23.
>
>> So it is new behaviour.
>
> Relatively so, since I can reproduce it with a seven years old build.
> If I'm not mistaken the change is by Juri Linkov from 2008-04-22.
>
>> Therefore: 1) was it introduced deliberately? If so, why? (if the code
>> was the code made more complex by introducing a special case rather
>> than simplifiying it, doubly why?)
>>
>> And: 2) this behaviour is not documented. My understanding is that
>> documentation omissions are considered bugs.
>
> Juri, what do you think?

This change was discussed here where you can see all arguments pro and contra:
http://thread.gmane.org/gmane.emacs.devel/93054/focus=95497




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#23131; Package emacs. (Wed, 14 Jul 2021 14:47:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 23131 <at> debbugs.gnu.org,
 jan <rtm443x <at> googlemail.com>
Subject: Re: bug#23131: switch-to-buffer-other-frame problem
Date: Wed, 14 Jul 2021 16:46:24 +0200
Juri Linkov <juri <at> jurta.org> writes:

>>> Therefore: 1) was it introduced deliberately? If so, why? (if the code
>>> was the code made more complex by introducing a special case rather
>>> than simplifiying it, doubly why?)
>>>
>>> And: 2) this behaviour is not documented. My understanding is that
>>> documentation omissions are considered bugs.
>>
>> Juri, what do you think?
>
> This change was discussed here where you can see all arguments pro and contra:
> http://thread.gmane.org/gmane.emacs.devel/93054/focus=95497

So I think this works as designed.  We could perhaps mention
`read-buffer-to-switch' in the interactive case in the doc strings, but
I think that's a level of detail that'd just be counter-productive, so
I'd rather not, and I'm closing this bug report.

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




bug closed, send any further explanations to 23131 <at> debbugs.gnu.org and jan <rtm443x <at> googlemail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Wed, 14 Jul 2021 14:47:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 12 Aug 2021 11:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 230 days ago.

Previous Next


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