[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new text property
From: |
Colin Walters |
Subject: |
Re: new text property |
Date: |
10 Jun 2002 02:53:33 -0400 |
On Mon, 2002-06-10 at 02:38, Stephen J. Turnbull wrote:
> What I do know is that font-lock itself has a minimum of five
> implementations (font-lock, font-lock-cache, lazy-lock, lazy-shot, and
> jit-lock).
Those are all ways of dynamically searching for text and placing `face'
properties on them. That's a very different approach from the way
`font-lock-face' is used.
Really, `font-lock-face' has nothing to do with what people
traditionally think of as "Font Lock" (i.e. regexps, searching), except
that it happens to be toggled on and off when the user types M-x
font-lock-mode. The amount of code dealing with `font-lock-face' in
font-core.el amounts to about 8 lines.
> Primitive highlighting has at least three interfaces
> (overlays, text properties, extents). This looks like an area ripe
> for consolidation, not proliferation, of APIs to me.
Yes, but adding `char-property-alias-alist' will not really increase the
difference between interfaces. XEmacs appears to already have
`default-text-properties', which is similar.
> I also don't like the idea that semantics apparently depend on whether
> a reference is an "original" or an "alias".
They don't.
> Thus the warning. This may be the right thing to do, but I want to
> make sure that XEmacs people _discuss_ this change rather than simply
> adopt it for the sake of compatibility.
I understand that. But could you please study `font-lock-face' a little
bit more carefully? The points you have raised so far don't really
apply to it.
Re: new text property, Colin Walters, 2002/06/10
Re: new text property, Hrvoje Niksic, 2002/06/10