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

[Drew Adams]

> > 2. It doesn't prevent font-lock from clobbering the highlighted
> >    text when doing syntactic font lock (e.g. in comments).
>
> It's true that font-lock's own faces take precedence.  But the
> font-lock-face property is not clobbered.

I said that the "highlighted text", that is, the _highlighting_, is
clobbered.

> > 3. The highlighting is removed when font-lock-mode is turned off.
>
> Again, the lont-lock-face properties are not removed.  But yes, it is made
> inactive.

Again, I didn't say anything about removal of the `font-lock-face' property.
I said that the "highlighting" is removed. Highlighting is a visual effect.
The highlighting that a user adds is wiped out. The text property might
still be there, but the highlighting that was its purpose is gone.

> > IOW, no, `font-lock-face' property was not at all designed
> > specifically for this kind of case. Highlight some text, and have
> > it stay highlighted whether or not font-lock-mode is on. Have
> > font-lock ignore that text when it does its own highlighting.
>
> Well, with those extra conditions, then indeed, no it doesn't quite fit
> your bill.

Not much "extra" about that. Do you think that users who want to highlight
portions of a buffer (e.g. matching regexps) only want to do so in buffers
that are not font-locked?

For example, facemenu stuff such as `facemenu-set-face' is useless for
font-locked buffers, only because of this limitation. We give users a lame
message telling them, in effect, Fuggedabowdit!, only because we are unable
to tell font-lock "Hands off!" of the highlighting that users add using
facemenu (or other highlighting packages).

I have a highlighting library, for instance
(http://www.emacswiki.org/cgi-bin/wiki/HighLight), that lets you use either
overlays or text properties. If you choose to use text properties, font-lock
clobbers the highlighting. One use of text properties is to do essentially
what `facemenu-set-face' does, including entering new text in some face.
Useless in a font-locked buffer, only because of this silly limitation.

Now, if font-lock didn't itself use the `face' property, things might be
OK...

Or, as I said, if one could at least set some other property (e.g.
`font-lock-ignore') that told font-lock "Hands off!" this text...

> How 'bout:
> - use font-lock-mode-hook to move `face' properties to/from a new property
>   `persistent-face' when turning font-lock-mode on/off.

It's a joke, right? Why don't you make font-lock use such a property itself,
all the time? Make it independent of `face' altogether.

> - add a font-lock-fontify-region-function so that after fontifying
>   the region normally, you scan the region for `persistent-face'
>   properties and copy those to the `face' property.

Right (ridiculous). Move all of `face' to `persistent-face' and then back
again. And besides such a convoluted, heavy workaround?

What about all of those "many different ways, each one with advantages and
quirks" that you promised? How about _one_ simple way to tell font-lock
"Hands off!" this text?

> > That's too bad.  How about adding that, after the release?
>
> I'm not interested in coding it up because I don't see a need for
> it, but if someone provides a clean patch, I don't see any reason
> why I'd oppose it.

I hope someone does. I would myself, if FFS could accept it without employer
papers. I can't believe it would be hard for font-lock to check if text it
wants to work with has an ignore-me property.

Or some other mechanism that allows the same feature: be able to apply
property `face' to some text and not have that highlighting overridden by
what font-lock does. I'm not wedded to any particular way to implement that
feature, but I think it's a needed feature.

> > From what you say, it sounds as if that whole passage about
> > that property should be stated in terms of jit-lock only. And there
> > should be a cross reference to the place where jit-lock is introduced.
>
> Yes, that's probably right.

Glad we could agree about something.

I'd add that the Elisp manual is pretty poor on explaining font lock,
generally. Start with `i font-lock' and see what you get. Keep hitting `,'
and see if you get a good view of what font-lock is all about.

Or start with node _Font Lock Mode_ (the best place to start, and in the
main menu, but not easy to stumble upon with `i'). There's not much in that
first node.  That's fine, but what happens when you go to the next node,
_Font Lock Basics_, which has the menu-item description "Overview of
customizing Font Lock"?

1. That node is simply a description of variable `font-lock-defaults'.

2. That node has nothing to do with "customizing Font Lock", in spite of
what was advertised.

3. That node is _not_ an overview of font lock or a description of "font
lock basics". It's almost the farthest thing from the basics.

Node _Search-based Fontification_ is closer to an overview of font-lock
customization ("the most important variable for customizing..."), but it is
still not the place to start. There should be a real overview of font lock
at the beginning: what it is, what it's for (why), how to customize it
(although that really belongs in the Emacs manual), and how it works. It
should include a getting-started example or two, showing how to use font
lock in your own code (including how to get around it).

I submit that the font-lock doc is not easy to read. You pointed out one
area where it is also incorrect. It would be good if someone who is familiar
with the purpose, use, and implementation of font lock would reread the doc
and try to improve it.