emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Better handling of window margins


From: Stefan Monnier
Subject: Re: Better handling of window margins
Date: Fri, 04 Dec 2015 08:22:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>> WRT to sizing the margin, I think if we want to "do it right" it'd make
>> sense to provide an Elisp-layer that defines two functions which could
>> look like:
>>    (window-margin-register OWNER SIZING-DESCRIPTOR)
>> and
>>    (window-margin-unregister OWNER)
>> so those two functions can appropriately combine the SIZING-DESCRIPTORS
>> still active.
> Not sure why window-margin-register and window-margin-unregister
> couldn't be set-window-margins with additional arguments.

Because we want this to be flexible, so it's better written in Elisp, so
it's an extra layer, so it's another function.  set-window-margins then
becomes an internal function that we'd encourage people to stop using.

>> Not sure what SIZING-DESCRIPTOR should look like (it could be
>> a function which takes a size and returns a new size).
> I don't think such a function can be implemented by any particular
> mode, because a mode only knows well what it needs from the margins,
> it has no better idea about other modes' needs than the rest of Emacs.

That's the point of having SIZING-DESCRIPTOR be a function: it receives
a description of the margin chosen by "all other users" and adjusts it
according to its own needs.

> functions for it.  To say nothing of the fact that having more than
> one function again raises a problem of in what order to apply them,
> and what would be the results of applying conflicting functions in any
> order.

We'd push this responsibility on the package authors.
If SIZING-DESCRIPTOR just returns the sum (or the max) of the provided
size and its own use, ordering doesn't matter, for example.
And for the remaining cases we could rely on add-function's `depth' to
impose a particular ordering.


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]