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

[Alan Mackenzie]

Hello, Stefan.

On Mon, Feb 02, 2015 at 01:54:20PM -0500, Stefan Monnier wrote:
> > +  ;; Prevent `font-lock-default-fontify-region' extending the region it 
> > will
> > +  ;; fontify to whole lines by removing 
> > `font-lock-extend-region-whole-lines'
> > +  ;; (and, coincidentally, `font-lock-extend-region-multiline' (which we do
> > +  ;; not need)) from `font-lock-extend-region-functions'.  (Emacs only).  
> > This
> > +  ;; fixes Emacs bug #19669.

> My general understanding of font-lock's highlighting is that using
> a smaller region is only ever useful for performance reason, rather than
> for correctness (and this line of thinking influences the design of the
> code).  So I'm really curious to understand how this counter-example
> works, since it might hint at further (latent) bugs elsewhere.

> Can you walk me through what happens in the scenario of bug#19669?

Certainly!

The pertinent file.h looks like this:
#########################################################################
enum xxx_xxxxxxxxxx_x
    {XXX_XXXX_XXXX_XXXXX_XXXXX,
     XXX_XXXX_XXXX_XXXXX_XXXXX,
     XXX_XXXX_XXXXXX_XXXXXXXX_XXXXXXX,
     XXX_XXXX_XXXXXX_XXXXXXXX_XXXXXXX,
     XXX_XXXX_XXXX_XXXXXXXX,
     XXXXXX_XXXXXXX_XXXX_XXXXXXXX,
     XXXXX_XXXXXX_XXXX_XXXXXXXX,
     XXX_XXXXXXX,
     XXX_XXX_XXXXXXXX,
     XXX_XXX_XXX_XXXXXXXXX,
     XXXXXX_XXX_XXXXXXX,
     X_XXXXXXXXXX};

enum xxx_xxxx_xxxxxxxxxx_x
    {XXX_XXXXXX_XXXX_XXX,
     XXX_XXXXXX_XXXX_XX,
     XXX_XXXXXXXX_XXXX_XXX,
     XXX_XXXX_XXXXXXX,
     XXX_XX_XXXXX_XXXX_XXXXXXX,       <==================================
     XXXXXX_XXXXXX_XXXX_XXXXXXXX,
     XXX_XXXX_XXXXXXX,

     // xxx
     XXXXXX_XXXXXXXX};
#########################################################################

1. Visit the file.
2. Note that in the second enum, only the first 4 identifiers are fontified.
3. This is because only the first jit-lock-chunk-size bytes (rounded up
to EOL) are fontified.
4. The second jit-lock-chunk begins inside enum braces.

5. Redisplay attempts to fontify the buffer by calling jit-lock-function
for two chunks.  The first chunk is fine.
6. jit-lock calls the value of font-lock-fontify-region-function, which
is..
7. ..c-font-lock-fontify-region function, with parameters 506, 631.
(Here 506 is BOL marked, 631 is EOB).
8. Here, `new_beg' and `new_end' are initialised to 506, 631, then
modified by calling the functions in
c-before-context-fontification-functions.  This contains just one
function, c-context-set-fl-decl-start.
9. c-context-set-fl-decl-start just calls c-set-fl-decl-start..
10. ..which ensures 506 is not in the middle of a declaration.  In doing
so, it returns 409, the new "safe" position.  This is the position just
after the "{".

11. (409 . 631) gets returned to c-font-lock-fontify-region, which calls
(font-lock-default-fontify-region 409 631).
12. font-lock-default-fontify-region adjusts 409 to 404, since 409 is
not at BOL.  404 is no longer a "syntactically safe" position wrt the
original 506.
13. font-lock-default-fontify-region calls
(font-lock-fontify-keywords-region 404 631)...

14. ...which eventually calls c-font-lock-enum-tail.  This function was
the solution to the problem of a jit-lock chunk starting in the middle
of a long enum declaration.  It fontifies the rest of the enum's
identifiers (actually, if fontifies them all, up to limit; optimisation
is called for, here).  However...
15. .... point is no longer inside the enum's brace block, having been
moved from 409 to 404 by font-lock-extend-region-whole-lines.  So the
condition for c-font-lock-enum-tail isn't met, and the fontification
doesn't get triggered.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).