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

[martin rudalics <rudalics@gmx.at>]

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

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

Joost's use case with making a window on the right of an existing one to
show a buffer for `display-buffer'.

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

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

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

It's relevant because above you said that "display-buffer is not
relevant to the use case that Joost described, with those modes which
use margins".  All I'm trying to do is to say that "only display-buffer
is relevant to the use case Joost cares about, with those modes which
use margins".  But maybe it's better for Joost to tell.

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

Let me try to sum up the possible ways to get confused here.  For a long
time we didn't have any problems or reports in this area because margins
were only used occasionally and in a very disciplined way.  Then we had
‘(n)linum-mode’ which started to use margins for displaying line
numbers.  And now we have modes that use potentially large margins to
center text within a window.  It's only the latter that introduce the
problems I list below.

Another problem is that these modes conflict(ed) with ‘(n)linum-mode’
when deciding on the size of the margins.  This is part of other
threads, so I won't describe it here.  The three major problems I see
are:

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

martin