unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <20150202213957.GF3673@acm.acm> (raw)
In-Reply-To: <jwv1tm8f8p1.fsf-monnier+emacsdiffs@gnu.org>

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).



  reply	other threads:[~2015-02-02 21:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20150201212213.17840.3710@vcs.savannah.gnu.org>
     [not found] ` <E1YI1y9-0004eO-Re@vcs.savannah.gnu.org>
2015-02-02 18:50   ` [Emacs-diffs] emacs-24 d69e9f1: CC Mode: Stop Font Lock forcing fontification from BOL. Fixes debbugs#19669 Stefan Monnier
2015-02-02 19:27     ` Alan Mackenzie
2015-02-03  2:12       ` Stefan Monnier
2015-02-02 18:54   ` Stefan Monnier
2015-02-02 21:39     ` Alan Mackenzie [this message]
2015-02-03  2:26       ` Stefan Monnier
2015-02-07 12:27         ` Alan Mackenzie
2015-02-07 15:29           ` Stefan Monnier
2015-02-07 15:40             ` Alan Mackenzie
2015-03-16 23:53   ` Daniel Colascione
2015-03-18 12:08     ` Alan Mackenzie
2015-03-19  3:34       ` Daniel Colascione
2015-03-19  9:31         ` Alan Mackenzie
2015-03-19 13:49           ` Stefan Monnier
2015-03-19 20:37             ` Alan Mackenzie
2015-03-19 20:56               ` Stefan Monnier
2015-03-20 16:30                 ` Alan Mackenzie
2015-03-20 16:34                   ` Daniel Colascione
2015-03-20 17:29                     ` Alan Mackenzie
2015-03-20 21:25                       ` Daniel Colascione
2015-03-20 22:30                         ` Alan Mackenzie
2015-03-20 18:05                   ` Stefan Monnier
2015-03-20 21:12                     ` Alan Mackenzie
2015-03-20 22:01                       ` Stefan Monnier
2015-03-30 16:44     ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150202213957.GF3673@acm.acm \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).