emacs-pretest-bug
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]