Re: Last steps for pretesting (font-lock-extend-region-function)

[Stefan Monnier]

>> BTW, I still intend to move font-lock-extend-region-function from
>> after-change-functions to font-lock-fontify-region (or maybe even
>> jit-lock-fontify).

> That would radically change the meaning of the function.

Of course.

> Please keep Font Lock working equivalently with and without JIT switched
> on.  Edebugging through font-lock-fontify-region (for debugging a mode's
> font lock settings) is a nightmare when JIT is enabled.

Yes, OK, don't worry about the jit side-comment.

> How about the following compromise?  font-lock-extend-region-function
> should get called BOTH in the two after-change functions AND in
> jit-lock-fontify-now and font-lock-default-fontify-region.

No, my problem is specifically with calling it from after-change-functions.

>> So if you really manage to use the current
>> font-lock-extend-region-function (called from after-change-functions) in
>> a way that's robust, efficient, .....

> So far, yes (except, perhaps, for the need of an extend-region function
> in j-l-f-n and f-l-d-f-r).

So your code needs extend-region both in a-c-f and in f-l-d-f-r ?

>> .... and can't be done as efficiently/elegantly/robustly with a hook in
>> font-lock-fontify-region (or with the font-lock-multiline property),
>> please scream.

> AAAAAAAAARRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!

> I don't think we're going to agree on the relative elegance of
> font-lock-extend-region-function vs. font-lock-multiline.  I think that
> the former is more elegant than the latter, and you think the latter is
> the more elegant.

Of course, we don't have to agree on every detail.

> I'm convinced that either approach would be robust (hey, we're competent
> hackers ;-).

I'm convinced that only using a-c-f would *not* be robust, no matter how
competent the hacker.

> However, I think that f-l-extend-region-function can be done more
> efficiently by the major mode maintainer, in the sense that it will
> require less time and effort reading manuals, reading fine source, and
> coding.

more efficiently than what?


        Stefan