Re: new text property

[Hrvoje Niksic]

Colin Walters <address@hidden> writes:

> The rationale for this change is that it easily allows "special"
> modes to have their fontification controlled by M-x font-lock-mode,
> rather than having to set a variable like `cvs-highlight',
> `Info-fontify', or tracking down a -face variable and setting it to
> `default'.

I don't understand why it would be desirable for font-lock-mode to
control non-font-lock highlighting.

If there is a need to manipulate faces on the buffer level, such as
turning them all off, regardless of whether they come from font-lock
or from another source of highlighting, shouldn't that be made
generic?  That way both font-lock and other sources of highlighting
could be using the same feature.  For example, the extents used for
highlighting could have a `highlight' property whose presence would
indicate that it's ok to remove their `face' property at the request
of the user.

I don't think char-property-alias-alist makes sense, as we don't use
char properties, except in the compatibility layer.  Adding features
only to that compatibility layer is dangerous because we often want
the properties to be accessible from both interfaces.

> It would be nice if XEmacs could support `char-property-alias-alist' in
> its entirety (I bet all you need to change is `extent-get'),

I don't know what extent-get is, but supporting
char-property-alias-alist would surely require more changes, such as
in map-extents, extent-at, and many others.