emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: Is there something like `on-display-functions'?
Date: Thu, 28 Jan 2010 14:37:11 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

>> Unless the two functions cooperate, there's no reason to presume that
>> the two functions will fontify the same amount of text, since the amount
>> is mostly arbitrarily chosen by the function themselves (and may need
>> rounding up because of line-granularity or other
>> foo-region-extend-function).
>> 
>> So if each function is written independently, it will (in general) not
>> fontify the same amount of text as the others, and it won't know how
>> much the others (if any) have fontified.  So none of the functions will
>> actually know on which portion of the text the `fontified' property
>> should be applied.
> The place where `fontified' property with a nil value is left after
> all fontification-functions are run is not very important.

On the contrary, it's very important.

> It's just the place where redisplay will stop next and call those
> functions again.

If function foo1 fontified to location 123 and foo2 to location 245 and
the property is set until 245 and the window ends at 200, then foo1 will
not be called again, and the display will show 123-200 without
foo1's fontification.

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

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

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

This said, I don't think it's a serious problem.  The way I look at it,
we should have used fontification-function rather than
fontification-functions, and that's it.

The "multiplexing" of several functions on this hook can be (and is)
performed by jit-lock, where it's easier to be more clever (although
currently jit-lock is not terribly clever either).


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]