[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: Font Lock on-the-fly misfontification in C++]

From: Alan Mackenzie
Subject: Re: address@hidden: Font Lock on-the-fly misfontification in C++]
Date: Mon, 24 Jul 2006 14:33:43 +0100
User-agent: Mutt/1.5.9i

Afternoon, Stefan!

On Sun, Jul 23, 2006 at 11:11:45PM -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).

> > solution is to determine the bounds of the region to fontify by
> > analysing the surrounding text syntactically.

> Presumably, at the moment when Emacs fontified it correctly, it knew
> the corresponding bounds, so it could have added the
> font-lock-multiline property at that time, thus avoiding the need to
> re-determine those bounds later when refontifying.

The buffer was originally fontified as a whole, thus the corresponding
bounds were BOB and EOB.

When the buffer is changed, in the most general case, the bounds of the
region to be refontified are going to have to be recalculated before

As you are aware, I intensely dislike the notion that an entire buffer
should have to be left constantly marked with all places where it
fontification might have to straddle line boundaries, rather than
determining these things as they are needed.  I also dislike being
unable to specify an exact fontification region to Font Lock (such as
the bounds of one of Simon's comments).

>         Stefan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]