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

[Daniel Colascione]

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