bug#431: closed by Stefan Monnier <monnier@iro.umontreal.ca> (Re: bug#431: 23.0.60; `display-buffer' opens vertical instead of horizontal windows)

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>> Now repeat this with 160x24 instead of 80x24.  The frame is now
>>>> split horizontally and the new buffer is in a window to the *right*
>>>> of the original window.
>> This is the desired default behavior.
> This is *now* the desired default behavior, but from my POV this is a
> *regression*: on Debian emacs22_22.2+2.2 still has the old behavior and

Every change in the default behavior will be regression for someone.

> I've some functions which rely on that.

What kind of functions?  What do they look like?  What do they do?

> Arbitrarily breaking stuff is not acceptable IMO and this is the reason
> why I reopened this bug.

This is not arbitrary.

> It could be strange, but I really like the new default behavior: I tend

I'm not surprised: that's why I say the change is not arbitrary.

> However, what I'd prefer instead is something configurable every time I
> want to split a window: there's a default behavior (let it be managed by
> `split-width-threshold' or `split-height-threshold', I don't care), but
> e.g. if I call C-u C-x 4 f the default behavior is reversed.

I see what you mean.  I don't think "C-u C-x 4 f" is a good solution
because it's too specific.  But I've already toyed with some other idea
which would be just as useful: get rid of C-x 4 f and C-x 5 f etc.. and
instead introduce "other-window" and "other-frame" prefix keys, which
would apply to the next command (C-x C-f, C-x b, M-x calendar, M-x info,
...).  In this context, you could easily add "other-vertical-window" and
"other-horizontal-window" prefix keys.

In any case, this is out of the scope of this bug report.  If you want
to discuss such a thing, please move it to some other bug-report or to
emacs-devel.


        Stefan