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

[Stefan Monnier]

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

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

>> > OTOH, it would be a simple change to have the loop in
>> > handle_fontified_prop maintain the lowest buffer position of those
>> > where the `fontified' property was placed by any of the functions it
>> > invokes, and reset the value of that property to nil for that position
>> > after the loop finishes.  Would that resolve the difficulty?
>> 
>> 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'.

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.

All doable, but ugly and messy, duplicating what jit-lock does.

> 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'd be interested in
a before-redisplay-hook, admittedly, which would be an alternative to
post-command-hook: 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, ...).  I'm thinking of things like reveal-mode, or
changing the cursor color depending on context.
Anything else in your mind?

> ----------------------
> [1] As usual, our mostly wrong impression about the speed of our our
> machines stems from the fact that most of the time we see them being
> busy moving pixels from here to there.  When time comes to exercise
> raw computing power, modern machines are lightning fast.

> A case in point is the bidi reordering code.  Its processing core is
> no less than 1500 lines of C, which replace these two lines in the
> current unidirectional display engine:

>         IT_BYTEPOS (*it) += it->len;
>         IT_CHARPOS (*it) += 1;

> (For those who are not familiar with the display engine, this advances
> the iterator by one character and the corresponding number of bytes,
> as determined by the length of its multibyte sequence.)

> IOW, instead of two increments, we run a 1500-line monster.  Mind you,
> this runs in the innermost loop of the display engine!  Would you be
> surprised to know that I got scared when I finished implementing the
> reordering code?  I was afraid that the resulting redisplay will
> crawl.  So I timed the code, by writing a trivial wc workalike, and
> timing it against the real wc.  To my surprise it worked at half the
> speed of wc, which is pretty darn fast, concerning what it needs to
> do instead of just incrementing a pointer.

> Morale: never underestimate what a modern CPU can do when it does not
> need to move pixels ;-)

Amen!


        Stefan