Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

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

>> You haven't shown any evidence of inefficiency.

> I think I have, in our previous discussion.  I think it's clear that
> f-l-multiline properties are erased throughout the change-region, and
> have to be recalculated througout the change region, at every change.
> For most C-like languages, this will be expensive for large regions.  Of
> all the CC languages, you can only determine f-l region boundaries
> cheaply in AWK (and maybe IDL).  By contrast, f-l-extend-region only
> needs to do the calculation at the two ends of the changed region, and
> has to do it just as often.

I think you're comparing apples and oranges.

And even if it weren't, it's still no evidence of inefficiency (by
"evidence" I mean actual user-visible slowdown).  In all the examples I've
shown, there is no calculation to be done for f-l-multiline: just add the
property at the time when you know where to put it (i.e. you've already
done the calculation for the purpose of highlighting anyway).

> This extra calculution will delay the display of fresh buffer areas when
> scrolling, for example.

I must be missing your reference again.

>> > Is there any chance of you adapting the font-lock-multiline mechanism
>> > so that the properties can be applied _before_ fontification, exactly
>> > where they are needed, rather than _after_ fontification throughout
>> > the entire change region?

>> That's the thing on the backburner.  But it's still unrelated to the
>> OP's problem which was specifically about *re*fontification, where the
>> current font-lock-multiline support is all you need (and if you don't
>> like it, there are already several existing alternatives, see the
>> lispref manual).

> Could you be more explicit here, please, on what these alternatives are?

- jit-lock-defer-multiline
- your new font-lock after-change-function hook (currently called
  font-lock-extend-region-function)

> I've not been aware of them up to now.

Sorry to disappoint you, you knew them.

>> >     public Bar    // Bar fontified as a type, at first 
>> >                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> Oh, I see.  It seems very minor.  Why do you care?  Is the performance
>> difference ever noticeable?  If yes, how often?

> I don't think we should be so casual about other people's processor
> cycles.  The performance difference will be very noticeable if Emacs ever
> comes to be run on application servers rather than individual desktops,
> for example.  If "public Bar" were a 20-line declaration, the delay might
> well be noticeable, especially on the sort of older PC's which still
> permeate the developed world.  ;-)

But the delay will be noticable anyway when editing the 20 line declaration
itself (which sems just as likely as editing a comment that follows it):
solving it for the comment is not enough, you need to be able to rehighlight
just the line that was touched, even if it was part of a long
multiline element.  At this point, unless you have very long lines, having
to round up to a whole number of lines is not much of a problem either.

Anyway, I'm not opposed to your proposed change to allow
non-wholeline fontification.  I doubt it'll be useful, but I can't see it
hurting either.

> Indeed, not.  But doing our stuff in a way that obfuscated C works right
> at no extra cost is not a bad way to go.

Agreed, but it's very different from what font-lock was designed to do.


        Stefan