all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Stephen Leake <stephen_leake@stephe-leake.org>
Cc: emacs-devel@gnu.org
Subject: Re: managing windows in two frames
Date: Sat, 07 Sep 2013 11:37:49 +0200	[thread overview]
Message-ID: <522AF3ED.3090601@gmx.at> (raw)
In-Reply-To: <85hadx584g.fsf@stephe-leake.org>

 > `find-file' does not call `display-buffer'; `find-file-other-window'
 > does call `display-buffer'. (I just checked by enabling Edebug in
 > display-buffer.)
 >
 > `find-file' calls `switch-to-buffer' which calls `pop-to-buffer'.

Usually, `switch-to-buffer' simply sets the buffer of the selected
window.  It calls `pop-to-buffer' only if something unexpected happens.
But you're right in the sense that `find-file' is usually not affected
by `display-buffer-alist'.

 > The same is true for all the other "put a buffer in this window"
 > user level functions I've encountered.

Right.  There was a period where Stefan wanted to deprecate calls of
`switch-to-buffer' from Elisp but later Chong restored the old behavior
(and neither wanted to change the specification of `switch-to-buffer'
itself).  IIRC he simply wanted to keep the old semantics unchanged.

 > `display-buffer-same-window' is an action for `display-buffer'.
 >
 > Ah! We could change the implementation of `find-file' to use
 > `display-buffer' with an action of `display-buffer-same-window'; that
 > action would be changed by prefix C-x 4 or C-x 5.

Yes.  We'd definitely have to replace all `switch-to-buffer' calls to
propose an action like `display-buffer-same-window' if we wanted to make
the prefixes work here.  But we have to do it in some "overriding" sense
to make sure that a user's "general" `display-buffer-alist' settings
don't interfere with the semantics of the current operation.

 > `find-file-other-window' could then be implemented by setting
 > `display-buffer-overriding-action' and calling `find-file'.
 >
 > That would make sense, and should be mostly transparent to users. All
 > the other similar functions would have to be changed in a similar way -
 > I haven't tried to enumerate them. We could implement C-x 4 and 5 for
 > the current uses of `display-buffer' first, and see how people like it.

We first have to handle the case where `display-buffer' pops up a
*Completions* window (which might pop up a *Backtrace* window ...).  I
yet have no good idea how to do that.

martin



  reply	other threads:[~2013-09-07  9:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03  9:11 managing windows in two frames Stephen Leake
2013-09-03 12:52 ` martin rudalics
2013-09-04 18:16   ` Stephen Leake
2013-09-04 18:24     ` Stephen Leake
2013-09-04 19:33     ` Stefan Monnier
2013-09-04 21:22       ` Stephen Leake
2013-09-06 10:53         ` martin rudalics
2013-09-07  8:49           ` Stephen Leake
2013-09-07  9:37             ` martin rudalics [this message]
2013-09-07 13:19               ` Stephen Leake
2013-09-08  7:56                 ` martin rudalics
2013-09-04 21:33       ` Drew Adams
2013-09-06 10:52       ` martin rudalics
2013-09-06 13:22         ` Stefan Monnier
2013-09-06 10:52     ` martin rudalics
2013-09-07  8:56       ` Stephen Leake
2013-09-07  9:37         ` martin rudalics
2013-09-07 13:29           ` Stephen Leake
2013-09-03 13:59 ` Stefan Monnier
2013-09-03 14:15   ` martin rudalics
2013-09-03 14:30     ` Stefan Monnier
2013-09-03 16:23       ` martin rudalics
2013-09-03 20:34         ` Stefan Monnier
2013-09-04  6:25           ` martin rudalics
2013-09-04 13:24             ` Stefan Monnier
2013-09-04 15:04               ` martin rudalics
2013-09-04 17:44                 ` Stefan Monnier
2013-09-06 10:53                   ` martin rudalics
2013-09-06 13:44                     ` Stefan Monnier
2013-09-06 17:14                       ` martin rudalics
2013-09-06 19:00                         ` Stefan Monnier
2013-09-07  9:37                           ` martin rudalics
2013-09-08 17:55                             ` Stefan Monnier
2013-09-09  8:10                               ` martin rudalics
2013-09-09 14:05                                 ` Stefan Monnier
2013-09-04 18:19   ` Stephen Leake

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=522AF3ED.3090601@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=stephen_leake@stephe-leake.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.
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.