[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: C++-mode: Syntax highlighting: wrong color for funct
From: |
Ralf Angeli |
Subject: |
Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows] |
Date: |
Tue, 14 Feb 2006 09:49:46 +0100 |
* Stefan Monnier (2006-02-13) writes:
>> Currently a function is used as matcher in `font-lock-keywords' for
>> this functionality. It basically operates like this:
>
>> (catch 'match
>> (while (re-search-forward "<<" limit t)
>> (let ((beg (match-beginning 0)))
>> (search-forward ">>" limit 'move)
>> (store-match-data (list beg (point)))
>> (throw 'match t))))
Ouch. Pasting the code into a wterm messed up indentation pretty
badly. )c:
> I.e. equivalent to "<<\\(.\\|\n\\)*?\\(>>\\)?".
The function actually used in AUCTeX does a bit more. For example it
checks if a face for verbatim content is present and does not set a
match in such a case.
>> With the matcher function above text in quotation marks won't be
>> fontified when I start typing stuff like "<<foo" as long as there is
>> no closing quotation mark. Now if the closing quotation mark is
>> entered a few lines below the line containing the opening quotation
>> mark, font locking won't see the opening quotation mark and the
>> multiline quotation won't be fontified.
>
> Indeed. You can use contextual refontification, tho:
>
> (if jit-lock-context-unfontify-pos
> (setq jit-lock-context-unfontify-pos
> (min jit-lock-context-unfontify-pos
> (re-search-backward "<<" limit t))))
>
> it's specific to jit-lock, tho.
Hm, I would not like leaving people who disabled jit-lock out in the
cold. So the hook is probably a better alternative. But thanks for
that hint anyway.
> Also it will not refontify immediately but only after jit-lock-contex-time.
> I'd consider it a feature, but others may disagree.
I am tempted to disagree but maybe this is a case of getting used to it.
> I like the idea behind your before-font-lock-after-change-function, except
Uh, Alan Mackenzie is the originator of this proposal, not me. (c:
> that I'd want it to be in font-lock-default-fontify-region. I.e. it should
> then be possible to remove mention of font-lock-multiline from
> font-lock-default-fontify-region by moving it to this new hook (which we
> could call font-lock-fontify-extend-region-functions).
Hm, how would it be possible to detect closing tags in this case?
Maybe with an initial search for these tags across the region to be
fontified. Or on a case by case basis for every closing tag which is
encountered during fontication of the region? This would be rather
inefficient compared to using a hook to be called before
`font-lock-after-change-function'. But maybe you are thinking about
something completely different.
--
Ralf
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], (continued)
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], martin rudalics, 2006/02/16
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Vivek Dasmohapatra, 2006/02/16
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Alan Mackenzie, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Stefan Monnier, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Alan Mackenzie, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], martin rudalics, 2006/02/16
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Alan Mackenzie, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], martin rudalics, 2006/02/16
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows],
Ralf Angeli <=
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Stefan Monnier, 2006/02/14
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Ralf Angeli, 2006/02/14
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Stefan Monnier, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Ralf Angeli, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Ralf Angeli, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Werner LEMBERG, 2006/02/14
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Alan Mackenzie, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Stefan Monnier, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Alan Mackenzie, 2006/02/15
- Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows], Kim F. Storm, 2006/02/16