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

[Eli Zaretskii]

> Date: Sat, 28 Nov 2015 11:26:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 22009@debbugs.gnu.org
> 
>  > 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.
> 
> Indeed.  Joost's description of his fix is too general, it alludes to
> solving problems with C-x 3.  I initially misunderstood too as you can
> derive from the following dialogue in a different thread.  I said that
> 
>  > As I tried to explain before: ‘window-splittable-p’ is hardly the
>  > function we care about here.  We care about ‘split-window’ itself.
> 
> and Joost answered
> 
>  > Actually, I care about window-splittable-p, not about
>  > split-window. split-window is not a problem, because after it's done
>  > its work, window-configuration-change-hook is run, where
>  > writeroom-mode can (and in fact already does) adjust the window
>  > margins.
> 
> So your question
> 
>  > So why
>  > should we do anything about window-splittable-p if it only affects
>  > functions that are not relevant to Joost's use case?
> 
> should be answered now.  Correct?

Yes, thanks.  But that still doesn't suggest how to fix
window-splittable-p, unless we care _only_ for Joost's use case.  And
I don't think we can declare that only such use cases matter, as
window-splittable-p is too general-purpose for that.

>  > 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 the fix is wrong it will be wrong for master too.  And if I don't fix
> the code for the release branch but do care about the correctness of our
> docs, I have to rewrite doc-strings and Elisp reference in order to
> describe the inconsistency between vertical and horizontal splitting for
> the release branch.  This is a bug I could ignore for some time simply
> by not looking at the code more deeply.  Once I look at the code and see
> what it does, I have to react either by correcting the code or by
> changing the documentation.  Anything else would be irresponsible.

We agree that the code should be fixed.  We just disagree about (or
don't know) _how_ to fix it.

>  >>   > 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?
> 
> If it is not related then I missed again what you were asking.  I tried
> to guess twice but am apparently too silly to grok it.

Forget it, it isn't related to the issue, so there's no need to
explore this further.

> (1) When a mode uses margins to center text and you want to split the
>      corresponding window via C-x 3, ‘split-window-right’ may refuse to
>      split the window because the decision whether to split the window is
>      based on the assumption that the margin widths in the original
>      window shall be preserved.
> 
> (2) When a mode uses margins to center text and you want to resize the
>      corresponding window horizontally via ‘mouse-drag-vertical-line’,
>      the latter may refuse to do that because the decision whether to
>      shrink the window is based on the assumption that its margin widths
>      shall be preserved.
> 
> (3) When a mode uses margins to center text and you want to split the
>      corresponding window for displaying a buffer via ‘display-buffer’,
>      ‘split-window-sensibly’ may refuse to split the window because the
>      decision whether to split the window is based on the assumption that
>      the window to be split is only as wide as its text area.  Since this
>      wide can be comparably small in a window that uses margins to center
>      text, the attempt to display a buffer on the right may often fail
>      unexpectedly.
> 
> Joost's fix is exclusively for problem (3).

Agreed.  And I don't think we can fix this only for that use case.  We
should try to look for a more general solution.