[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: perl mode color highlighting working badly
From: |
Stefan Monnier |
Subject: |
Re: perl mode color highlighting working badly |
Date: |
Thu, 13 Oct 2005 10:21:40 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
>>>>> "martin" == martin rudalics <address@hidden> writes:
>> > jit-lock breaks font-lock's handling of syntax-table properties anyway.
>> > Having syntactic properties behave correctly only for positions
>> > preceding `font-lock-syntactically-fontified' means that I can't parse
>> > text after that position reliably with `parse-sexp-lookup-properties'
>> > non-nil.
>>
>> But the same problem happens without jit-lock if you don't turn on
>> font-lock.
>>
>> How is this? Would you please explain what this problem is?
> font-lock uses `font-lock-fontify-buffer' to fontify the entire buffer
> initially and `font-lock-after-change-function' to fontify any new text
> inserted in the buffer. Both guarantee that the syntactic keyword pass
> is executed and syntactic properties assigned properly as described in
> section 23.6.9 of the Elisp manual.
> With jit-lock the syntactic keyword pass is executed only till the end
> of the window showing the highest so far displayed position of the
> buffer. This means that a parsing function investigating text after
> that position cannot rely on syntactic properties of the underlying
> text. Since jit-lock is turned on by default the manual should warn
> about this.
And as mentioned above, if font-lock is turned off the same parsing function
will equally be unable to rely on the syntax-table properties. So the only
situation where the problem cannot be reproduced without jit-lock is when
this parsing function is only used in font-lock and when it parses text past
the displayed text. I don't know of any such case.
>> Actually, in my experience, most/all the weird corner cases that
>> seem to be caused by jit-lock can be reproduced without jit-lock.
>>
>> Perhaps we should define a simple function that someone can call to
>> update the syntax-table properties for a certain region.
> `font-lock-fontify-syntactic-keywords-region' does that already. But
> for languages relying on syntax properties one would have to call that
> function before every scan-sexps, parse-partial-sexp, skip-syntax ...
Indeed. I've mentioned already a few times that the functionality offered
by font-lock-syntactic-keywords should be added to syntax.el (which means
make it independent from font-lock) after which font-lock-syntactic-keywords
can be made obsolete. We'll also probably need a way for this new
functionality to be triggered from scan-sexps, but that can come later.
And of course, this new functionality should ideally be a bit more
flexible/powerful than font-lock-syntactic-keywords so that the job done by
perl-font-lock-syntactic-face-function can be conveniently done there.
Stefan
Re: perl mode color highlighting working badly, martin rudalics, 2005/10/12
Re: perl mode color highlighting working badly, martin rudalics, 2005/10/13
Re: perl mode color highlighting working badly, Stefan Monnier, 2005/10/13
Re: perl mode color highlighting working badly, martin rudalics, 2005/10/14