Re: jit-lock refontifies too much

[martin rudalics]

>>Hence in at least 99 out of 100 cases contextual fontification just slows
>>down editing and wastes processor cycles.
>
>
> In theory, that's true.  In practice, I've yet to come up with a case where
> it's noticeable.  Have you actually perceived this slow down, or are
> talking hypothetically?  What do you compare it against?  Remember that in
> Emacs-21, the exact same wasteful redisplay took place, except that it took
> place after 3s of idle-time rather than 0.5s.
>

I'm only comparing Emacs-22.1 jit-lock with my patch.  On a 1GHz machine
setting jit-lock-context-time to zero seconds makes Emacs stutter when I
use auto-repeat to insert a sequence of characters.  Patched, I can set
this to zero seconds and won't suffer any delays as long as I don't
insert, for example, a sequence of string delimiters.  With faster
hardware the slowdown might go away.  GC overhead stays.

>
>>The problem could be resolved by using the following reasoning (please
>>correct me if I'm wrong):
>
>
>>- Syntactic context is correctly established via the face property
>>   assigned to a character by font-lock.  As an example, font-lock
>>   assigns a character the font-lock-string-face property iff that
>>   character is within a string - according to the best knowledge of
>>   syntax-ppss.
>
>
> That's not quite true since the font-lock-string face may be used for
> elements not recognized by the syntax-tables.  But the exceptions are very
> rare anyway and probably don't affect your proposed solution.

Anyway, the "iff" is wrong.

>
>
>>- The syntactic context of a character may change iff preceding text is
>>   modified (I ignore syntax table switching here).
>
>
> Actually, jit-lock-multiline ws introduced specifically because this is not
> necessarily the case.  In Perl, if you change
>
>             s{a}{b}ex;
> into
>             s{a}{b};
>
> the syntactic context of `b' is changed.  Yes: Perl's syntax sucks.
> But again, this shouldn't affect your proposed solution.
>

But this is already beyond syntactic fontification, that is, current
font-lock-fontify-syntactically-region using syntax-ppss only can't
handle this.  And my solution should handle jit-lock-multiline much the
same way original jit-lock does.  Anyway, you're right.  I would have to
say something like "syntax-pps recognizes changes in the syntactic
context of a character iff text preceding the character is modified".

> If you change
>
>     (* (* this is a nested comment
>           blabla *)
>        end of comment *)
>
> to
>
>     (* this is a nested comment
>           blabla *)
>        end of comment *)
>
> the char after your modification will still be on font-lock-comment face,
> but the text "end of comment *)" needs to be refontified.

Elementary.  It's not the first time I'm stumbling over nested comments.

> Wait, I don't
> even need nested comments, just take C mode:
>
>      /* sfsgf
>         tryjjy */
> to
>      //* sfsgf
>         tryjjy */
>
> Although in your case jit-lock will round up the "change" to a whole line,
> so the problem shouldn't bite you in the case of C.

It does, however.  I would have to syntax-ppss the start of the
following line in order to handle this.  Your examples reveal the major
weakness of my approach.  I'm not able to handle changes in the type of
the first delimiter of a delimited expression as long as the face of an
enclosed character may stay the same.

>
> The above problems can be "easily" addressed by changing your algorithm to
> not look at the face property, but instead to look at the return value of
> syntax-ppss.  If it hasn't changed, then we know the subsequent text doesn't
> need refontification.
>

I don't remember any previous return value when refontifying.  Calling
syntax-ppss twice for the same position in one and the same invocation
of jit-lock-fontify-now always yields the same value.

>>There is one complication: When text has not been fontified yet, the
>>comparison described above would always indicate a context change.  This
>>would be inefficient in some cases, for example, when scrolling backward
>>into unfontified text.  The patch of jit-lock below tries to avoid this
>>by using an additional text property called "jit-lock-context".
>
>
> Adding yet-another-text-property is a waste of precious CPU and
> memory resources.  It makes your suggestion pretty dubious.  Luckily, using
> syntax-ppss instead of faces should not suffer from this same initialization
> problem.
>

The property would last only as long as there are unhandled buffer
changes.  However, it does waste resources.  Too bad that syntax-ppss
won't work.