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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I don't claim it's buggy or even more buggy than font-lock-multiline.
>> It's just an ugly kludge, .....

> I can't understand at all why you feel that.  I really can't.  To me,
> f-l-e-r-f seems natural, simple and obvious.  Optionally setting a hook
> variable to a function is done countless times in Emacs.  I can't see why
> font-lock-extend-region-function is any more ugly than, say,
> adaptive-fill-function.

I'm not saying the hook is a kludge: I'm saying the code that uses it is
a kludge, compared to the code that uses font-lock-multiline.

>> ....much more heavyweight codewise (this is objectively the case in
>> terms of lines of code, and I hope my comparison above convinces a few
>> more people that it's also subjectively the case).

> This is not the case.  We're agreed that, for the f-l-multiline mechanism
> to work, it needs supplementing by a f-l-extend-region-function hook.

Yes, it needs such a hook called from font-lock-default-fontify-region.
Just like your current hook that's called from
font-lock-after-change-function.  This is orthogonal.

> If we need this hook anyway, why complicate it with f-l-multiline when the
> hook works just fine on its own?

There are two alternatives when writing your code in cc-mode:
- use a hook in f-l-d-f-r + font-lock-multiline.
  The font-lock-multiline part of the code is a couple lines added to
  font-lock-keywords.
- use a hook in f-l-d-f-r + a hook in f-l-a-c-f + a hook in b-c-f.
  The *-change-function part of the code is a good bit more than
  a couple lines.

In which way does font-lock-multiline complicate "it"?


        Stefan