Re: jit-lock refontifies too much

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

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

Oh, yes, if you set it to 0s the slowdown will be noticeable, especially in
buffers where the font-lock patterns are complex, such as in C mode or
Perl mode.  That's partly why the default is only 0.5s.

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

Exactly.  There may be some other cases, tho.  E.g. in elisp-mode, if you
change

        (defvar foo 1
          "hello")
to
        (defvar foo '(1
          "hello")

the "hello" needs refontification (from font-lock-doc to font-lock-string).
In the above case, the syntax-ppss state changes, so using that would solve
this problem.  But changing

        (defvar foo 1
          "hello")
to
        (defvar foo 0 1
          "hello")

also requires a similar refontification, but the syntax-ppss state doesn't
really change, so even using syntax-ppss wouldn't solve this problem.

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

Oh, right, when jit-lock-fontify-now gets called, the buffer is already
changed, so you'd have to use a before-change-functions hook to remember the
syntax-ppss state before the change.  Hmmm...


        Stefan