Re: Window splitting issues with margins

[martin rudalics]

> I maintain a package called visual-fill-column[1] that mimicks the
> effect of `fill-column' in buffers with `visual-line-mode' turned on by
> widening the window margins. As such, I ran into an issue with window
> splitting that I believe Emacs should handle better.
>
> If I split a window horizontally[2] that has a wide margin, e.g., with
> `split-window-right', the width of the text area is reduced to a minimum
> of 2 columns before the margins are reduced. At least that is my
> impression from the following test:
>
> - emacs -Q
> - make sure you have a wide frame
> - load any text file (to better see the effect)
> - M-x eval (set-window-margins (selected-window) 0 150)
> - C-x 3 (split-window-right)
>
> Depending on the width of the frame and the size of the right margin,
> the text is now reduced to a very small width, while the margin is much
> wider.
>
> I think it would make more sense to reduce the margin before reducing
> the text width.

The margins you set above become a window property.  If after C-x 3 you
do C-x 1 your are left with the reduced margins which might not be what
you want.  Deciding when and how to auto-adjust margins is not trivial.
I would do that in ‘visual-fill-column’.

> A related problem is the fact that `window-splittable-p' only takes the
> width of the text area into account when deciding if a window can be
> split horizontally. This often leads to the situation where a window is
> split vertically, although there appears to be enough room to split it
> horizontally (said room being taken up by the margin).

I agree with this observation.  ‘window-splittable-p’ is asymmetric:
When it checks the width, it uses the text area while for the height it
uses the total area (inlcuding mode and header lines, scrollbar, divider
...).  If you want to change this, please provide a patch.  I certainly
won't object it but am afraid that some people eventually will complain
because one of their packages then doesn't work like it used to over the
past decades ...

BTW: Bug#5944 is about a related issue.  I never got around to resolve
it for a similar reason.

> Also, there is no built-in function that returns the width of the window
> without the fringes, scroll bar and right divider, but *with* the
> margins.

But it's not overly hard to write such a function ;-)

> There is `window-text-width' and `window-body-width' (which,
> despite their names, both only look at the text width;

If your read the Elisp manual (section 27.3 Window Sizes) you will
notice that "text area" and "window body" denote one and the same thing.

> though the latter
> has a PIXELWISE argument that the former lacks

The former will have one in Emacs 25.1.  But you should always use
‘window-body-width’ now.

> ).  The function
> `window-total-width' returns the window width *with* fringes, scroll
> bars and right divider.
>
> Such a function would be useful for packages that calculate some value
> that depends on the width of the window, which often end up using a bad
> value if the window has wide margins (e.g., windows showing buffers
> where `visual-fill-column-mode' is in use). I have made several bug
> reports / pull requests to packages asking them to use
> `window-total-width' instead of `window-width' (which is an alias for
> `window-body-width'), and most have been kind enough to make the change,
> but my pull request to popwin.el[3] was rejected because the window
> configuration wasn't always restored properly after closing the popup
> window. This seems to be the result of using `window-total-width',
> because using a custom function that returns justh the text width +
> margins works fine (i.e., all of popwin.el's ERT tests now pass[4]).
>
> Such a function would probably make sense for the other packages that
> (now) use `window-total-width' as well, because what these packages
> generally need to know is the maximum *potential* width of the text
> area.

The greatest problem I have with a function returning the combined size
of text area and margins is that it would leave out the fringes.  Hence
such a function would by default _not_ return the size of a contiguous
area on the screen which I personally would find slightly disconcerting.

But if you send us such a function (say ‘window-text+margins-width’)
and nobody objects I'll install it.

martin