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

[Alan Mackenzie <acm@muc.de>]

Hi, Martin!

On Wed, 15 Feb 2006, martin rudalics wrote:

> > That's how I understand it.  The region to be fontified will get
> > extended backwards to the starting tag regardless of this point being
> > visible in the window or not.  If it will be fontified right away or
> > marked to be fontified by jit-lock depends upon either
> > `jit-lock-after-change' or `font-lock-after-change-function' being
> > present in `after-change-functions'.

>Presumably the "region to be fontified gets extended" by resetting its
>fontified text-property to nil.  `jit-lock-after-change' should be able
>to do this if you provide the correct start and end values.  But keep in
>mind that with jit-lock redisplay immediately triggers refontification
>of displayed text whose fontified text-property has been reset to nil.
>This refontification won't recognize any "starting tag" preceding
>window-start unless you explicitly tell it to go there, for example, by
>using a multiline property.  If you decide on the `font-lock-multiline'
>property, every time you insert or delete a character nearby, redisplay
>has to refontify the entire contiguous area covered by the property.

There's a fundamental mismatch between Font Lock's implementation and
reality: Font Lock assumes that, with the exception of comments and
strings, the fontification of a region is dependent only on text near the
region.  This works pretty well for programming languages, but badly for
mark-up languages.

Conceptually, Emacs partitions the problem into a low-intensity global
task (locating comments and strings), for which it has the fast syntax
routines, and a high-intensity local task (hairy syntax analysis near
point.)  It is worth noting that the syntax routines support 2-character
delimiters (like "/*"), if only by kludge.

I am convinced that, in the long term, we need an analogous, fast, global
mechanism for for locating and characterizing regions bounded by
arbitrary delimiters - in this case "<<" and ">>", but could just as well
be Texinfo's "{" and "}" or Lex's and Yacc's "%{", "%}" and "%%" or
"literate programing"'s boundaries between narrative text and executable
code, or "here documents" within a shell script.

Until we have this, I think we'll be entangling ourselves in an ever
stickier web of ad-hoc workarounds.

-- 
Alan.




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642