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

[martin rudalics <rudalics@gmx.at>]

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

Presently ‘window-splittable-p’ is misnamed and I think that's the main
cause of the confusion.  But its doc-string clearly names
‘split-window-sensibly’ as the caller (which is misnamed as well but all
of these were written before ‘display-buffer’ was reorganized).  In any
case both functions belong exclusively to ‘display-buffer’ and are not
related to C-x 3.

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

But the "normal" case where this happens is C-x 3 and there the mode
that created the large margins should adapt.

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

Basically it would amount to ‘split-window-horizontally’ telling us that
it can't split the window.  Which might not be the intention of the user
who expects the margins (whose sole purpose is to center the text in the
window) to shrink accordingly.

But honestly I don't know which implications changing the semantics of
‘window-min-width’ could have.  I could imagine adding a new option say
‘window-min-text-width’ and have the resizing routines respect this as
far as possible.

But sanitizing window sizes when, for example, making a frame very
small, would have to ignore such an option anyway.  The text area is the
only part I can freely shrink and enlarge down to one line and two
columns.  I cannot restore previous fringes, margins and scroll bars
once I have shrunk them because I don't remember their previous size.
And adding for every window a slot, say previous_left_fringe_width,
remembering it in window configurations, setting it when a user sets
‘set-window-fringes’ in between is something I'm not inclined to do.

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

If you mean that a mode introducing large margins should override
‘split-window-sensibly’ then this is not TRT.  ‘split-window-sensibly’
is user territory and ‘window-splittable-p’ too.

martin