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

[Joost Kremers]

On Fr, Nov 27 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > The point is that the margins may be used for two different kinds of
>  > purposes:
>  >
>  > (1) The margins can be used to display useful information, in which case
>  > they should be retained when the window is split.
>
> But ‘window-splittable-p’ is used in a context where usually we use the
> new window to display another buffer than that of the original window.
> To my knowledge nobody wants *help* or *completions* buffers to display
> line numbers.

But I'm talking about the original window, which is now narrower than it
was before. If linum-mode is active in that buffer, it will still be
active after the split and the window will need margins to accommodate
the line numbers.

> And if the original window has no margins but the new
> window should display them, the current code won't help either.

No, but the buffer displayed in the new window has a local value for
`window-configuration-change-hook', which should take care of setting
the margins (as it does in writeroom-mode).

>  > (2) The margins can be used to reduce the width of the text area. In
>  > this case, the margins are disposable.
>
> Let's specify the reason more explicitly: The margins are used to center
> the text area in the window.  Correct?

Not necessarily, it's also possible that only one of the margins is
widened. That is what visual-fill-column-mode does, another mode I wrote
that mimics the effect of `fill-column' in buffers that use
visual-line-mode.

>  > The only way to deal with both (1) and (2) correctly, and also with the
>  > case where different modes use the margins for (1) and (2) *at the same
>  > time*, would be to store information about the modes that use the
>  > margins and for which purpose. Then `window-splittable-p' could tell
>  > which part of the margins must be retained and which part is disposable.
>
> It would have to be clairvoyant wrt which kind of margins the buffer
> displayed in the new window will have.  ‘find-file’ can enable
> ‘linum-mode’ in ‘find-file-hook’ but the real width of the margin needed
> to display them will be known only when ‘linum-mode’ calculates it, that
> is, _not_ at the time of splitting.

Yes, of course, there's nothing to be done about that.
`split-width-threshold' and/or `window-min-width' should be set up in
such a way that the new window can comfortably display a buffer that has
the margins that the user wants. But that's the user's responsibility.

I'm only worried about the original window. Perhaps some clarification
with screen shots is in order. Consider the following:

http://wwwuser.gwdg.de/~jkremer/visual-fill-column1.png

This is a buffer with a soft-wrapped text, with the right margin set to
some large value so that the text is wrapped at `fill-column'. If I do
`C-h f <some-function>' in such a window configuration, I get this:

http://wwwuser.gwdg.de/~jkremer/visual-fill-column2.png

which is odd, because there is so much "empty" space on the right. By
using `window-total-width' in `window-splittable-p', I get this:

http://wwwuser.gwdg.de/~jkremer/visual-fill-column3.png

Much nicer, IMHO. (I'm not trying to defind my fix here, I know it's
flawed. Just demonstrating what my use case is.)


-- 
Joost Kremers
Life has its moments