From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>
Cc: 4293@emacsbugs.donarmstrong.com
Subject: bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el
Date: Wed, 02 Sep 2009 18:45:56 +0200 [thread overview]
Message-ID: <4A9EA144.80708@gmx.at> (raw)
In-Reply-To: <8BA10FD9BFF44AD3BDCE2184D7577DF9@us.oracle.com>
> I do. With pop-up-frames = t, and with a frame alteady showing buffer foo,
> (switch-to-buffer-other-window 'foo) opens a *new*, additional frame to show
> foo. That's the bug. pop-to-buffer instead simply navigates to the existing
> frame, selecting buffer foo there.
The body of `switch-to-buffer-other-window' is deceptively simple
(let ((pop-up-windows t)
same-window-buffer-names same-window-regexps)
(pop-to-buffer buffer-or-name t norecord)))
so let's look into this:
- `pop-up-windows' t means it can pop-up a new window in the selected
frame. I suppose we don't care about this.
- `same-window-buffer-names' and `same-window-regexps' make sure the
selected window is not chosen. So we don't care about these either.
- The `buffer-or-name' and `norecord' arguments for `pop-to-buffer' are
the same as for `pop-to-buffer'. We don't care about them.
- The `other-window' argument set to t is the only one that would differ
with respect to a plain `pop-to-buffer'. But we need it in order to
not reuse the selected window, just as the names of the bookmark
functions indicate. So we won't care about these either.
All that's left are variables like `display-buffer-reuse-frames' which
are handled the same way by `display-buffer'.
>> If you have `display-buffer-reuse-frames' set to nil, `pop-to-buffer'
>> will not reuse another frame displaying that buffer either.
>
> Right. This is for the case when it is set to non-nil. For the nil case, I
> imagine that there is not much difference between pop-to-buffer and
> switch-to-buffer-other-window (but I don't know, as I've always set it to t).
So show me where there's a difference for the `t' case.
> (In fact, I set both display-buffer-reuse-frames and the obsolete (?)
> display-buffer-reuse-frame to t, just in case. ;-))
>
> I expect that most people who use non-nil pop-up-frames set
> display-buffer-reuse-frames to t (but I don't know that for a fact).
Then why does this not work for `switch-to-buffer-other-window'?
>> Please tell which specific detail of `switch-to-buffer-other-window'
>> you dislike in the present use case.
>
> Opening a new frame for the buffer, when there is already an existing frame
> showing it. In the present use case (and in most use cases), that is uncalled
> for.
>
> Context: non-nil pop-up-frames, non-nil display-buffer-reuse-frames.
> pop-to-buffer DTRT; switch-to-buffer-other-window does not.
It does so here.
> (No, we don't want to change the behavior of switch-to-buffer-other-window; that
> command has its uses. It's just that most or many of the existing calls of
> switch-to-buffer-other-window should really be calls of pop-to-buffer.)
>
>> Note: It can't be the `other-window' argument,
>> because in that case we'd have to change the names of the respective
>> bookmark functions.
>
> Sorry, I don't what you're saying, there.
>
> It's pretty simple, really: When I want to go to a bookmark in another
> window/frame (which is most of the time I want to go to a bookmark), I don't
> want to create a new frame for that destination buffer - I just want to go to
> the frame that's already showing it. Imagine hitting the key to go back to that
> bookmark several times, off and on over a period of time. You would end up with
> lots of frames showing that same buffer. Silly.
I suppose you redefined some of the involved functions in a non-standard
manner. Please have a look. Otherwise, we need someone else to confirm
the behavior you report. I can't reproduce it.
martin
next prev parent reply other threads:[~2009-09-02 16:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87skdymwe0.fsf@red-bean.com>
2009-08-30 14:52 ` bug#4293: 23.1; use pop-to-buffer, not switch...other-window, in bookmark.el Drew Adams
2009-09-02 9:58 ` martin rudalics
2009-09-02 14:39 ` Drew Adams
2009-09-02 15:47 ` martin rudalics
2009-09-02 16:16 ` Drew Adams
2009-09-02 16:45 ` martin rudalics [this message]
2009-09-02 17:56 ` Drew Adams
2009-09-02 21:22 ` Stefan Monnier
2009-09-02 21:29 ` Drew Adams
2009-10-05 2:10 ` bug#4293: marked as done (23.1; use pop-to-buffer, not switch...other-window, in bookmark.el) Emacs bug Tracking System
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A9EA144.80708@gmx.at \
--to=rudalics@gmx.at \
--cc=4293@emacsbugs.donarmstrong.com \
--cc=drew.adams@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.