RE: how to prevent font-lock from messing with a portion of text?

[Drew Adams]

> Sorry, I misread your code.  I didn't pay attention to your loop.
> Boy, this is way too inefficient.  You can make it a bit better using
> next-property-change, at least.

Yes, I mentioned that (I mentioned `next-single-property-change', actually).

> But still, the performance impact is
> a problem, because the benefit is so small.

It depends on what is observed in practice. I don't claim that others will
observe the same in all contexts, but I don't notice any slowdown during
fontification. There surely is a slowdown, because of the naive
implementation, but I don't notice it.

The question is, is the slowdown a problem in practice? I find that even
buffers that were large (~500K chars) present no problem. And very, very,
large buffers are not completely font-locked by default anyway. IOW, it's
not clear that this would really affect what users perceive.

As I mentioned, unfontifying is a different matter - there, the slowdown is
noticeable and unacceptable, and a C implementation would be needed to
compare with the current C implementation
(`remove-list-of-text-properties').

> >> OK, here's another option: don't change anything to font-lock, don't
> >> fiddle with it at all, just don't use text-properties to add
> >> your special faces.  Use overlays instead. Problem solved
>
> > As I said, my own highlighting library uses overlays by default. But
> > sometimes text properties are useful. Facemenu is one example.
>
> I don't see any reason why facemenu should use text-properties rather than
> overlays.

Facemenu is an example. I suspect that there are good reasons that it uses
the `face' text property (e.g. input of new text?), but I won't argue for or
against that use.

Applications other than facemenu, for whatever reasons, might well use
property `face' for things other than font-locking. There's nothing that
discourages them from doing that, and nothing should. Overlays are not a
general replacement for text properties.

As it stands now, applications cannot really do that and expect font lock to
play well with them. That was my point in suggesting that we turn your
(`persistant-face') suggestion on its head, and use a dedicated property for
font lock - IOW, not have font lock use property `face' at all. That would
be a solution that should have no performance penalty.

The point is that font-lock today uses property `face', and so do/will other
applications, and font lock is not a good neighbor, effectively erasing any
`face' property (erase: the visual effect, not the property itself) that it
does not "own".

The solution, as I see it, is to either 1) move font lock to its own
non-`face' property or 2) have some other mechanism to tell font lock "hands
off!" a given portion of text. I'd prefer the former, for a variety of
reasons; the latter is an ugly little hack, and entails some performance
hits.

> > As it stands now, any application that uses the `face' text
> > property gets that highlighting trampled on by font lock -
> > there is no simple way for an application to prevent that.
> > That, to me, is undesirable.
>
> We all agree.  The differnece is whether we consider it
> sufficiently serious to warrant action and performance penalties.

Cantoning font lock to its own text property (or properties) should not
imply a performance penalty. Doing a `font-lock-ignore' workaround such as I
suggested (but with an optimized implementation) is second best, AFAICT. I
hope some solution to font lock's bad-neighborliness is found (after the
release).