Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie <acm@muc.de>]

Evening, Stefan!

On Mon, Jul 24, 2006 at 10:36:08AM -0400, Stefan Monnier wrote:
> >> >> 3.  Append a space to the fourth commented line.  Bug:
> >> >> fontification of Foo, bar, Snafu and snafu is removed from that
> >> >> line.

> >> > The problem is that after a textual change, the changed line gets
> >> > fontified as an atomic entity, i.e. yanked out of its context.  The

> >> If you placed a font-lock-multiline property on the whole thing,
> >> font-lock would know not to yank that one line out of its context.

> > We've already been through this at some length.

> > I think we're agreed that it's not possible to put this property exactly
> > where it's needed (at the boundaries of the region to fontify, and
> > nowhere else) when it's needed (at the time of the change, before Font
> > Lock starts fontifying).

> I'm talking about this specific example, which is about
> refontification, not about the original fontification.  As you know,
> the two problems are closely related yet separate.

I don't see the differences, except at a fine level of detail.  Either
operation has to go through the font-lock-keyword stuff, etc.

[ .... ]

> Come on, be more constructive, please.

I was being constructive when I submitted this patch:

    Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT)
    From: Alan Mackenzie <acm@muc.de>
    Reply-To: Alan Mackenzie <acm@muc.de>
    To: emacs-devel@gnu.org
    Subject: font-lock-extend-region-function: Final refinements.

It hasn't as yet been installed, although it would establish the
infrastructure with which the problems being discussed here could be
wholly and efficiently erradicated, without resort to obscure coding.

[ .... ]

> Have you taken the time to look at my cc-awk.el patch example (I mean,
> other than to try and find some superficial flaw in it).  It should
> give you a pretty good idea of what the above paragraph refers to.

I know what your paragraph refers to.  We've discussed it at great
length already, and I think I understood it at the time you posted it.
That approach is more obscure and more inefficient (in terms of
processor cycles) than anything I want to put into CC Mode.

Is there any chance of you adapting the font-lock-multiline mechanism so
that the properties can be applied _before_ fontification, exactly where
they are needed, rather than _after_ fontification throughout the entire
change region?

[ .... ]

> > I also dislike being unable to specify an exact fontification region
> > to Font Lock (such as the bounds of one of Simon's comments).

> I don't understand what you're referring to.

>From Simon's example:

    public Bar    // Bar fontified as a type, at first

type a space after "first".  The region I want to specify to Font Lock
is exactly this:

    public Bar    // Bar fontified as a type, at first 
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't think the font-lock-multiline mechanism is capable of doing
this.  The `font-lock-extend-region-function' mechanism definitely is.

Most of CC Mode's languages are not line-based.  I think it's unhelpful
to construe it's font-locking stuff in terms of buffer lines.  This is
what has led to many complaints about font locking in CC Mode (many of
which have appeared directly in bug-cc-mode).  If CC Mode can specify a
font-locking region based on language constructs (e.g. a whole
statement, a comment, a string, a declaration), these problems will
go away.  Even entries to the obfuscated C competition would get
correctly and efficiently fontified.

>         Stefan

-- 
Alan.