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: Fri, 20 Mar 2015 17:29:18 +0000 Message-ID: <20150320172918.GC3493@acm.fritz.box> References: <55076CF8.60309@dancol.org> <20150318120806.GA4160@acm.fritz.box> <550A43BB.3070904@dancol.org> <20150319093110.GA2753@acm.fritz.box> <20150319203724.GB2753@acm.fritz.box> <20150320163027.GB3493@acm.fritz.box> <550C4C2C.9060807@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426872603 7107 80.91.229.3 (20 Mar 2015 17:30:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Mar 2015 17:30:03 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 20 18:29:54 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 1YZ0k4-0003ko-Ve for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 18:29:53 +0100 Original-Received: from localhost ([::1]:44930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ0jz-0002Bp-8W for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 13:29:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ0jw-0002BY-Ao for emacs-devel@gnu.org; Fri, 20 Mar 2015 13:29:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ0js-0007ck-6C for emacs-devel@gnu.org; Fri, 20 Mar 2015 13:29:44 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:24602 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ0jr-0007cd-Sq for emacs-devel@gnu.org; Fri, 20 Mar 2015 13:29:40 -0400 Original-Received: (qmail 65643 invoked by uid 3782); 20 Mar 2015 17:29:38 -0000 Original-Received: from acm.muc.de (pD951ACB9.dip0.t-ipconnect.de [217.81.172.185]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 20 Mar 2015 18:29:36 +0100 Original-Received: (qmail 4601 invoked by uid 1000); 20 Mar 2015 17:29:18 -0000 Content-Disposition: inline In-Reply-To: <550C4C2C.9060807@dancol.org> 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:184046 Archived-At: Hello, Daniel. On Fri, Mar 20, 2015 at 09:34:52AM -0700, Daniel Colascione wrote: > On 03/20/2015 09:30 AM, Alan Mackenzie wrote: > > On Thu, Mar 19, 2015 at 04:56:16PM -0400, Stefan Monnier wrote: > >>>> 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. > >> There's your problem: your current setup needs the starting point to be > >> either before "union" or after the first open brace. > >> It breaks down if it's between the two. That's the problem you need to fix. > > Not really. CC Mode is quite capable of handling the Font Lock region > > starting at BOL2. The problem is, when that starting point needs to be > > after the brace on L2, Font Lock moves the starting point somewhere > > else, fouling up the font locking. This is proving surprisingly tough > > to fix. > I don't understand. Why shouldn't I be able to tell cc-mode to fontify > *arbitrary* regions and expect it to correctly apply highlighting to > these regions? You can, as a CC Mode user. In its turn CC Mode needs to be able to select the region in which it does its analysis, so that that analysis starts at a neutral syntactic position. > It's the idea that the region "needs to be after brace" that I find > confusing. Shouldn't jit-lock have the right to expand the region > arbitrarily? Absolutely not. CC Mode needs to do syntactic analysis inside this region, so the region needs to start at the (syntactically) right place. To do this analysis CC Mode must first find the beginning of any definition the current position is in, otherwise context fontification can go wrong. An example of this going wrong is in this snippet: 1. template 2. 3. 4. void myfunc(T* p) {} If a space is inserted on L3, this will trigger context fontification of L4. L4 is fontified differently in the presence of the template declaration (for reasons you, a C++ hacker, probably understand better than me). What the bug reporter saw was L4's fontification going wrong a half second after typing the space, something as irritating as what is happening to your "for". The solution I implemented for the problem was to extend the font lock region to include L1. That same region extension which includes that template line, in the enum example goes back to after the "{" on L2. Bug #19669 went wrong in c-font-lock-enum-tail, the function which handles a the start of a fontification region being within an enum brace block. c-font-lock-enum-tail will only trigger when the starting point is within that brace block. When Font Lock moves the starting point somewhere else (in particular, BOL), that condition no longer holds, and the font locking fails. -- Alan Mackenzie (Nuremberg, Germany).