Re: Window splitting issues with margins

[martin rudalics]

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

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

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

> Actually, it's the other way around: linum-mode should set
> margins-min-width and writeroom-mode should respect that
> value. writeroom-mode's goal is to set the text width to a certain
> value. It doesn't care about the margins, except that it needs them in
> order achieve this goal. If the margins need to be set to 0 to achieve
> the desired text width, that's fine. It's linum-mode that requires a
> minimum width for the left margin, because it needs to display
> something there.

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.

> Of course I'd be happy to update writeroom-mode to make it respect a
> minimum margin width set by some other package, but right now, I don't
> see any way of doing that.

> (1) Different packages that use the margins have no way of
> interoperating without running into trouble at some point.

Yes.

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

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

martin