Re: Window splitting issues with margins

[martin rudalics]

> One question that came up while reading this is whether it is possible
> for two modes to display something in the (same) margin.

Can we do that?

> If yes, your
> proposal will probably not work right. If we have, say, nlinum-mode
> requesting a left margin of 4 and some-other-mode requesting a margin of
> 2, also in order to display something there, the window parameter would
> be ((4 . 0) (2 . 0)). Then the actual left margin width should not be
> (max 4 2) but (+ 4 2).

Agreed.

> writeroom-mode is different, however, because it just wants the margins
> to be a certain width, regardless of what other packages display in them.
>
> I would probably use a window parameter that stores the requested margin
> widths in an alist with the requesting modes as keys, e.g.:
>
> ((nlinum 4 . 0) (some-other-mode 2 . 0))

OK.  I thought about doing that because then a mode doesn't have to
remember the margin sizes it requested for the sole purpose to remove
them eventually.

> (The symbol can be freely chosen by the mode, but it should obviously be
> properly prefixed.) `set-window-margins' then sets the margins to the
> sum of the requested values.

Or the requesting mode.  We'd still have to agree first on who's to
decide.

> As a special case, the symbol can also be t, which indicates that the
> associated widths are not additive but minimum widths. This is what
> writeroom-mode would use. So if the window parameter has the value:
>
> ((nlinum 4 . 0) (some-other-mode 2 . 0) (t 40 . 40))
>
> a call to set-window-margins would set the margins to (40 . 40), because
> 4+2=6 and 6<40. But if it has the value:
>
> ((nlinum 4 . 0) (some-other-mode 2 . 0) (t 4 . 4))
>
> `set-window-margins' would set the margins to (6 . 4), because
> nlinum-mode and some-other-mode request a total width of 6, while the
> minimum width is 4.

I we already use mode identifiers we can easily add a fourth value to
tell whether the values are additive or minimum.

> This would require adding an additional argument to set-window-margins
> for the symbol to be used as a key in the window-margin alist. If the
> symbol is left out, set-window-margins would behave in the old way,
> setting window margins to absolute values and ignoring the window-margin
> alist.
>
> Anyway, all of this probably only makes sense if it's actually possible
> for two modes to display something in the same margin without
> interfering with each other.

Indeed.

martin