Re: Better handling of window margins

[Eli Zaretskii <eliz@gnu.org>]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Date: Tue, 01 Dec 2015 22:28:44 +0100

I think we should consider the 2 issues separately:

 . how can multiple features each display its own stuff in the margins
   without breaking other such features

 . how to split windows that have margins

For the first issue, IMO it isn't enough to specify just one value,
the required margin width.  You need also to specify the width of the
stuff, if any, that is displayed in the margin.  (This will have to be
specified in pixels, because you can display images and pixel-granular
stretches of white space in the margins.)  For example, linum-mode
will specify a margin width of N columns, and display width of the
same N columns in pixels.  By contrast, modes such as writeroom-mode
will specify a margin width of M columns and display width of zero.

So we need to maintain, for each of the 2 margins, a list of elements
of the form:

   (SYMBOL MARGIN-WIDTH DISPLAY-WIDTH)

where SYMBOL is a unique symbol used to identify the request that came
from a specific feature/mode.  We should provide a function to return
this list, or maybe make it the value of a local public variable.  We
should also have a way for a feature to update its request.

Given such a list of requests, we compute the required margin width
using the following simple algorithm:

 . compute maximum of all MARGIN-WIDTH values
 . compute the sum of all DISPLAY-WIDTH values
 . take the maximum of the above two

(I omitted the translation from columns to pixels and back that will
be needed here.)

This solves a large portion of the interference issue, but it still
leaves at least one aspect unsolved: what if some feature wants to
limit the margin width from above?  For example, I presume that
writeroom-mode and its ilk would like to do that, because they want to
keep the text area at some constant width.  But if the width
calculated as above is greater than that, the text area will have no
alternative but to shrink.  Is that acceptable?  Or should we refuse
the request that causes this?  (In the latter case, we will have to
ask each feature to supply one more parameter with its request.)

Now regarding the split-window issue.  I believe we shouldn't try to
second-guess how to split windows in these cases.  Instead, we should
place the burden of doing TRT on the modes.  Specifically:

 . for splitting the window with "C-x 2" and "C-x 3", the mode could
   simply invoke the correct splitting function itself

 . for splitting the window as result of some command calling
   display-buffer, we could expect the modes to customize the
   display-buffer-* variables to control how the window is split (if
   there are currently no features/variables to that effect, we should
   add them)

The reason I don't believe in some general-purpose heuristics in this
case is that there's any number of possible needs of modes wrt
margins.  You are trying to classify these into "static" and
"dynamic", but the "dynamic" kind can be something very different from
what writeroom-mode and its ilk need in this regard.  So the
heuristics will fail when we have a mode whose margins are not
"static", but not like writeroom-mode, either.

Does this make sense?