Re: Window splitting issues with margins

[Joost Kremers]

On Di, Nov 24 2015, martin rudalics <address@hidden> wrote:
> I think we agree that ‘nlinum-mode’ and ‘visual-fill-column-mode’ have
> to file their requests via ‘set-window-margins’ and the latter uses the
> maximum value requested.  All this is simple until the moment when the
> mode that requested the current maximum size gets turned off.
>
> In any case I would maintain a window parameter as a list of requested
> margin widths like ((4 . 0) (40 . 40)).  Basically there are then two
> ways to handle this: Let ‘set-window-margins’ decide or let the modes
> agree among themselves.
>
> For the former, when a mode gets turned off it calls, for example,
> (set-window-margins nil -40 -40) and ‘set-window-margins’ decides that
> there is one contender less for a left margin width of 40 and a right
> margin width of 40 and it may have to set new widths.  -0 might require
> special care.
>
> Having the modes agree among themselves means that a mode that wants to
> change the margins has to consult that parameter, add its own value to
> it and only if its own value is larger than the current value, use it in
> a call to ‘set-window-margins’.  When a mode is turned off, it has to
> remove its value from the window parameter, and possibly call
> ‘set-window-margins’ with the new largest value.
>
> WDYT?

One question that came up while reading this is whether it is possible
for two modes to display something in the (same) margin. 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).

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

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

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.

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.


-- 
Joost Kremers
Life has its moments