From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned. Date: Sat, 21 Mar 2015 00:00:03 +0000 Message-ID: <20150321000003.GF3493@acm.fritz.box> References: <20150319230136.GC2753@acm.fritz.box> <20150320160744.GA3493@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 1426896089 30990 80.91.229.3 (21 Mar 2015 00:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 00:01:29 +0000 (UTC) Cc: 20146@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 21 01:01:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1YZ6qk-0001Jc-Ua for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 01:01:11 +0100 Original-Received: from localhost ([::1]:46132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ6qk-0000Up-AP for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Mar 2015 20:01:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ6qg-0000Ta-KM for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 20:01:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ6qc-0001pT-Kc for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 20:01:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ6qc-0001pP-IC for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 20:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZ6qb-00013S-UB for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 20:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Mar 2015 00:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20146 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20146-submit@debbugs.gnu.org id=B20146.14268960274002 (code B ref 20146); Sat, 21 Mar 2015 00:01:01 +0000 Original-Received: (at 20146) by debbugs.gnu.org; 21 Mar 2015 00:00:27 +0000 Original-Received: from localhost ([127.0.0.1]:59431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZ6q2-00012S-E1 for submit@debbugs.gnu.org; Fri, 20 Mar 2015 20:00:27 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:28380 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZ6pz-00012J-IN for 20146@debbugs.gnu.org; Fri, 20 Mar 2015 20:00:24 -0400 Original-Received: (qmail 87980 invoked by uid 3782); 21 Mar 2015 00:00:22 -0000 Original-Received: from acm.muc.de (pD951ACB9.dip0.t-ipconnect.de [217.81.172.185]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 21 Mar 2015 01:00:21 +0100 Original-Received: (qmail 6726 invoked by uid 1000); 21 Mar 2015 00:00:03 -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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100729 Archived-At: Hello again, Stefan. On Fri, Mar 20, 2015 at 03:39:10PM -0400, Stefan Monnier wrote: > > Perhaps we could implement the convention that when a major mode has > > positively set the font-lock region's start and end points, these should > > be accepted by F/J-lock, but when not, F/J-lock should be free to alter > > them (as it typically does now). > No the core of the API is font-lock-fontify-region and it should work > with *any* bounds (i.e. if these need to be extended, it should be done > by font-lock-extend-region-function). However, when the bounds are set by the major mode, those bounds should be respected by Font Lock. As I pointed out to Daniel, the major mode is the expert in where font-locking must start whereas Font Lock itself is just an enthusiastic amateur, completely lacking the structural knowledge the major mode has of the buffer. > Jit-lock is implemented on top of that API and is hence free to use any > bounds it sees fit. But surely not to pass bounds to the major mode that the major mode must, for a second time, adjust. This is crazy. > If you rely on more specific bounds being passed to > font-lock-fontify-region, that means you have a problem on your side. There is a problem, yes, but on which side it is is a matter for discussion. CC Mode has always relied on the specific bounds that it provides. This is the whole point of the 2006 interface. You yourself pointed out that CC Mode is the sole user of the functionality for expanding FL regions. The main point of expanding these regions, from CC Mode's point of view is to instruct Font Lock where to begin, so that CC Mode's font-locking then functions correctly. If CC Mode cannot rely on Font Lock being obedient, then it must internally store the correct starting and ending points and somehow substitute these for the inaccurate ones supplied by Font Lock. > > The existence of font-lock-extend-after-change-region-function makes > > this distinction possible. > The existence of font-lock-extend-after-change-region-function is an > error on my part (More specifically the result of a weakness on my part: > when you requested this feature, I added > font-lock-extend-region-function (which was the right fix) and > reluctantly accepted to also add > font-lock-extend-after-change-region-function just out of tiredness of > arguing that it was the wrong solution). Yes, it was an exhausting discussion back in 2006. But f-l-extend-after-change-r-f works well. If you change the interface to have only font-lock-extend-region-functions, then you rule out what somebody (was it Daniel?) recently called "edge triggered" fontification, leaving only "level triggered". AWK Mode (if not others) uses edge triggered fontification: For the calculation of its FL region, it uses `beg' and `end' from before-change-functions and `beg', `end', and `old-len' from after-change-functions. If f-l-extend-after-change-r-f vanishes, some other means will have to be found to transmit this info to Font Lock - the ugly advice used by earlier Emacs versions, for example. > Stefan -- Alan Mackenzie (Nuremberg, Germany).