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

[Alan Mackenzie <acm@muc.de>]

Hi, Stefan!

On Thu, 20 Apr 2006, Stefan Monnier wrote:

>>> 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.

>> 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.

You mean in calling it ONLY from a-c-f?  Or from calling it in
after-change-functions at all?

>>> 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 ?

Yes.  The region needs extending in two distinct circumstances:
(i) In after-change, to determine the entire region which needs
  refontifying;
(ii) In jit-lock-fontify-now, to ensure that each chunk starts and stops
  at a "safe place".
These are logically disjoint.  But it seems that the major mode code to
do each of them is so similar, that we might as well just have a single
function, font-lock-extend-region-function, called in two different ways.

>>> .... 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.

I agree with you here.

>> 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?

More efficiently than setting font-lock-multiline text properties.

>        Stefan

-- 
Alan.