Re: Last steps for pretesting (font-lock-extend-region-function)

[Alan Mackenzie]

Evening, Stefan!

On Tue, 25 Apr 2006, Stefan Monnier wrote:

>> OK.  So FACENAME comes back as nil (which presumably means "don't apply a
>> facename property") and the side effect is applying f-l-multiline if the
>> buffer line matches the regexp.

>Right.

>>>> What about the run-time overhead of having an extra text property over
>>>> the entire buffer?
>>> It's not over the entire buffer.
>> Load a buffer and wait for it to be jit-locked.  The entire buffer will
>> have been scanned and this text property, in effect, set to t or nil on
>> every single byte.

>Actually the `nil' value is not added, so the property is only added where
>it's non-nil.  Hence it's not added to the entire buffer.

Maybe the 'nil' isn't explicitly added, but the entire font-lock region
(or buffer) has to be scanned.  Every time a region gets fontified, the
f-l-m properties are erased and every multiline sequence in that region
is recalculated.  In the approach I favour, only the bits at the region
boundaries need checking, and then only at the time they are needed.

This continual erasure and recalculation of f-l-m properties could have a
serious impact on the speed of C Mode, when that finally acquires a
suitable region calcualtion function - because this function will
essentially have to be c-beginning-of-statement-1, with various
strategies, such as cacheing, to speed it up.  Calculating this function
for _every_ statement within the region would be prohibitively expensive.

>>> And I haven't seen any evidence that it's noticeable (especially
>>> compared the number of `face' properties or of the `fontified'
>>> property added to the whole buffer).
>> I'm sure it's not.

>Good.

>> Is it really that important to responsiveness whether the delay
>> happens at the redisplay or immediately after the change?  With the
>> after-change f-l-e-r-f, only the two boundaries of the region get
>> checked, plus any chunk boundaries when this is bigger than 500 bytes.
>> With the extra pattern in f-l-keywords, then entire region gets
>> checked.

>But a single command may do thousands of buffer-modifications.

What is a typical number for an "advanced" command?

>Look at it this way.  Let's define things as follows:
>- a single buffer-modification, without your hook, takes time T1
>- font-locking, without my font-lock-multiline thingy, takes time T2
>- your hook takes times N1*T1
>- my font-lock-multiline takes time N2*T2

>So your approach can slow down user-visible execution by a fator N1,
>whereas mine can slow it down by a factor N2.  So the important question
>(to me anyway) is whether N1 is expected to be bigger or smaller than
>N2.

Equally important is T1 and T2.

>Note that in all likelyhood T2 is much larger than T1, so it should be
>expected that N1 is significantly larger than N2.

You've given a good argument for keeping both approaches available.

>> expensive in aggregate - it marks _every_ sequence which must be
>> atomically fontified, just in case that sequence might straddle a chunk
>> boundary in the future.

>No: it's only applied to those atomic elements which do straddle
>a line boundary.

My understanding of the form you were suggesting for AWK Mode's
f-l-keywords, ("^.*\\\\\n" . (progn ......)), was that this regexp would
be matched against ALL lines in the region, marking all multi-lines,
in case they might in the future come to straddle chunk boundaries.

>>> I'm as close as it gets to a font-lock maintainer.  So from where I
>>> stand, you're trying to impose your taste and judgment on me.

>> I'm as close as it gets to a CC Mode maintainer at the moment.  What's
>> constraining my freedom in that department now?  ;-)

>We're talking about font-lock code here.  You're free to do whatever you
>like in cc-mode, including adding an advice to
>font-lock-after-change-function.

Richard has specifically required this advice to be eradicated, on the
grounds that if such advice is necessary there's some deficiency in the
underlying functionality, and that deficiency should be fixed.

[ .... ]

>        Stefan

-- 
Alan.