bug#23131: switch-to-buffer-other-frame problem

bug#23131: switch-to-buffer-other-frame problem

[jan]

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

bug#23131: switch-to-buffer-other-frame problem

[martin rudalics]

 > 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

bug#23131: switch-to-buffer-other-frame problem

[jan]

Hi Martin,
please see below

On 28/03/2016, martin rudalics <rudalics@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
>
>

bug#23131: switch-to-buffer-other-frame problem

[martin rudalics]

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

bug#23131: switch-to-buffer-other-frame problem

[Juri Linkov]

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

bug#23131: switch-to-buffer-other-frame problem

[Lars Ingebrigtsen]

Juri Linkov <juri@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