From: Sam Halliday <sam.halliday@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: change buffer in other frame, multiple monitors
Date: Thu, 28 May 2015 07:26:11 -0700 (PDT) [thread overview]
Message-ID: <7913274f-17ab-449d-b33d-bb70e09aa105@googlegroups.com> (raw)
In-Reply-To: <a45b6a7f-e0ef-4de3-abfc-ad591752b4be@googlegroups.com>
Workaround incase anybody else comes across this
(defun switch-to-buffer-other-frame--no-really (buffer-or-name)
"Switch to buffer BUFFER-OR-NAME in the other frame."
(interactive
(list (read-buffer-to-switch "Switch to buffer in other frame: ")))
(other-frame 1)
(switch-to-buffer buffer-or-name nil t)
(other-frame -1))
(global-set-key (kbd "C-x 5 b") 'switch-to-buffer-other-frame--no-really)
On Thursday, 28 May 2015 15:16:42 UTC+1, Sam Halliday wrote:
> I'm starting to think that `C-x 5` commands are not really intended to reuse the other frame (despite their name). From the docs http://www.gnu.org/software/emacs/manual/html_node/emacs/Creating-Frames.html
>
> > If an existing visible or iconified ("minimized") frame already displays the requested buffer, that frame is raised and deiconified ("un-minimized"); otherwise, a new frame is created on the current display terminal.
>
>
> e.g. starting emacs24 (debian jessie) with -Q and type
>
> C-x 5 2 ;; new frame
> C-x 5 b ;; *Messages*
>
> a THIRD frame is opened. I had expected the other frame to be reused.
>
>
> Is there any way to get the `C-x 5` commands to reuse the other frame instead of creating a new one or am I going to have to rewrite my own functions that first call `other-frame`?
>
>
>
> On Thursday, 28 May 2015 15:02:45 UTC+1, Sam Halliday wrote:
> > I'm starting to think there must be a bug somewhere. Setting the explicit action is still causing `C-x 5 b` to open a new frame even if one is already open:
> >
> > (setq display-buffer--other-frame-action
> > '((display-buffer-reuse-window display-buffer-pop-up-frame)
> > (reusable-frames . t) (inhibit-same-window . t)))
> >
> > I'm on Debian Jessie but some mac users have said that the out-of-the-box behaviour is for `C-x 5 b` to reuse the other frame.
> >
> > I'm stumped. Any help appreciated.
> >
> >
> > On Thursday, 28 May 2015 12:22:25 UTC+1, Sam Halliday wrote:
> > > I've updated the below with the newer display-buffer-alist approach with
> > >
> > > (setq display-buffer-alist
> > > '((".*" display-buffer-reuse-window (reusable-frames . t))
> > > (".*" display-buffer-pop-up-frame (inhibit-switch-frame . t))))
> > >
> > > The reuse-window entry seems to reproduce the behaviour of the legacy setting I was using.
> > >
> > > I have added a display-buffer-pop-up-frame entry as per the documentation for display-buffer but it seems to be ignored.
> > >
> > > Is my syntax perhaps incorrect? Maybe there should only be one ".*"?
> > >
> > >
> > >
> > > On Wednesday, 27 May 2015 15:16:27 UTC+1, Sam Halliday wrote:
> > > > Hi all,
> > > >
> > > > I have a setup with multiple monitors and when using Emacs I have a frame in each monitor.
> > > >
> > > > I recently asked a question on this list and the solution was to set
> > > >
> > > > (setq-default display-buffer-reuse-frames t)
> > > >
> > > > so that 'next-error would not popup a new window (when the window was already open in a new frame).
> > > >
> > > > That worked great! I've recently been extending my use of basic emacs commands to include the commands under `C-x 5 ...` (i.e. the "do in the other frame" commands)
> > > >
> > > > However, when I type `C-x 5 b` and select a buffer name, I am expecting the buffer to be shown in the other frame. But instead, the buffer is opened in a new frame.
> > > >
> > > > It would appear that setting 'display-buffer-reuse-frames is not enough to force re-use of existing frames and this function is popping up a new one.
> > > >
> > > > Is there something else I must do to re-use frames? I note that display-buffer-reuse-frames is deprecated, but I'm not entirely sure how to migrate to the new world.
> > > >
> > > > Best regards,
> > > > Sam
next prev parent reply other threads:[~2015-05-28 14:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 14:16 change buffer in other frame, multiple monitors Sam Halliday
2015-05-28 11:22 ` Sam Halliday
2015-05-28 14:02 ` Sam Halliday
2015-05-28 14:16 ` Sam Halliday
2015-05-28 14:26 ` Sam Halliday [this message]
2015-05-28 14:25 ` Michael Heerdegen
2015-05-28 15:03 ` Yuri Khan
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7913274f-17ab-449d-b33d-bb70e09aa105@googlegroups.com \
--to=sam.halliday@gmail.com \
--cc=help-gnu-emacs@gnu.org \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).