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

[David Kastrup]

Alan Mackenzie <address@hidden> writes:

> On Mon, 24 Apr 2006, Stefan Monnier wrote:

[...]

> I find the elisp manual page which describes font-lock-keywords
> ("Search-based Fontification") all but inpenetrable.  It's reduced me to
> tears on several occasions.  I've just spent five minutes looking through
> it, trying to find the description of the form you suggested to me:
>
>      (".*\\\\\n.*"
>       (0 (progn (put-text-property (match-beginning 0) (match-end 0)
>                                    'font-lock-multiline t)
>                 nil)))
>  
> .  I didn't find it.
>

[...]

>>You don't have to be familiar with the internals.  At least not more
>>than necessary to write the proper foo-before-change-function plus
>>foo-font-lock-lock-extend-region-after-change.
>
> With respect, Stefan, that's rubbish.  You need to know where and how to
> write the above Lisp form (the one starting (".*\\\\n.*" ...)) into
> f-l-keywords.  For me, that's perhaps half an hour to an hour of
> frustration trying to find the right place in "Search-based
> Fontification".

[...]

>>Here's my alternative implementation:
>
>>   (defconst c-awk-font-lock-keywords
>>      '(...
>>        (".*\\\\\n.*"
>>         (0 (progn (put-text-property (match-beginning 0) (match-end 0)
>>                                      'font-lock-multiline t)
>>                   nil)))
>>        ...))
>
>>Now which one's more direct and simple, really?
>
> The one which is adequately commented.

Not relevant.

> The one which doesn't use an obscure list structure that you need to
> look up in a manual.  The one with thin, obvious interfaces with the
> rest of Emacs.

It appears to me like you are uncomfortable around font lock
expressions.  And I doubt that anybody having worked with font lock
entries and syntax table entries has not teared out his hairs in
frustration several times round.

But I don't think that the solution is trying to move everything
somewhere else.  It would rather be sensible to create appropriate
accessor functions that save the programmer from having to deal with
the internal list structures.

We do similar things with the "event" data structure by having posn-*
accessor functions.  font-lock should be made more programmer-friendly
instead of delegating stuff to various ad-hoc hooks.

> I've tried, but I just don't have the intellectual capability to
> cope with such complexity without the greatest of difficulty.  You
> obviously do.  Complicated nested structures make my eyes glaze
> over.  There's a good chance I'm not the only Emacs hacker who has
> this sort of trouble.

Then we need to create functions or macros that build and access the
data structures.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum