bug#29279: Sharing the margins

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 29279@debbugs.gnu.org, joostkremers@fastmail.fm
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 19 Nov 2017 01:55:23 +0200
> 
> > The way this feature is designed and implemented, it doesn't lend
> > itself easily to hooks, primarily because it works in the inner-most
> > level of redisplay.
> 
> Then maybe using the margins for it will be a necessary price, with the 
> corresponding performance hit (though hopefully not), just to enable the 
> extensibility our users are accustomed to.

Not from my POV.  The extensibility is already there, you can look at
the bundled modes which were adapted to this feature.

> >> Can't you save the necessary data to a variable, finish redisplay,
> >> and then run the hook (if the data says so)?
> > 
> > That would be pointless, because there are already hooks which work
> > before redisplay or after it finishes.  All such a hook needs to do is
> > compare the value returned by line-number-display-width with the last
> > value it saw.  That's what I did in tabulated-list-mode, which has
> > some unique requirements in this area.  Avoiding the comparison
> > doesn't justify a new hook.
> 
> Hmm, I'm not sure it would be as pointless as you say: normally, it's 
> most important to be notified of some change _eventually_, and not 
> necessarily during some process such as redisplay. It would at least 
> save the user the problem of puzzling out how to do this, and what to 
> compare.

What is the difference between being notified when the width changed,
and figuring out when it was changed by comparing two numbers?

> On the other hand, it could be the argument for margin changes not to 
> run the usual hooks, because any sane called could compare margin widths 
> before and after.

It's the other way around: we are talking about hooks that would like
to change the margins.

> > And anyway, what do you envision that a hook function will want to do?
> > Most probably, it will want to change the window dimensions, or affect
> > what's on display in some other way, which means an immediate second
> > redisplay cycle.
> 
> Affect what's on display, yes, most likely.
> 
> > So we gain nothing by making the display engine call
> > the hook.
> 
> Yeah. I was suggesting to call the hook later, though.

Same difference.

> >> It's somewhat hypothetical, but I'd like to refer to (*) above. That is,
> >> somebody will probably ask for that anyway, sooner or later.
> > 
> > Somebody already did, and I declined for now, because I think the same
> > effect can be achieved via existing hooks.
> 
> Do you have margin-using examples that likewise couldn't be "achieved 
> via existing hooks" if margin changes didn't call 
> window-configuration-change-hook?

I didn't try to look.

Anyway, could we please stop mixing these two issues?  This discussion
is about margin sharing, not about a (missing) hook for changes in
line-number width.