[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: How to prevent font-lock (& jit-lock etc.) from refontifying?
From: |
Drew Adams |
Subject: |
RE: How to prevent font-lock (& jit-lock etc.) from refontifying? |
Date: |
Wed, 13 Oct 2004 15:07:35 -0700 |
I guess that's as close as I'll get to what I was looking for. In this
case, I can use inhibit-modification-hooks, but in general that does more
than just tell font-lock not to refontify; it inhibits all
*-change-functions.
I just wanted to be able to write some code that highlights things
regardless of the buffer mode and regardless of whether font-lock-mode is
on. Yes, the highlighting could be temporary until a buffer change.
Besides using inhibit-modification-hooks, it looks like there is now no way
to tell font-lock not to refontify. IOW, "you can't get there from here".
Either:
- the user happens to be using font-lock, in which case you could either
add the highlighting regexps to font-lock-keywords or use font-lock-face
- or the user doesn't happen to be using font-lock, in which case your code
cannot depend on font-lock to do the highlighting
So, without resorting to inhibit-modification-hooks, it looks like you would
need to test whether font-lock is currently turned on, and use a _different
implementation_ accordingly. That seems absurd.
I guess I may try doing something with overlays.
BTW, what was wrong with the situation before -- where font-lock did its
thing but didn't try to rule the roost, and gave you a way to _prevent it
from refontifying_ -- when you knew it didn't need to refontify (or when you
didn't want it to refontify)?
Previously, function font-lock-after-fontify-buffer did the trick: it would
tell font-lock that the buffer has already been fontified and doesn't need
fontifying (until a buffer change is made).
That function still exists, and it still does the same thing - but only for
fast-lock and lazy-lock fontifying. Here's the code, including a
commented-out part that suggests that someone once had it working for
jit-lock too:
(defun font-lock-after-fontify-buffer ()
(cond ((and (boundp 'fast-lock-mode) fast-lock-mode)
(fast-lock-after-fontify-buffer))
;; Useless now that jit-lock intercepts font-lock-fontify-buffer. -sm
;; (jit-lock-mode
;; (jit-lock-after-fontify-buffer))
((and (boundp 'lazy-lock-mode) lazy-lock-mode)
(lazy-lock-after-fontify-buffer))))
Shouldn't this function have the same effect in all font-lock modes,
including jit-lock? Shouldn't it always tell the fontification code not to
do anything until the buffer changes? The comment (yours, I guess) seems to
indicate that this can't be done now (even if it should be done) because
jit-lock intercepts font-lock-fontify-buffer. Does that mean that this
function was neutered because of the way jit-lock happened to be
implemented?
Maybe this function can't do the trick anymore, but don't you think there
should at least be a variable to calm font-lock down (like
inhibit-modification-hooks, but affecting only fontification)?
- Drew
-----Original Message-----From: Stefan Monnier
just do: (let ((inhibit-modification-hooks t))
(put-text-property start end 'face 'toto))