From: "Drew Adams" <drew.adams@oracle.com>
To: "'martin rudalics'" <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: RE: display-buffer cleverness - how to tame?
Date: Mon, 4 May 2009 10:13:48 -0700 [thread overview]
Message-ID: <000e01c9ccdb$b0997180$c2b22382@us.oracle.com> (raw)
In-Reply-To: <49FF1AA0.9080601@gmx.at>
> > Emacs adding DWIM now means that if you want the simple,
> > straightforward behavior of old you need to write it yourself?
>
> It's not about adding DWIM. Let's have a look at "the simple,
> straightforward behavior of old": You apparently have a frame with two
> side-by-side windows and `pop-up-frames' bound to nil (IIRC
> `pop-up-frames' is usually non-nil on your Emacs). The left window is
> the larger one and the right window the least recently used one.
>
> Emacs 22 first tries to split the larger (left) window and fails to do
> so because the window is not full-width. Then Emacs tries to split the
> least recently used (right) one and succeeds. I suppose you were not
> aware of this
Correct; I was not aware of the details behind the Emacs 22 "magic", as Stefan
put it. Thanks for the explanation.
> since otherwise you wouldn't have written (in your first
> mail on this subject) "the problem seems to be that display-buffer now
> tries to split the largest window" where "now" apparently means "Emacs
> 23". The difference is that with Emacs 23 `display-buffer' tries to
> split the largest window _and_ succeeds in doing so.
Thanks for that explanation also. You might consider mentioning that change in
the NEWS (in those terms or similar terms) - your call.
The question I have now is how to impose, in a particular call to
`display-buffer', *not* splitting a window if it is not full-width? That is, how
to reinstate that pre-Emacs 23 splitting criterion (temporarily)?
I'd also like to know how to tell `display-buffer' not to split the selected
window, and how to tell it specifically which window to split. Those approaches
would also solve the problem I see here (in alternative ways), and that
knowledge would be generally helpful (to me, at least).
> So basically you wrote some code that (1) relied on some undocumented
> behavior of `display-buffer',
Yes, I mentioned that.
Because the behavior was undocumented, it was magic, and more or less
take-it-or-leave-it. Replacing it with different magic is OK, but let's document
that, so the magic trick is exposed.
And let's provide simple ways to control the behavior, other than
`define-your-own'.
> and (2) would have failed to DTRT with
> more than two windows on your frame or the window on the
> right not being the least recently used one.
Which is not a problem here - that cannot be the case in my context. But it is
good to know.
> > You are not making it easier for users (which includes
> > Emacs-Lisp users)...
>
> The present code is more fully documented. So I hopefully made it
> easier for users (which includes Emacs-Lisp users) to complain ...
That's good. Maybe there are still a few things that could be explained? My
questions above are a start.
Martin, I do appreciate the work you've done wrt behavior involving windows,
BTW, as I think you know. Much of that work has in fact been clearing up and
taming existing magical, take-it-or-leave-it behavior. I'm thinking, for
instance, of the work you did around quitting help and view mode.
next prev parent reply other threads:[~2009-05-04 17:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-04 7:41 display-buffer cleverness - how to tame? Drew Adams
2009-05-04 8:38 ` martin rudalics
2009-05-04 14:39 ` Drew Adams
2009-05-04 15:03 ` Miles Bader
2009-05-04 15:49 ` Drew Adams
2009-05-04 18:58 ` Samuel Bronson
2009-05-05 2:50 ` Miles Bader
2009-05-04 16:36 ` Stefan Monnier
2009-05-04 16:41 ` martin rudalics
2009-05-04 17:13 ` Drew Adams [this message]
2009-05-05 7:02 ` martin rudalics
2009-05-05 14:18 ` Drew Adams
2009-05-05 16:33 ` martin rudalics
2009-05-05 16:58 ` Drew Adams
2009-05-05 18:55 ` martin rudalics
2009-05-05 20:20 ` Drew Adams
2009-05-06 16:21 ` martin rudalics
2009-05-06 17:54 ` Drew Adams
2009-05-07 9:37 ` martin rudalics
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='000e01c9ccdb$b0997180$c2b22382@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).