Re: font-lock-multiline for cc-awk.

[Stefan Monnier]

>> AFAICT the patch below converts cc-awk to use font-lock-multiline
>> instead of an after-change-function.

> You've rubbed out my after-change function!  Heeeellllllllllpppppppp!!

Well, it was just a sample patch.

> In fact, it's a massive pain in the posterior that font lock erases these
> text properties without getting permission from the major mode.

Huh?  font-lock only clears the syntax-table properties if you specifically
ask it to manage that property (by setting font-lock-syntactic-keywords).

> I don't want to mix up the syntax-table and f-l-multiline properties,
> because they're very different things.

On the contrary, they belong together: the font-lock-multiline accompagnies
the syntax-table property to say "this syntax-table property depends on this
chunk of text", so that if a part of this chunk of text is changed, the
syntax-table property can be recomputed.

> Doing so would weaken the
> existing functions, which are strong single-purpose functions.  To do
> things this sort of way, I'd put in a new function
> c-awk-set-fl-multiline-properties (a sister function to
> c-awk-set-syntax-table-properties, with the same calling conventions).
> The existing function loops round string/regexp/division sign constructs,
> whereas the new one would be looping round lines.

A multiline-line without strings or regexps doesn't need to be refontified
atomically because none of the other patterns you use can span or depend on
multiple lines of text.

> They don't mix very happily.

On the contrary: they belong together.

> But mainly, I don't want to be applying f-l-m properties throughout the
> region[*].  They should be applied only at the region boundaries when
> these need extending, and only when font lock is enabled, since they serve
> no purpose otherwise.

> [*] As you're aware, I don't want to use f-l-m properties at all.  But if
> I must use them, I only want them where absolutely needed.

Look, I'm just showing this code to try and get you to understand how
font-lock-multiline properties work.  It seems like you've been thinking
much too hard about your a-c-f code and can't think outside of
that setting.

[ Reminds me of "a calculus of capabilities" and "alias types": they present
  a new way to guarantee the safety of "manual" memory
  management primitives.  Contrary to previous appoaches (which tended to be
  very complex and incomplete or much too restrictive), they allow
  dangling pointers.  Many people found it terribly difficult to believe to
  understand that a system that allows dangling pointers can be safe w.r.t
  manual memory management: all previous approaches cared about checking
  that "free" is safe, whereas those new approaches only care about checking
  that the memory access is safe: i.e. they simply disallow access after
  a "free" rather than disallow "free" if the object is still "live" (which
  they typically define as "reachable"). ]

> Why not leave things alone until Richard has settled the whole matter?

Of course, I didn't intend to apply the patch.


        Stefan