bug#29279: Sharing the margins

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 29279@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 13 Nov 2017 21:16:30 +0200
> 
> On 11/13/17 8:29 PM, Eli Zaretskii wrote:
> 
> >> I'm not sure I understand the "Zero means ..." passage, though.
> > 
> > That's your "total width" thing, for margin users that just want to
> > set the overall width of the margins without displaying anything
> > there.  Like Joost Kramer's visual-fill-column and similar packages.
> 
> OK, but why "maximum width"? workroom-mode wanted to set the total 
> width, but if we want to describe what will happen with the column in 
> question, the value sounds more like "minimum total width".

Indeed, I meant to write "total", not "maximum".

> > Yes, set-window-margins will most probably be reimplemented by calling
> > the above.
> 
> Which area will the left-margin specs be drawn on, then? Ones without 
> any particular symbol specified.

Either without any symbol, or with nil, or with some invented symbol.
Something ti figure out as part of the implementation.

> Having ORDINAL = 0 mean something else, not so great. Especially if the 
> result is to have the padding in this column, necessary to reach the 
> specified total width.

My idea was not to create a column, just make sure the total width is
no less than the requested value.  Which means some of the requested
columns will be wider than requested, I guess.

> I imagine workroom-mode might have a idea where they want the padding to 
> end up (to the left or to the right of all columns). So instead of 
> co-opting the ORDINAL argument to mean "cols will  total cols"

We need to study the needs of potential users, no doubt, before
finalizing the API.

> > It will also be somewhat slower.
> 
> We should probably measure before discarding this idea.

The slowdown will be caused by resizing of the margins (and all the
window-configuration-change-hooks that triggers).