Re: PATCH: make linum.el play nicely with other margin-setting extensions

[João Távora]

On Fri, Nov 13, 2015 at 2:53 PM, martin rudalics <address@hidden> wrote:
>> Though if we come up with `left-margin-min-width' we'll probably have to
>> come up with some `max-width' version some time in the future, no? And
>> so on for every other window-related property. And so on for every
>> frame-related property while we're at it.
>
> I see no problems here.  We can have each mode add its preferred margin
> settings as a triple with a minimum, preferred and maximum width for the
> left and right margins and some kind of priority.  And do similar things
> for the text area, fringes, scrollbars and whatever we want.

Yes, it works.

> The greatest problem is to handle all these options.

Obviously, it's a lot new option-related cruft, right?

> The parameter with the highest priority would specify the preferred
> size, the remaining ones constrain minimum and maximum.  And all these
> constrained by the total size of the window/frame.
>
>> Woundn't it be nicer that a package/mode, when it so sees fit, could
>> mark a particular window|frame|buffer setting as being "owned" by it and
>> then query arbitrarily later if it still owns it?
>
> But wasn't the problem that darkroom should respect the minimum width of
> ‘linum-mode’ and vice-versa?  How would "owning" fit into this?

Yes. Did you see the example implementation, which provides the example
you request?

>> Clearly if *all* extensions played by these rules we would be out of the
>> woods: the test would become
>>
>>      (if (eq (get-setting-owner 'set-window-margins w) 'linum)
>>          ;; reset the margins to whatever was there before
>
> This "before" is problematic when a second or third mode kicks in after
> an owner has set its preferred size.

But then it's those other modes that need to be fixed, to follow
whatever their policy is regarding overwriting current settings. Just
like linum.el does in its `linum-update-window'.

The policy there is: "make just the space I need. If I need to change to
change the margins, then I own them, and it's my responsibility to reset
them to what they were before unless someone else takes that
responsibility from me".

    ;; open up space in the left margin, if needed
    ;;
    (let ((existing-margins (window-margins win)))
      (when (> width (or (car existing-margins) 0))
        (set-window-margins win width (cdr existing-margins))
        (set-setting-owner 'set-window-margins win 'linum)))

And the cleanup code

    ;; restore margins if we still own that setting
    ;;
    (if (eq (get-setting-owner 'set-window-margins w) 'linum)
        (set-window-margins w 0 (cdr (window-margins w))))

Let's be clear: My solution is not a panaceia, it doesn't magically
fix all other
packages that are competing for setting a property. But it allows those
packages to adhere to a simple protocol if they see fit, and is
considerably less onerous on new interfaces to offer to said extensions.

> And how do we decide prioritization when the "owner" is deactivated and
> there are two or more contenders?

We don't. Up to the package. Every package has its policy and can decide
to take ownership. A good policy for taking ownership is "I needed to
change it, I take ownership, so I can check later if I should revert
it". But there might be other cases

João