[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23131: switch-to-buffer-other-frame problem
From: |
jan |
Subject: |
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@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
>
>