emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: C++-mode: Syntax highlighting: wrong color for funct


From: Stefan Monnier
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Mon, 13 Feb 2006 17:10:36 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

I.e. equivalent to "<<\\(.\\|\n\\)*?\\(>>\\)?".

> That means, search for an opening tag and if you find one search for
> the closing tag till `limit'.  If an opening tag was found, set the
> match to the region from the opening tag to the closing tag, or
> `limit' if none was found.

> What I'd like to use instead is this:

>   (catch 'match
>     (while (re-search-forward "<<" limit t)
>       (let* ((beg (match-beginning 0))
>            (after-beg (match-end 0))
>                 (point-of-surrender (+ beg 1000)))
>                 (search-forward ">>" point-of-surrender 'move)
>                 (if (= (point) point-of-surrender)
>                     (progn
>                           (goto-char after-beg)
>                                 (store-match-data (list after-beg after-beg)))
>                                   (store-match-data (list beg (point))))
>                                   (throw 'match t))))))

> That means, search for an opening tag and if one is found search for
> the closing tag till an arbitrarily large region after the opening tag
> (1000 characters large in the code above).  If no closing tag is
> found, set an empty match; if one is found, set the match from the
> opening to the closing tag.

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

Also it will not refontify immediately but only after jit-lock-contex-time.
I'd consider it a feature, but others may disagree.

Finally, the above code is naive: you'd have to make sure it's only used
when refontification will indeed make a difference, otherwise the code could
be triggered again and the context refontification could repeat over and over
again.

I like the idea behind your before-font-lock-after-change-function, except
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).


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]