bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20189: 25.0.50; Feature request: Alternative split-window-sensibly f


From: Eli Zaretskii
Subject: bug#20189: 25.0.50; Feature request: Alternative split-window-sensibly functions
Date: Tue, 24 Mar 2015 19:05:35 +0200

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Tue, 24 Mar 2015 10:18:04 +0100
> 
> With the widescreen displays that are common today, the default behavior
> of `split-window-sensibly' is not always too sensible, and of course
> what's sensible is determined by the user.  So I'd suggest that some
> alternative implementations are provided so that users can easily try
> them out to find the one that suits them best.
> 
> The problem with `split-window-sensibly' on a wide screen is that it
> prefers vertical splits.  The current emacs -Q behavior in a maximized
> frame of size 269x82, the first split will be a vertical one.  That's
> pretty useless because then you have two windows with nearly 200 columns
> of free space right of the buffer contents (assuming that usually most
> buffer contents are at most 80 columns wide).

'split-window-sensibly' is documented to "split WINDOW in a way
suitable for 'display-buffer'".  Are you talking about the same use
case, i.e. are you talking about some command that invoked
'display-buffer'?  Or are you talking about some different use case?
This is not clear from your description, since it lacks the context in
which your needs are different.

IMO, the rest of the discussion depends crucially upon the context,
and in particular on the command that invoked 'display-buffer' (or
maybe invoked 'split-window-sensibly' directly?).

My understanding of the current logic is that 'display-buffer' is
generally used for short-lived windows that are intended to be deleted
a short time after the split.  Long-lived splits are supposed to be
caused by "C-x 2" and "C-x 3", where the user determines how to split
anyway.

If we are willing to produce long-lived splits automatically, then the
2 thresholds are IMO not enough for "sensible" behavior of any kind;
what is missing is 2 more parameters that provide the desired (as
opposed to minimal) height and width of a window.  These parameters
are implicitly present in your description, but you never explicitly
name them.

> It's exactly like `split-window-sensibly' except that the
> horizontal/vertical clauses are reversed, i.e., it tries a horizontal
> split before trying a vertical split.  That version suits my needs a bit
> better.
> 
> However, it's still not exactly what I really want.  The problem is that
> after the first horizontal split I end up with 2 side-by-side windows
> where each one is 132 columns wide.  That's still much wider as needed
> for most buffer contents but less than `split-width-threshold', so the
> next splits will all be vertical ones so that I'll eventually end up
> with four windows arranged in a 2x2 grid, each window having the size
> 132x40.

You never say what are your values of the 2 thresholds, so it is hard
to reason about your description.

> (1) That version would prefer horizontal splits as above.
> 
> (2) I want either horizontal or vertical splitting but not both, i.e.,
>     the layout should always be Nx1 or 1xN windows.
> 
> (3) A window may get split horizontally not if it's wider/taller than
>     `split-width-threshold'/`split-height-threshold' but instead when
>     its width/height *after* the split followed by `balance-windows'
>     is larger than or equal to (/ split-{width,height}-threshold 2).
> 
> (4) The single-window exception of `split-height-threshold' still
>     holds, so in frames with just one window a vertical split is
>     performed even though that window is actually too small according
>     to the rules above.

Maybe I misunderstand, but doesn't (2) contradict (1)?

And why is (1) a good idea anyway?  Why not have a more optimal split,
whereby (for example) the larger dimension is preferred?

As for (3), such a criterion is IMO a good idea only if we actually
balance the windows as part of the split.  Otherwise, you will have
adverse effects when the window to be split is very narrow, but some
of its peers are wide.

> When I use a frame of size 80x82 instead, I'd end up with 2 vertical
> windows

And this is good because?...

FWIW, I'd prefer a 80x41 window to a 40x82 window, since 40 columns is
way too few for editing a typical program or text buffer.  Or do you
have a lot of buffers with very short lines?

It is also possible that in some cases the caller of
split-window-sensibly could provide the requested dimensions in
advance.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]