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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Look at my suggested patch for cc-awk and you'll see that you never need to
compute anything extra: you just have to place the font-lock-multiline
property at the moment where you highlight the multiline element (at which
point you already have all the necessary info).

My experience has been that this has always been the case.  And it's not
a coincidence.

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

Both T1 and T2 are outside the scope of this discussion, so I'm not sure why
you find them important.

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

Why?  Because you think that in some potential hypothetical case, T2 might
be smaller than T1?  In my experience not only is T2 always much larger than
T1, but N2 is also tiny (because it's really nothing more than adding a few
put-text-property calls).  So the reverse case sounds hopelessly unlikely
to me.  Get back to me when you've found one.

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

Oh yes, that's the case, sorry I misunderstood your use of "chunk" (even
though it was indeed quite clear, my fault).  So the only correction I'd
make to your claim is that it's not "_every_ sequence which must be
atomically fontified", but "_every_ multiline sequence which must be
atomically fontified" (that was probably meant implicitly).

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

Yes, and there is no such deficiency, as shown with my sample patch, using
font-lock-multiline.


        Stefan