GNU bug report logs - #4293
23.1; use pop-to-buffer, not switch...other-window, in bookmark.el

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Sun, 30 Aug 2009 15:00:06 UTC

Severity: normal

Done: Karl Fogel <kfogel <at> red-bean.com>

Bug is archived. No further changes may be made.

Full log


Message #30 received at 4293 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 4293 <at> debbugs.gnu.org
Subject: Re: bug#4293: 23.1;	use pop-to-buffer, not switch...other-window,
 in bookmark.el
Date: Wed, 02 Sep 2009 18:45:56 +0200
> 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



This bug report was last modified 15 years and 229 days ago.

Previous Next


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