[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing font
From: |
Alan Mackenzie |
Subject: |
Re: [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669. |
Date: |
Mon, 2 Feb 2015 21:39:57 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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).