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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20146: font-lock-extend-jit-lock-region-after-change: results are di


From: Stefan Monnier
Subject: bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned.
Date: Sat, 21 Mar 2015 18:30:26 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>> The major mode sets font-lock-extend-region-function and this functions'
>> result should be (and is) respected by the rest of font-lock.
> If only, but this is simply not the case at the moment.
> jit-lock-fontify-now has a hard-coded extension to whole lines,
> regardless of the contents of font-lock-extend-region-functions.

There's no relationship between the two.  The bounds that
font-lock-fontify-region are not under the major mode's control.
What is under the major mode's control is how those bounds are extended
by font-lock-extend-region-functions.

> This is surely a bug.

Nope.

> As a better idea, why not have jit-lock-fontify-now use
> f-l-extend-region-functions, and then pass the original `start' and
> `next' to f-l-fontify-region.

No, you have that backwards: it's f-l-fontify-region which runs
f-l-extend-region-functions, specifically so that you don't need to care
about what jit-lock (and other callers of f-l-fontify-region) might do
(you just need to make sure that f-l-fontify-region works correctly for
*any* bounds).

>> But callers of font-lock-fontify-region (such as
>> font-lock-after-change-function, or jit-lock) can choose *any* bounds
>> they feel like and font-lock-fontify-region should behave correctly.
> This seems to be true.  When I (setq font-lock-support-mode nil), things
> seem to behave properly.  It seems a poor workaround, though.

I don't see how what you say relates to what you quoted.


        Stefan





reply via email to

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