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

[Eli Zaretskii]

> Date: Fri, 27 Nov 2015 09:27:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org
> 
>  > Maybe we should step back and recall what problem are we trying to
>  > solve with the proposed patch, then.
> 
> The current code is inherently wrong because it treats height and width
> differently.  And it's not about the margins alone but also about
> fringes, scroll bars and dividers.  But this is a very old inconsistency
> and I never worried to much about it.  Joost uncovered it.

Yes, but this doesn't seem to answer my question.  I already agreed
that there's inconsistency, the question is how to fix it.  I
suggested one way of reasoning, but you rejected it saying that the
code in question only affects a function that is only used by
display-buffer.  But display-buffer is not relevant to the use case
that Joost described, with those modes which use margins.  So why
should we do anything about window-splittable-p if it only affects
functions that are not relevant to Joost's use case?

Hence my question: if we aren't fixing Joost's use case, and
display-buffer is not relevant to splitting windows with large
margins, what problem we are trying to solve with that patch?

More importantly, if there isn't a clear-cut use case that will allow
us to decide which is the correct behavior, how can we decide whether
to make this change on master or on the release branch?  And why did
you feel it was so important to fix it on the branch?  What's the
urgency?

>  >> 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.
>  >
>  > Didn't you just tell they are called by display-buffer?  How's that
>  > "user territory"?
> 
> The option ‘split-window-preferred-function’ is by default set to
> ‘split-window-sensibly’.  It's exclusively in the hand of the user to
> change that.  A mode that wants to change whether and how
> ‘display-buffer’ is supposed to split a window should specify its own
> buffer display action in the call to ‘display-buffer’.

OK, and I'm still asking: how is all that related to
window-splittable-p?  When we talk about that function, what is the
relevance of the user's ability to replace it to the discussion?

> It would be more correct to rename
> 
> ‘split-window-preferred-function’ -> 
> ‘display-buffer-split-window-preferred-function’
> 
> ‘split-window-sensibly’ -> ‘display-buffer-split-window-sensibly’
> 
> ‘window-splittable-p’ -> ‘display-buffer-window-splittable-p’
> 
> in order to avoid the misunderstandings we have here.

And how is this renaming relevant to the patch that is being
discussed?

I should probably bail out of this discussion, because I feel I'm not
contributing anything but my own confusion to it.