bug#22009: PATCH: Use `window-total-width' in `window-splittable-p'

[Eli Zaretskii]

> Date: Thu, 26 Nov 2015 17:58:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org
> 
>  > I agree with the asymmetry observation, but I think that the width
>  > check is the one that gets it right, while the height check is wrong
>  > and should be corrected.  When a window is split horizontally, the
>  > part that gets split is the text area, not the margins -- those stay
>  > at their original size.
> 
> Note that ‘window-splittable-p’ is exclusively used by ‘display-buffer’
> and the probability is very high that the new window will not be used
> for displaying the buffer of the original window.  The new window will
> very likely have its own margins and header line.

Is it forbidden to call that function from any other Lisp?  If so,
disregard what I wrote.  But if not, window-splittable-p should do a
correct job no matter who calls it, do you agree?

>  > we should consider the text-area size, not the total size.
>  > Otherwise, we can easily wind up in situations where, due to large
>  > margins, a window is split horizontally and the width of its text area
>  > becomes ridiculously small.
> 
> This is a problem that bites us much more with ‘split-window’ than with
> ‘display-buffer’.  As a matter of fact it has been already addressed in
> one of the present threads discussing margins.  My opinion is that modes
> that manage wide margins have to handle this in the hooks called when
> windows are split, deleted or resized.  They also calculate the size of
> the margins based on the current window width when they get activated.

My text that you quoted here talks about the "normal" case, where the
margins stay put upon splitting windows.  I'm saying that in such a
situation a decision made using the total width could be terribly
wrong.

>  > Therefore, I think we should document that split-width-threshold and
>  > window-min-width refer to the width of the text area, and if there are
>  > functions in window.el that compare them with window-total-width,
>  > those places need to be fixed, not this one.  We should also fix the
>  > height check in window-splittable-p.
> 
> ‘window-min-width’ (and all related variables and functions) refer to
> the total width of windows.  Changing its semantics would constitute
> quite some effort.

If it's complicated, let's do that on master.  But do it we must, IMO.

>  > The modes that triggered this are special in that they adapt their
>  > margins to the split, but how would window-splittable-p know that?
>  > Perhaps such modes should override that function, or maybe we should
>  > provide a hook for them?
> 
> This is not mode-triggered.

In my text, "this" referred to this bug report.