Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669.

[Alan Mackenzie]

Hello, Stefan.

On Thu, Mar 19, 2015 at 09:49:13AM -0400, Stefan Monnier wrote:
> > The problem in #19669 was that Font Lock's extension of the region to be
> > font locked to the beginning of the line was changing the syntactic
> > context, hence CC Mode's font locking didn't work in that case.  The
> > solution was to prevent that extension in the pertinent case.  However, I
> > got it wrong.

> The way I see it, the core of the problem is that the way you handle
> partial re-fontification of a multi-line `union' construct has
> a dead spot.

> More specifically, if you have code like

> 1    union
> 2      {
> 3        foo,
> 4        bar
> 5      }

> you can handle fontification from 1,3, or 4 but not from 2.  You need to
> refine the system you use to keep track of whether we're within
> a `union' so that it knows that position 2 is also "within a union".

Well, sort of.  The problem I'm facing is that in Dima Kogan's bug
#19669, the following construct appears:

1. enum xxx_xxxx_xxxxxxxxxx_x
2.     {XXX_XXXXXX_XXXX_XXX,
3.      XXX_XXXXXX_XXX_XXX,
4.      XXXX_XXXXX_XXXX_XXX,

Note that the brace on L2 is on the same line as the first XXX_....

When the user types on line 4, 5, ... here, CC Mode sets the
fontification region start to JUST AFTER THE { ON L2.  It is essential
that Font Lock doesn't change this.

When Daniel types the "r" of his "for", it is equally essential that
Font Lock (or something) does adjust the fontification region start to
BOL.  This is the more normal case.

How do we reconcile these?  The pertinent adjustment is done by having,
or not having, `font-lock-extend-region-wholelines' on
`font-lock-extend-region-functions'.  So, I have a solution which, in
the "enum case" sets a flag which instructs c-font-lock-fontify-region
later to bind `f-l-extend-r-f' to nil.  Should work.

Unfortunately, there is a dirty hack in
`font-lock-extend-jit-lock-region-after-change' which illegitimately
(i.e. at a time when it is forbidden, according to the contract on the
variable) tests `font-lock-extend-region-functions' for
'f-l-extend-region-wholelines' and then fouls up the beginning of the
"enum region" to BOL 2 before CC Mode's code has had a chance to bind
`f-l-extend-region-functions' to nil.

The purpose of this hack, made in 2006, is to prevent double redisplay,
according to the comments in font-lock.el.  I can't see how it works,
right at the moment, but couldn't we somehow remove this dirty hack?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).