Re: How to prevent font-lock (& jit-lock etc.) from refontifying?

Re: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Stefan Monnier]

> In Emacs 20, I only had to worry about lazy-lock doing this, and function
> lazy-lock-after-fontify-buffer was available to convince lazy-lock not to
> undo things behind my back. I could just call that function after
> highlighting, to fool lazy-lock into thinking there was no need to
> rehighlight. This function, lock-after-fontify-buffer, is still available in
> Emacs 21.

Such a hack will not prevent future re-highlighting (e.g. if you later on
make a change on the same line).  If that's good enough, then just do:

   (let ((inhibit-modification-hooks t))
     (put-text-property start end 'face 'toto))

> Please don't reply that I should just use font-lock-keywords and let
> font-lock do the highlighting. Assume that there is a reason I want to add
> some-face as the 'face property using put-text-property. Thanks.

Without knowing the reason why you want to do it, I can't give you a good
answer.


        Stefan

RE: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Drew Adams]

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

Re: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Stefan Monnier]

> Previously, function font-lock-after-fontify-buffer did the trick: it would

But this kind of use fell squarely in the category of ugly brittle
nasty hacks, so you get what you paid for ;-)

Using inhibit-modification-hooks is also a brittle ugly hack.
I think in your case the best option is to use overlays.


        Stefan

Re: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Oliver Scholz]

"Drew Adams" <drew.adams@oracle.com> writes:

> Thanks for your replies. Does anyone know if it is true that font-lock
> provides no way to prevent it from refontifying in the way I described? I'm
> thinking there must be a (simple) way that I'm ignorant of. I can't believe
> that they (we) would change font-lock in a way that lets it impose itself so
> completely.

Well, the idea (for the kind of buffers that use font-lock) is that
you either enhance font-lock to add your faces or that you use
overlays.

That said, CVS Emacs provides the text property `font-lock-face' which
you can use together with font-lock.  `font-lock-keywords' has a
higher priority, though. (Maybe that should be different?)

    Oliver
-- 
22 Vendémiaire an 213 de la Révolution
Liberté, Egalité, Fraternité!

How to prevent font-lock (& jit-lock etc.) from refontifying?

[Drew Adams]

In Emacs 21, suppose that I apply a face to certain spans of text. Maybe the
buffer is already font-locked before doing this, maybe not. In either case,
I want these spans of text to show the face I apply, overriding any
font-lock highlighting that might be there.

However, font-lock (jit-lock, I believe) works behind the scene to refontify
things the way it thinks they should look. That is, it effectively _removes_
any highlighting I go to the trouble to add.

In Emacs 20, I only had to worry about lazy-lock doing this, and function
lazy-lock-after-fontify-buffer was available to convince lazy-lock not to
undo things behind my back. I could just call that function after
highlighting, to fool lazy-lock into thinking there was no need to
rehighlight. This function, lock-after-fontify-buffer, is still available in
Emacs 21.

However, in Emacs 21, I do not see an equivalent way (or any other way) to
prevent _jit-lock_ from undoing my highlighting changes.

Example:

(put-text-property start end 'face some-face), where start and end specify
the text span to be highlighted, and some-face is just what it says.

I can set the buffer read-only and modified-p states back to what they were
before my highlighting action, but jit-lock still refontifies behind the
scene, overriding the some-face highlighting I added.

I've checked the source code (font-lock.el, jit-lock.el) and the Elisp
manual, but I don't see how to deal with this.

Please don't reply that I should just use font-lock-keywords and let
font-lock do the highlighting. Assume that there is a reason I want to add
some-face as the 'face property using put-text-property. Thanks.

RE: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Drew Adams]

Sorry, two points of clarification:

1. It looks like it's not jit-lock that's refontifying; and it's not
lazy-lock either. I don't know what is doing this.

2. The function I meant, to prevent rehighlighting behind your back in Emacs
20, is font-lock-after-fontify-buffer, not lazy-lock-after-fontify-buffer
(it calls lazy-lock-after-fontify-buffer or fast-lock-after-fontify-buffer,
as appropriate).

My question remains: how to prevent behind the scene refontifying in Emacs
21?

-----Original Message-----From: Drew Adams
However, font-lock (jit-lock, I believe) works behind the scene to refontify
things the way it thinks they should look. That is, it effectively _removes_
any highlighting I go to the trouble to add.

In Emacs 20, I only had to worry about lazy-lock doing this, and function
lazy-lock-after-fontify-buffer was available to convince lazy-lock not to
undo things behind my back.

Re: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Sacha Chua]

"Drew Adams" <drew.adams@oracle.com> writes:

> In Emacs 21, suppose that I apply a face to certain spans of text. Maybe the
> buffer is already font-locked before doing this, maybe not. In either case,
> I want these spans of text to show the face I apply, overriding any
> font-lock highlighting that might be there.

One workaround would be to use overlays instead, as overlays override
font properties. Not the answer you're looking for, but might be
helpful...

-- 
Sacha Chua <sacha@free.net.ph> - open source geekette
interests: emacs, gnu/linux, making computer science education fun
wearable computing, personal information management
http://sacha.free.net.ph/ - PGP Key ID: 0xE7FDF77C

Re: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Kevin Rodgers]

Sacha Chua wrote:
 > "Drew Adams" <drew.adams@oracle.com> writes:
 > > In Emacs 21, suppose that I apply a face to certain spans of text. Maybe the
 > > buffer is already font-locked before doing this, maybe not. In either case,
 > > I want these spans of text to show the face I apply, overriding any
 > > font-lock highlighting that might be there.
 >
 > One workaround would be to use overlays instead, as overlays override
 > font properties. Not the answer you're looking for, but might be
 > helpful...

Another technique I've used to work around this problem is to set the
category property instead of the face property:

(put 'foo 'face 'foo-face)
(put-text-property start end 'category 'foo)

-- 
Kevin Rodgers

RE: How to prevent font-lock (& jit-lock etc.) from refontifying?

[Drew Adams]

Thanks for your replies. Does anyone know if it is true that font-lock
provides no way to prevent it from refontifying in the way I described? I'm
thinking there must be a (simple) way that I'm ignorant of. I can't believe
that they (we) would change font-lock in a way that lets it impose itself so
completely.

-----Original Message-----From: Kevin Rodgers
Sacha Chua wrote:
 > "Drew Adams" <drew.adams@oracle.com> writes:
 > > In Emacs 21, suppose that I apply a face to certain spans of text.
Maybe the
 > > buffer is already font-locked before doing this, maybe not. In either
case,
 > > I want these spans of text to show the face I apply, overriding any
 > > font-lock highlighting that might be there.
 >
 > One workaround would be to use overlays instead, as overlays override
 > font properties. Not the answer you're looking for, but might be
 > helpful...

Another technique I've used to work around this problem is to set the
category property instead of the face property:

(put 'foo 'face 'foo-face)
(put-text-property start end 'category 'foo)