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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 26 Nov 2015 09:23:13 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org
> 
> > Convince me.  (It doesn't sound like a bug, does it?)
> 
> It is a bug.  In
> 
>                (>= (window-width window)
>                    (max split-width-threshold
>                         (* 2 (max window-min-width 2))))
> 
> we currently compare apples and oranges.  ‘window-width’ does not
> include margins, fringes, scrollbar and divider.  ‘window-min-width’
> is meant to include them all.

Thanks.  It turns out I was mistaken wrt what issue this attempts to
solve.

Now that you've set me straight, I agree this is a bug.  But I don't
necessarily agree with the proposed solution.

In the discussion that led to this you said:

> > A related problem is the fact that `window-splittable-p' only takes the
> > width of the text area into account when deciding if a window can be
> > split horizontally. This often leads to the situation where a window is
> > split vertically, although there appears to be enough room to split it
> > horizontally (said room being taken up by the margin).
> 
> I agree with this observation.  ‘window-splittable-p’ is asymmetric:
> When it checks the width, it uses the text area while for the height it
> uses the total area (inlcuding mode and header lines, scrollbar, divider
> ...).  If you want to change this, please provide a patch.  I certainly
> won't object it but am afraid that some people eventually will complain
> because one of their packages then doesn't work like it used to over the
> past decades ...

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.  So when we decide whether to split
vertically, 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.

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.

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?

> BTW: Bug#5944 is about a related issue.  I never got around to resolve
> it for a similar reason.

Did you really mean 5944?  That's not an Emacs bug even.