[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
font-lock-extend-region (was: address@hidden: C++-mode: Syntax highlight
From: |
Stefan Monnier |
Subject: |
font-lock-extend-region (was: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]) |
Date: |
Mon, 20 Mar 2006 03:16:28 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
> DONE. In the process, I moved the processing of font-lock-lines-before
> from font-lock-default-fontify-region into
> font-lock-after-change-function and jit-lock-after-change, so as to be
> able to stop them interfering with eachother.
OK, having thought some more about it, I'm really convinced doing it in
after-change-function is the wrong way: your jit-lock code won't always do
the right thing, because even though you mark the whole extended region for
refontification, jit-lock may refontify it in chunks (and maybe not even in
the intended order).
So I will move the font-lock-extend-region code to
font-lock-default-fontify-region where it belongs (which is why that's also
the place where font-lock-extra-lines was handled and where
font-lock-multiline is handled).
Now IIUC that means it'll break some/all of your uses of that variable.
Clearly you won't be pleased, but think about it this way: it'll save you
bug reports from users seeing odd behavior in conjunction with jit-lock.
Anyway, as I said, for your use case what you should be using is an
after-change-functions hook that puts a font-lock-multiline property.
But as you noted, this will only work if your hook happens to be placed in
after-change-functions before font-lock's own (or jit-lock's, though that
one is much less serious).
Also as I mentioned elsewhere, another solution is to change your
requirement such that some of the responsibility of the refontification is
passed on to contextual refontification: I would tend to prefer this
solution myself (it moves work away from the time-critical path).
But admittedly, setting jit-lock-context-time to 0 is believed to be a bit
too costly right now (not enough optimizations), so if you really want the
refontification to be immediate (rather than delayed by 0.5 idle seconds),
it's not a good solution.
So what I offer you is to introduce a new
`font-lock-before-after-change-functions' which is just like
after-change-functions except it's run by font-lock's (or jit-lock's)
after-change-function and before it does anything else.
You can then use this hook to place a function that computes the extended
region and places a font-lock-multiline property on it.
Do we have a deal?
Stefan
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Alan Mackenzie, 2006/03/14
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Stefan Monnier, 2006/03/14
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Richard Stallman, 2006/03/15
- font-lock-extend-region (was: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]),
Stefan Monnier <=
- Re: font-lock-extend-region (was: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]), Alan Mackenzie, 2006/03/20
- Re: font-lock-extend-region, Stefan Monnier, 2006/03/20
- Re: font-lock-extend-region, Alan Mackenzie, 2006/03/27
- Re: font-lock-extend-region, Stefan Monnier, 2006/03/27
- Re: font-lock-extend-region, Alan Mackenzie, 2006/03/23
- Re: font-lock-extend-region, Stefan Monnier, 2006/03/23