bug#29279: Sharing the margins

[Dmitry Gutov <dgutov@yandex.ru>]

On 11/13/17 9:32 PM, Eli Zaretskii wrote:

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

I see.

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

I think set-window-margins, and the nil/unknown symbols should work with 
the 'default' symbol. And it will have the ordinal = 0.

Then, older packages that are not updated to use the new API can fight 
between themselves for the use of the default column, but the winner can 
peacefully coexist with the packages using the new API.

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

It would probably look not too great. Just like 'text-align: justify' 
often works bad on web pages.

So I'd personally prefer to have all padding on one side.

Then, unless people disagree, setting the total width could be made into 
a separate call. With three arguments: side, width and the side from 
which to pad (inside/outside, for instance).

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

Inviting Joost into the discussion.

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

Doesn't the use of the special area trigger the window configuration 
changes as well, in similar situations? After all, it also changes the 
accessible window body width, right?