Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Alan Mackenzie]

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.