Re: Window splitting issues with margins

[Joost Kremers <joostkremers@fastmail.fm>]

On Di, Nov 17 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > 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.
>
> If it's arranged to run after the function ‘linum-mode’ put on
> ‘window-configuration-change-hook’.

Yes, which is why `writeroom-mode' appends its update function to
`window-configuration-change-hook'. However, even though `linum-mode'
prepends its own update function `linum-update-current', it still usurps
the left margin, probably because `linum-update-current' is also added
to `post-command-hook'.

For clarity, the value of `window-configuration-change-hook' when both
writeroom-mode and linum-mode are enabled in a buffer is:

```
(linum-update-current t visual-fill-column--adjust-window)
```

(Note that writeroom-mode doesn't actually modify the margins itself. It
uses `visual-fill-column-mode' for that).

`nlinum-mode' seems to behave better, BTW. It doesn't set the margins'
width after each change or after each command, it seems to do that in
just two cases: when the window configuration is changed, and if it
needs more room for the line numbers (e.g., when line number 100 is
reached). The former is handled by appending rather than prepending
`visual-fill-column--adjust-window' to
`window-configuration-change-hook', so is not a problem. The latter
unfortunately still destroys the margin set by `writeroom-mode', but
things are restored again by any operation that calls
`window-configuration-change-hook'.

>  > The problem with window-splittable-p is that it decides whether a
>  > window can be split horizontally *before* writeroom-mode has a chance
>  > to adjust the margins. Since in the cases I'm talking about, most of
>  > the window width is taken up by the margins, window-splittable-p
>  > thinks that the window is rather narrow (80 characters, the width of
>  > the text area), while in fact it is quite wide (over 200 chars) and
>  > could be split horizontally (because most of those 200 chars are not
>  > used for anything except keeping the text width small).
>
> Aha.  So you want to use ‘window-total-width’ instead of
> ‘window-text-width’ here.  Sounds reasonable.

Yes. Sorry, I could have been clearer about that earlier. The modified
`window-splittable-p' that I have in my init file makes exactly this
single change.

> ‘window-splittable-p’ uses ‘window-width’ and ‘window-height’ just
> because these were there at the time the function was written.  If no
> one objects let's make it use total sizes in both directions.

I'd be all for it.

> OK.  But you rely on the fact that ‘writeroom-mode’ is able to run its
> hook functions after ‘linum-mode’.  This dependency is not very stable.

Nope.

>  > (2) When the margins are used to narrow the text width,
>  > window-splittable-p should take that into consideration when deciding
>  > if a window can be split horizontally. Right now, it doesn't.
>  >
>  > I think (2) is a relatively minor issue. The worst thing that happens
>  > is that a window is split vertically that could have been split
>  > horizontally, e.g., when a help window is popped up. Still, I think it
>  > would be fairly easy to fix once issue (1) is taken care of.
>
> But using ‘window-total-width’ in ‘window-splittable-p’ would fix (2).
> Correct?

Yes.

>  > (1) is a more serious issue, and one thing (though not the only thing)
>  > that needs to be recognised in order to find a way to deal with it is
>  > that the margins can be used for two fundamentally different types of
>  > purposes. On the one hand, they can be used to display some useful
>  > information about the buffer being shown in the window. On the other
>  > hand, they can be used to adjust the width of the text area. The
>  > crucial difference is that for the former purpose, the margins should
>  > not be reduced when the window width changes, while for the latter
>  > purpose, they can be adjusted freely. (Put differently, in the former
>  > case, the margins trump the text width, while in the latter, the text
>  > width trumps the margins).
>
> The only thing we can do is to say in the documentation that when two
> packages contend for the same margin, the one that tries to do that
> later in the redisplay cycle will succeed.

Perhaps it could also be added that in order to reduce (though not
eliminate) the risk of interoperability problems, packages (1) should
examine the width of the margins before changing them (e.g., in
`window-configuration-change-hook'); (2) should not set the margins to a
width lower than the existing width; and (3) should restore the original
width when they are disabled (or rather, restore the width that existed
before the last time they changed the margins).

This policy won't be failure proof, but it should minimise annoyances
for users and should make it easier to live with such annoyances when
they do occur (by doing something that causes
`window-configuration-change-hook' to be run, e.g., switching to another
buffer and back, splitting and unsplitting the window).


-- 
Joost Kremers
Life has its moments