bug#29279: Sharing the margins

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 29279@debbugs.gnu.org, Joost Kremers <joostkremers@fastmail.fm>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 13 Nov 2017 23:16:15 +0200
> 
> 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.

Could be.

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

But then requests for the rightmost (or leftmost) column will go
unsatisfied, for apparently no good reason.

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

That can be done, but the main issue is not the API in this case, I
think, it's the effect of the call.

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

No, and I still hope we can avoid the need to do that.
tabulated-list-mode came close, but I eventually succeeded in making
it happy with the other hooks.

> After all, it also changes the accessible window body width, right?

It depends on your POV.  My POV is that it doesn't, since the window
dimensions and the dimensions of the text area are unaltered.  At
least one other person disagreed (vociferously).