From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Devel" <emacs-devel@gnu.org>
Subject: RE: how to prevent font-lock from messing with a portion of text?
Date: Fri, 23 Mar 2007 10:13:06 -0700 [thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMCEBEDAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <jwvk5x8q777.fsf-monnier+emacs@gnu.org>
> > 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
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.
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.
next prev parent reply other threads:[~2007-03-23 17:13 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-22 16:56 how to prevent font-lock from messing with a portion of text? Drew Adams
2007-03-22 18:35 ` Stefan Monnier
2007-03-22 19:20 ` Drew Adams
2007-03-22 20:09 ` Lennart Borgman (gmail)
2007-03-22 20:49 ` Drew Adams
2007-03-22 21:40 ` Lennart Borgman (gmail)
2007-03-22 21:57 ` Miles Bader
2007-03-23 16:07 ` Stefan Monnier
2007-03-23 17:13 ` Drew Adams [this message]
2007-03-23 17:31 ` Lennart Borgman (gmail)
2007-03-23 22:36 ` Stefan Monnier
2007-03-24 1:33 ` Drew Adams
2007-03-24 1:57 ` Lennart Borgman (gmail)
2007-03-24 4:21 ` Stefan Monnier
2007-03-24 8:20 ` Lennart Borgman (gmail)
2007-03-25 3:11 ` Stefan Monnier
2007-03-25 3:31 ` Lennart Borgman (gmail)
2007-03-24 4:20 ` Stefan Monnier
2007-03-26 1:48 ` Drew Adams
2007-03-26 1:59 ` Lennart Borgman (gmail)
2007-03-26 5:52 ` Drew Adams
2007-03-26 8:47 ` Lennart Borgman (gmail)
2007-03-26 14:49 ` Drew Adams
2007-03-26 13:01 ` Stefan Monnier
2007-03-26 13:26 ` Miles Bader
2007-03-26 15:56 ` Drew Adams
2007-03-26 15:56 ` Drew Adams
2007-03-26 19:11 ` Stefan Monnier
2007-03-26 20:14 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EIENLHALHGIMHGDOLMIMCEBEDAAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.