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: Thu, 19 Mar 2015 20:37:25 +0000 Message-ID: <20150319203724.GB2753@acm.fritz.box> References: <20150201212213.17840.3710@vcs.savannah.gnu.org> <55076CF8.60309@dancol.org> <20150318120806.GA4160@acm.fritz.box> <550A43BB.3070904@dancol.org> <20150319093110.GA2753@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426797496 2038 80.91.229.3 (19 Mar 2015 20:38:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Mar 2015 20:38:16 +0000 (UTC) Cc: Daniel Colascione , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 19 21:38:03 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 1YYhCY-0006tv-TY for ged-emacs-devel@m.gmane.org; Thu, 19 Mar 2015 21:37:59 +0100 Original-Received: from localhost ([::1]:41205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYhCS-00023R-Ul for ged-emacs-devel@m.gmane.org; Thu, 19 Mar 2015 16:37:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYhCP-00023G-OA for emacs-devel@gnu.org; Thu, 19 Mar 2015 16:37:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYhCM-0001ia-Ix for emacs-devel@gnu.org; Thu, 19 Mar 2015 16:37:49 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:20420 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYhCM-0001iS-8q for emacs-devel@gnu.org; Thu, 19 Mar 2015 16:37:46 -0400 Original-Received: (qmail 89580 invoked by uid 3782); 19 Mar 2015 20:37:44 -0000 Original-Received: from acm.muc.de (pD951A075.dip0.t-ipconnect.de [217.81.160.117]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 19 Mar 2015 21:37:43 +0100 Original-Received: (qmail 5697 invoked by uid 1000); 19 Mar 2015 20:37:25 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.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:184028 Archived-At: Hello, Stefan. On Thu, Mar 19, 2015 at 09:49:13AM -0400, Stefan Monnier wrote: > > The problem in #19669 was that Font Lock's extension of the region to be > > font locked to the beginning of the line was changing the syntactic > > context, hence CC Mode's font locking didn't work in that case. The > > solution was to prevent that extension in the pertinent case. However, I > > got it wrong. > The way I see it, the core of the problem is that the way you handle > partial re-fontification of a multi-line `union' construct has > a dead spot. > More specifically, if you have code like > 1 union > 2 { > 3 foo, > 4 bar > 5 } > 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. When Daniel types the "r" of his "for", it is equally essential that Font Lock (or something) does adjust the fontification region start to BOL. This is the more normal case. How do we reconcile these? The pertinent adjustment is done by having, or not having, `font-lock-extend-region-wholelines' on `font-lock-extend-region-functions'. So, I have a solution which, in the "enum case" sets a flag which instructs c-font-lock-fontify-region later to bind `f-l-extend-r-f' to nil. Should work. Unfortunately, there is a dirty hack in `font-lock-extend-jit-lock-region-after-change' which illegitimately (i.e. at a time when it is forbidden, according to the contract on the variable) tests `font-lock-extend-region-functions' for 'f-l-extend-region-wholelines' and then fouls up the beginning of the "enum region" to BOL 2 before CC Mode's code has had a chance to bind `f-l-extend-region-functions' to nil. The purpose of this hack, made in 2006, is to prevent double redisplay, according to the comments in font-lock.el. I can't see how it works, right at the moment, but couldn't we somehow remove this dirty hack? > Stefan -- Alan Mackenzie (Nuremberg, Germany).