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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Thu, Mar 19, 2015 at 04:56:16PM -0400, Stefan Monnier wrote:
> >> 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.

> There's your problem: your current setup needs the starting point to be
> either before "union" or after the first open brace.
> It breaks down if it's between the two.  That's the problem you need to fix.

Not really.  CC Mode is quite capable of handling the Font Lock region
starting at BOL2.  The problem is, when that starting point needs to be
after the brace on L2, Font Lock moves the starting point somewhere
else, fouling up the font locking.  This is proving surprisingly tough
to fix.

One place which is causing me puzzlement is in jit-lock-fontify-now.
It's this bit:

           ;; The redisplay engine has already rendered the buffer up-to
           ;; `orig-start' and won't notice if the above jit-lock-functions
           ;; changed the appearance of any part of the buffer prior
           ;; to that.  So if `start' is before `orig-start', we need to
           ;; cause a new redisplay cycle after this one so that any changes
           ;; are properly reflected on screen.
           ;; To make such repeated redisplay happen less often, we can
           ;; eagerly extend the refontified region with
           ;; jit-lock-after-change-extend-region-functions.
           (when (< start orig-start)
             (run-with-timer 0 nil #'jit-lock-force-redisplay
                             (copy-marker start) (copy-marker orig-start)))

The only way `start' can be before `orig-start' is on the first line of
the fl region, and start is moved to BOL.  Why is it necessary to go to
all the expense of using `run-with-timer' rather than just fixing things
inside `jit-lock-fontify-now'?  What is the use case?  The mechanism
here, in particular the bit the attempts to avoid using this
`run-with-timer' too often, is causing me pain.  Could we not resolve
the problem, whatever it is, by a less convoluted means?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).