RE: display-buffer cleverness - how to tame?

[Drew Adams]

>  > 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.