Re: new text property

[Miles Bader <miles@lsi.nec.co.jp>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
> Er, as I understood that thread, the rationale is that font-lock is
> too heavy (aka "slow and broken") to be used by modes that just want
> some "light-weight" highlighting.  Is that not so?  Are there other
> advantages to not using font-lock to do font-locking?

Some modes just want to do their own face manipulation because it's
simpler, faster, and in some case, _possible_ -- there are types of
formatting which _cannot_ be done by font-lock, because they depend on
external information (it was suggested to retain such information using
a non-face text-property, and then have font-lock continually update the
face property using it, but that's just silly).

Rather than trying to shoehorn such modes into font-lock's model,
Colin's change simply allows modes to easily use whichever method suits
them best (and in fact, they could use both at the same time).

BTW, the `char-property-alias-alist' variable is used to implement the
`font-lock-face' feature, but otherwise is independent of font-lock, and
potentially useful on its own.

> I don't mean I oppose `font-lock-face' as such, but we should be
> careful to not put obstacles in the way of a high-performance
> font-lock

Which obstacles are those?

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.