Re: Is there something like `on-display-functions'?

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Thu, 28 Jan 2010 18:12:11 -0500
> 
> >> > If a function on that list needs to be sure it does
> >> > not miss any text due to the position where a nil-valued `fontified'
> >> > is placed, it should simply start from some earlier position, not from
> >> > the one with which it is invoked.  Then it could search for the first
> >> > position where it needs to do its job, and resume there.
> >> Which "earlier position"?  How does the function know how far back it
> >> would need to look?
> > It could simply record that position in some variable.
> 
> If the buffer is shown in two windows, that "last position" might be
> megabytes away.

It doesn't matter, because the redisplay works on windows one by one,
and the iterator structure is initialized anew for each one of them.

> >> > Note that the JIT Lock function that gets invoked via
> >> > fontification-functions always starts from the beginning of the line
> >> > to which the position it was invoked with belongs.  So it is already
> >> > doing something similar, albeit for different reasons.
> >> That used to be the case, but now this region-extension has been moved
> >> to font-lock (where it belongs).
> > The effect is the same.
> 
> Not quite: there are other users of jit-lock than font-lock (mostly
> glasses-mode, but Alan might become the third user, linum could be
> another user, ...).

My point was that the Lisp function which is invoked via this
mechanism can do its work in any position it finds fit, not
necessarily the position passed to it by the display engine.

> >> We could try and solve the problem this way, yes.  Then again, it could
> >> result in serious inefficiency if one of the functions works on 100B
> >> chunks and the other on 1KB chunks, forcing the 1KB chunks to be
> >> recomputed redundantly 10 times.
> 
> > That would just mean that the 1KB function gets called, detects that
> > it has nothing to do, and returns.  (Assuming it records its last
> > chunk in some variable.)
> 
> This assumption is currently not true.  Recording which part is already
> handled and which part is not yet handled is usually done either by the
> `fontified' property (if you use fontification-functions) or somehow by
> `jit-lock'.

That ``somehow'' is what I meant when I mentioned that the function
could record where it left off in some variable.

> If such a problem of efficiency needs to be solved, we could indeed
> probably hack it up via some such variable, tho it would be mighty ugly,
> since the function wouldn't necessarily know what happened between the
> last time it was called and the current time, so it would need to
> somehow figure out whether "nothing happened and I can just return" or
> whether in the contrary the buffer has been modified and the
> fontification that was computed last time needs to be refreshed.

Anything that's needed for such a decision except the position and the
buffer or window id?

> > Fine with me.  But I do think we may wish to have some more general
> > redisplay-hook feature, that isn't tailored to fontification.
> 
> Not sure what you're thinking of.

I was thinking about a hook that does not depend on the `fontified'
property.

> I'd be interested in a before-redisplay-hook

Why ``before''?  There isn't much a Lisp code can do to affect
redisplay, if it is called _by_ redisplay.  I'd say calling the hook
when redisplay is done is more useful.  But I didn't analyze the
possible uses of that, so I may be mistaken.

> admittedly, which would be an alternative to post-command-hook

Redisplay is not always triggered by commands.  Input from a process
is a notable example when it isn't.  Mouse movement is another.
Window size changes are yet another.

> several post-command-hooks would actually also like to be run at
> times where no command was performed (e.g. timer event, filter,
> sit-for, ...).

Exactly.