[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tue, 21 Mar 2006 16:32:10 -0500
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
>> The region is not automatically marked with font-lock-multiline, so you
>> can't really fault font-lock-multiline for it: it's your code that marks it
>> that is at fault.
>> [ Now don't get me wrong: the font-lock-multiline property is not perfect. ]
> Hang on a moment! The CC Mode code _doesn't_ currently mark text with
> font-lock-multiline. I understood your suggestion was that it should do
My response was to your complaint about font-lock-multiline because of what
would happen if the C mode placed a font-lock-multiline on the whole 20K of
yanked text. I understand that C mode doesn't do that right now.
>>> What I think we need is a function called from f-l-default-f-region which
>>> will get a safe starting position at or before L1034.
>> Agreed. And I suggested we name it font-lock-extend-region-function.
> font-lock-extend-region-function is already in use for purpose (i),
> determining the region to be fontified.
Yes, I understand that, but I'm trying to understand why you need it and
whether font-lock-extend-region-function is then the right answer.
> I'm saying we also need a distinct function for purpose (ii), determining
> a safe place to start fontifying a chunk which could easily be in the
> middle of the region returned by (i).
I think I need to start over. IIUC you're trying to handle the "\\\n"
line-continuation feature, right?
For that, you need to always font-lock the whole multiline-line at
a time, right? So my natural answer (given the hammer I have in my hand) is
to tell you to put a font-lock-multiline property on the whole
multiline-line. My naive understanding says that it should be sufficient:
no need for font-lock-extend-region anywhere.
>> Or is there some other reason to extend the region from
>> after-change-functions, other than atomic elements at the boundaries?
> The region sometimes has to be extended to the end of what was an atomic
> element before the change, but is no longer so.
If this previously-atomic element had a font-lock-multiline property, then
it will be refontified atomically (at which point it will be discovered
that it's not atomic anymore so the font-lock-multiline property won't be
>> I believe the one in jit-lock-fontify-now could be removed (but this
>> function is also sadly called from external packages, so there may be some
>> minor compatibility issues).
> I think any text region handled by jit-l-f-now cannot avoid being
> processed by f-l-fontify-region.
Indeed, as I said, I think it can be removed, although of course we'll then
have to update glasses-mode first (which registers itself with jit-lock).
I think glasses-mode and font-lock-mode are the only two to use jit-lock.
> I don't see this, yet. If 'fontified is cleared only on the new open
> paren at position 1055, the display engine calls successively
> (jit-lock-function 1055),
> (jit-lock-fontify-now 1055 1555),
> and (assuming j-l-f-now DOESN'T extend to whole lines)
> (run-hook jit-lock-functions 1055 1555),
> (font-lock-fontify-region 1055 1555),
> (funcall font-lock-fontify-region-function 1055 1555),
> (font-lock-default-fontify-region 1055 1555).
> Here, in f-l-default-f-r, 1055 is set back to 1044 (BOL), and this whole
> line, 1044 - 1056, gets its face properties rearranged.
You're right until here.
> These then get redisplayed.
But this is what doesn't happen.
> What am I missing here?
When the redisplay engine calls jit-lock-function with arg 1055, it has
already redisplayed all the text until 1054 and changes in the buffer that
affect text before 1055 will not cause redisplay to restart when
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], (continued)