Re: In praise of font-lock (Was: Re: [PATCH] Unconditional quit on SIGUSR2)

[Lennart Borgman]

On Mon, Mar 28, 2011 at 11:13 PM, Daniel Colascione
<address@hidden> wrote:
> On 3/28/2011 1:45 PM, Lennart Borgman wrote:
>>>
>>> Also, I strongly discourage anyone using fontification-functions
>>> directly.
>>>  Using this function bypass font-lock entirely, breaking font-lock-mode,
>>> add-font-lock-keywords, highlight-phrase, and other Emacs features.  It
>>> also
>>> adds no expressive power over font-lock-keywords, and IMHO,
>>> fontification-functions should be documented as being for internal use
>>> only.
>>
>> Thanks, I misremembered. I am using jit-lock-register.
>
> Well, thanks for not blowing away font-lock.  Still, why did you decide to
> use jit-lock-register instead of a function matcher in font-lock-keywords?

I am using this in wrap-to-fill.el in nXhtml to add 'wrap-prefix to
lines wrapped by visual-line-mode.

I got the advice from Stefan to use jit-lock-register directly and it
is simple and works very good. The net effect is that it works even if
font-lock is not on.

>  A matcher function can be as complex as you want: you can have it always
> return nil to skip font-lock's default logic and instead apply patterns
> using font-lock-apply-highlight.  The nice thing about this scheme is that
> it's portable, it's worked for years, and it'll continue to work no matter
> what fontification scheme we choose. It's not any less powerful than a
> function registered with jit-lock-register (which, granted, I haven't
> actually used) and it composes better with other users of font-lock with
> respect to prepending and appending faces.
>
> The neat thing about font-lock is that it allows creating rules using many
> different levels of sophistication.  It makes hard things possible and
> simple things easy. Plain regular expression defaulting to
> font-lock-keyword-face can coexist with recursive descent parsers in the
> same buffer, and mode authors can gradually increase the sophistication of
> their font-locking rules without having to leave the framework.  It's not
> perfect, particularly with respect to multiline matches, but it generally
> works pretty well and I don't see a good reason to bypass it.
>