Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Ralf Angeli <angeli@iwi.uni-sb.de>]

* Stefan Monnier (2006-02-12) writes:

>>> This patch to font-lock is exactly the sort of change I was thinking of.
>>> Could someone please install it, then rename
>>> before-font-lock-after-change-function to
>>> font-lock-extend-region-function, and rename
>>> font-lock-run-before-after-change-hook to font-lock-extend-region?
>
> I can't find this patch any more.  Based on the name, I suppose it's some
> kind of hook in font-lock-after-change-function, in which case I'd be
> tempted to suggest to move it to font-lock-fontify-region instead, to reduce
> the performance impact and make it easier to deal with lazy-lock&jit-lock
> since these tend to use their own after-change-function.

You can find the patch at
<URL:http://mid.gmane.org/Pine.LNX.3.96.1050309193630.414A-100000@acm.acm>.

>> An idea for making font locking more robust in this respect might be
>> to desist from coloring the rest of the buffer in case of an unmatched
>> opening tag, i.e. to leave it alone if a matching closing tag cannot
>> be found in an arbitrarily large region after the opening tag.  That
>> would mean fontification will only be applied as soon as the closing
>> tag is typed.  For that to work, however, I'd have to look backwards
>> for an opening tag which could be done with a hook like the one
>> proposed above.
>
> I'm not sure how that relates to before-font-lock-after-change-function.
> Could you describe how you currently font-lock those <<...>> multiline
> elements and how you'd use before-font-lock-after-change-function to solve
> the problem?

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

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.

I'd use something like `before-font-lock-after-change-function' to
look backwards a few characters from the point where text was entered
and detect closing tags.  For example if ">>" was detected after
typing it, I'd search backwards in an arbitrarily large region for a
starting "<<" quotation mark and extend the region to be fontified
backwards till that point.  Now font-lock will find both the opening
and closing quotation marks and fontify the enclosed text.

-- 
Ralf