[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: Re: how to prevent font-lock from messing with a portion of text?
Date: Mon, 26 Mar 2007 15:11:57 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.96 (gnu/linux)

>> >     (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.

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.
But still, the performance impact is a problem, because the benefit is
so small.

> 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.

There's no misunderstanding.

>> 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

> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]