From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel 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 Message-ID: <20150202213957.GF3673@acm.acm> References: <20150201212213.17840.3710@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1422913248 21447 80.91.229.3 (2 Feb 2015 21:40:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2015 21:40:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 02 22:40:48 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YIOjf-0001xC-IY for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 22:40:47 +0100 Original-Received: from localhost ([::1]:56834 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIOje-0001Ae-Vk for ged-emacs-devel@m.gmane.org; Mon, 02 Feb 2015 16:40:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIOjY-000196-T8 for emacs-devel@gnu.org; Mon, 02 Feb 2015 16:40:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIOjV-0003LJ-6B for emacs-devel@gnu.org; Mon, 02 Feb 2015 16:40:40 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:15595 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIOjU-0003L6-NH for emacs-devel@gnu.org; Mon, 02 Feb 2015 16:40:37 -0500 Original-Received: (qmail 13672 invoked by uid 3782); 2 Feb 2015 21:40:35 -0000 Original-Received: from acm.muc.de (pD951BC19.dip0.t-ipconnect.de [217.81.188.25]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 02 Feb 2015 22:40:34 +0100 Original-Received: (qmail 11672 invoked by uid 1000); 2 Feb 2015 21:39:57 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182296 Archived-At: 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).