[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: jit-lock refontifies too much
From: |
Stefan Monnier |
Subject: |
Re: jit-lock refontifies too much |
Date: |
Thu, 22 Sep 2005 13:37:38 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
> 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
- jit-lock refontifies too much, martin rudalics, 2005/09/12
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/12
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/14
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/14
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/15
- Re: jit-lock refontifies too much, Richard M. Stallman, 2005/09/19
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/20
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/21
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/21
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/22
- Re: jit-lock refontifies too much,
Stefan Monnier <=
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/25
- Re: jit-lock refontifies too much, Richard M. Stallman, 2005/09/26
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/27
- Re: jit-lock refontifies too much, Richard M. Stallman, 2005/09/28
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/27
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/28
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/28
- Re: jit-lock refontifies too much, martin rudalics, 2005/09/29
- Re: jit-lock refontifies too much, Stefan Monnier, 2005/09/29
- Re: jit-lock refontifies too much, Richard M. Stallman, 2005/09/24