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

[martin rudalics]

> 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.  The
greatest problem is to handle all these options.

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?

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

>          ;; else do nothing
>          )

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

martin