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 21:12:06 +0000 Message-ID: <20150320211206.GD3493@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1426885984 7163 80.91.229.3 (20 Mar 2015 21:13:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Mar 2015 21:13:04 +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 Fri Mar 20 22:12:55 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 1YZ4Dm-0003pB-E4 for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 22:12:46 +0100 Original-Received: from localhost ([::1]:45766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ4Dl-0004wr-Fq for ged-emacs-devel@m.gmane.org; Fri, 20 Mar 2015 17:12:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ4Da-0004wX-TP for emacs-devel@gnu.org; Fri, 20 Mar 2015 17:12:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ4DS-0007m7-Oe for emacs-devel@gnu.org; Fri, 20 Mar 2015 17:12:34 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:61360 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ4DS-0007lk-Ey for emacs-devel@gnu.org; Fri, 20 Mar 2015 17:12:26 -0400 Original-Received: (qmail 32853 invoked by uid 3782); 20 Mar 2015 21:12:25 -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 22:12:24 +0100 Original-Received: (qmail 5703 invoked by uid 1000); 20 Mar 2015 21:12:06 -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:184057 Archived-At: Hello, Stefan. On Fri, Mar 20, 2015 at 02:05:48PM -0400, Stefan Monnier wrote: > >> 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. > You yourself told me that the region had to start after the brace. In certain circumstances, this is necessary. When CC Mode sets a position using font-lock-extend-after-change-region-function, then it is necessary to start font-locking from that position. For example, if a line in a C file looks like: FOO, and you type an "L" before the comma, CC Mode, whilst font-locking, needs to know whether this identifier is (i) an element of an enum brace list; (ii) the name of a variable being declared (when the type will have been on a previous line); (iii) a parameter in a function call; or (iv) (maybe one or two other things). It does this by instructing Font Lock to start its processes from a specific earlier point in the file. In the case of FOO being inside a brace, without there being any semicolon before FOO, that position is the beginning of the first identifier after the brace. Starting from that position, c-font-lock-enum-tail will trigger, font-locking FOOL as font-lock-variable-name-face. Starting from outside the brace, c-font-lock-enum-tail will not trigger, leaving FOOL unfontified. When you, as a user, put point at BOL2 and type M-o M-o, then this will work too. Typing in L4, L5, .... triggering after-change fontification is an example of the first circumstance, where CC Mode sets BO font-lock region to just after the brace on L2. > > 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. > I'm confused: "somewhere else" is typically BOL2. Yes. It is in a syntactically different context. > Here you say this fouls up font-locking, but above you said CC-Mode is > quite capable of handling a font-lock region starting at BOL2. See above. If necessary for its analysis (I'm not sure if it is), CC Mode would extend the region as required if asked to start fl'ing at BOL2. > > One place which is causing me puzzlement is in jit-lock-fontify-now. > > It's this bit: > As you know, jit-lock is irrelevant to those kinds of font-lock problems > (in the sense that it's always possible to trigger the same problems > without the use of jit-lock, tho it may require some time to figure > out a triggering sequence). No, it isn't. Jit lock is used, and has its imperfections, one of which I recently reported as a bug and fixed, another of which is causing me pain and I've asked you for help on. These problems don't exist in plain Font Lock mode (with f-l-support-mode nil). > > The only way `start' can be before `orig-start' is on the first line of > > the fl region, and start is moved to BOL. Why is it necessary to go to > > all the expense of using `run-with-timer' rather than just fixing things > > inside `jit-lock-fontify-now'? What is the use case? > It's explained in the comment. OK. I think I've got it now. jit-lock-fontify-now is expanding backwards into a region which is already fontified, but for which it doesn't "have permission", then reapplying face properties which are already there, then (just in case a face property might have changed) triggering a whole new expensive redisplay. To minimise this expense, a questionable short cut is applied in another function (font-lock-extend-jit-lock-region-after-change). It is this short cut which is causing me the pain. There's got to be a better way of doing things than this. The abstract cause of all these difficulties seems to be Font Lock's not distinguishing between a beginning of region to be used for analysis, and the beginning of region to which face properties will be applied. > Which part of the comment don't you understand? I'm not sure. I get it now, but it was extremely difficult arriving at this understanding. Perhaps if "any part of the buffer prior to that" had been "the initial part of the first line before `orig-start'", I would have got it sooner. > By the time jit-lock is called the redisplay up to orig-start has > already been done (you can assume it's already drawn on the screen). > Stefan -- Alan Mackenzie (Nuremberg, Germany).