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

[Drew Adams]

> > (defun put-text-property-unless-ignore (start end property
> value &optional
> > object)
> >   "`put-text-property', but ignore text with property
> `font-lock-ignore'."
> >   (let ((here (min start end))
> >         (end1 (max start end)))
> >     (while (< here end1)
> >       (unless (get-text-property here 'font-lock-ignore object)
> >         (put-text-property here (1+ here) property value object))
> >       (setq here (1+ here)))))
>
> This will still override a face on a word inside a string, because
> (get-text-property <string-start> 'font-lock-ignore object) will be nil.
> You need to check for the presence of the property over the whole
> start..end region.

I have a string in an emacs-lisp-mode buffer. I highlight a word in the
string using property `face' and I put property `font-lock-ignore' on it
also. I turn font-lock on and off - the word highlighting stays. I modify
the file and save it - the word highlighting stays. I highlight the whole
string, or more than a word, with the highlighting starting or ending on or
off a word boundary - the highlighting stays. I don't see the problem you
mention.

Could you explain the problem differently (e.g. recipe to test)? I no doubt
misunderstand.

> > 2. In font-lock.el, use this definition of
> > `font-lock-default-unfontify-region':
>
> > (defun font-lock-default-unfontify-region (beg end)
> >   "Unfontify from BEG to END, unless text with property
> `font-lock-ignore'."
> >   (let ((here (min beg end))
> >         (end1 (max beg end)))
> >     (while (< here end1)
> >       (unless (get-text-property here 'font-lock-ignore)
> >         (remove-list-of-text-properties
> >          here (1+ here) (append font-lock-extra-managed-props
> >                                 (if font-lock-syntactic-keywords
> >                                     '(syntax-table face
> font-lock-multiline)
> >                                   '(face font-lock-multiline)))))
> >       (setq here (1+ here)))))
>
> Same thing here, except even more so.

Please give me a recipe to test. I don't say I don't believe you or that the
code above is foolproof, but I'd like to see what the problem is.

> Then the problem becomes that doing all those extra checks costs time, all
> the time, for a feature which will be almost never used.

I already spoke to performance. I don't claim that the above code is
optimized. I intended it to show in general terms what I meant, so there was
no misunderstanding about that.

> 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. The
differences that generally make overlays more useful for highlighting also
mean that they are less useful in some contexts. The fact that copying and
pasting text doesn't pick up overlays is one example: sometimes you might
want the faces pasted.

Every difference implies advantages and disadvantages. Text properties are
associated with text; overlays are associated with buffer positions, and so
on. This request is about letting a user-applied `face' property play well
with font-locking. That's all.

As I said, I'm not glued to any particular mechanism or implementation for
allowing that. If it can be proven that any reasonable implementation would
slow things down unacceptably, then an option could be used to turn on the
more costly behavior.

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.