[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: Drew Adams
Subject: RE: how to prevent font-lock from messing with a portion of text?
Date: Fri, 23 Mar 2007 10:13:06 -0700

> > Use put-text-property to add a face to some text using the
> > `face' property.
> > Prevent subsequent "erasure" of that highlighting by font-lock.
> The `font-lock-face' property was designed specifically for this
> kind of case.

1. That's only for Emacs 22.

2. It doesn't prevent font-lock from clobbering the highlighted text when
doing syntactic font lock (e.g. in comments).

3. The highlighting is removed when font-lock-mode is turned off.

4. It won't help with other code (e.g. 3rd library) that happens to use the
`face' property.

IOW, no, `font-lock-face' property was not at all designed specifically for
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.

Wrt Lennart's suggestion, BTW: I want to be able to also remove the
highlighting and then have font-lock treat that text normally again. So,
nothing that permanently prevents font-lock from fontifying the text would
be useful here.

As a simple example, imagine that you want to be able to use `M-o o'
(facemenu-set-face) on some text in a font-locked buffer. Currently, `M-o o'
just tells you that "Font-lock mode will override any faces you set in this
buffer" - IOW, you're SOL. If you want to see your highlighting, you must
turn off font-lock. Instead of punting this way, `M-o o' could do what's
needed to prevent font-lock from interfering - that is, from changing the
facemenu highlighting.

Yes, that would mean that font-lock highlighting could be thrown off,
depending on what `M-o o' highlighted, but that would be the chance the user
accepts by highlighting text with `M-o o'. The current design makes users
forego use of `M-o o' in font-locked buffers altogether.

That's just an example, to indicate the kind of thing I'm talking about:
using property `face' outside of font-lock to highlight some text, and not
have font-lock step all over it.

BTW, the doc does not explain anywhere (that I've found) just how the
activation of `font-lock-face' is controlled by `font-lock-mode'. It says
only that the mode toggles the activation of the property.

 - Node Precalculated Fontification: "activation [of `font-lock-face']
   is toggled when the user calls `M-x font-lock-mode'."

 - Node Special Properties: "state of activation [of `font-lock-face']
   is controlled by `font-lock-mode'."

IOW, the doc never says which is on and which is off. Please fix the doc to
make the toggle behavior explicit. It should say that property
`font-lock-face' is activated only when `font-lock-mode' is on.

> > I would like to be able to, say, set a particular text property
> > on the same text, which would cause font-lock to ignore that text (skip
> > over it, as if it weren't there).
> Again, there's no such general facility

That's too bad. How about adding that, after the release? It seems like a
simple way to prevent font-lock (not just jit-lock or whatever) from
touching certain characters. It's easy to add and remove, and it gives you
as fine-grained control as you like (individual characters).

Use: put text property `font-lock-ignore' on some text, and font-lock would
just skip over that text, ignoring it. Take property `font-lock-ignore' away
from that text, and font-lock would see the text again, taking it into
account when fontifying.

I think this would be a reasonable general mechanism, and I imagine that the
implementation would be straightforward, even trivial.

Unlike property `font-lock-face', `font-lock-ignore' would not be under the
control of `font-lock-mode'. Code could use `font-lock-ignore' to control
the visibility (on/off) of text portions to font-locking.

> > I thought that's what property `fontified' (= t) would do, but
> > that seems not to be the case.
> `fontified' is a jit-lock thing, so don't expect to be able to use it to
> solve font-lock problems.

OK. That's not clear to me from the doc, however.

> > The Elisp manual says this about `fontified':
> >
> >      This property says whether the character has a face assigned to it
> >      by font locking.  The display engine tests it to decide whether a
> >      buffer portion needs refontifying before display.  *Note Auto
> >      Faces::.  It takes one of three values:
> >
> >     `nil'
> >           Font locking is disabled, or the character's `face' property,
> >           if any, is invalid.
> Huh?  I don't agree with this part of the manual.  `nil' means that the
> fontification is not uptodate (so it will be refontified next
> time the block is made visible, for example).
> So I think the term "invalid" is a bit strong here.  Also it's not "font
> locking is disabled" but "jit-lock is disabled".

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

reply via email to

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