GNU bug report logs -
#29279
Sharing the margins
Previous Next
Full log
Message #41 received at 29279 <at> debbugs.gnu.org (full text, mbox):
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?
This bug report was last modified 7 years and 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.