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 13:19:24 +0000 Message-ID: <20150321131924.GB3001@acm.fritz.box> References: <20150319230136.GC2753@acm.fritz.box> <20150320160744.GA3493@acm.fritz.box> <20150321000003.GF3493@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 1426944027 13823 80.91.229.3 (21 Mar 2015 13:20:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 13:20:27 +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 14:20:16 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 1YZJK0-0000Ch-Ju for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 14:20:12 +0100 Original-Received: from localhost ([::1]:47804 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZJJz-0004lk-SP for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 09:20:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZJJv-0004jU-B0 for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 09:20:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZJJr-0004rB-2P for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 09:20:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41619) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZJJq-0004p4-VX for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 09:20:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZJJp-00063o-Rv for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 09:20: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 13:20: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.142694398723270 (code B ref 20146); Sat, 21 Mar 2015 13:20:01 +0000 Original-Received: (at 20146) by debbugs.gnu.org; 21 Mar 2015 13:19:47 +0000 Original-Received: from localhost ([127.0.0.1]:59628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZJJa-00063F-S0 for submit@debbugs.gnu.org; Sat, 21 Mar 2015 09:19:47 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:52778 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZJJX-000635-NR for 20146@debbugs.gnu.org; Sat, 21 Mar 2015 09:19:44 -0400 Original-Received: (qmail 46030 invoked by uid 3782); 21 Mar 2015 13:19:42 -0000 Original-Received: from acm.muc.de (pD951A26C.dip0.t-ipconnect.de [217.81.162.108]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 21 Mar 2015 14:19:41 +0100 Original-Received: (qmail 3776 invoked by uid 1000); 21 Mar 2015 13:19:24 -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:100743 Archived-At: Hello, Stefan. On Fri, Mar 20, 2015 at 10:29:16PM -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. > The major mode sets font-lock-extend-region-function and this functions' > result should be (and is) respected by the rest of font-lock. It is not. font-lock-extend-region-functions (note the "s") is plural, and all functions on it are run repeatedly until none makes a change. So when the major mode sets the region, this is instantly violated by the other functions in f-l-extend-r-f. This is what caused bug #19669, and I'm still struggling to find a way round it. The problem is the mixing up of Font Lock's internal functions with the major mode's in f-l-extend-region-functions. The major mode's function is not given the priority it should have. Is there any particular reason for the repeated running of the functions on f-l-extend-region-functions? Why are they not simply each run once? Is there any use case where it is helpful for one of these functions to make a second (or subsequent) change to the font-lock region? Why don't we change this bit to a simple `run-hook' form? > But callers of font-lock-fontify-region (such as > font-lock-after-change-function, or jit-lock) can choose *any* bounds > they feel like and font-lock-fontify-region should behave correctly. If the major mode is going to get *any* bounds rather than the ones it has already specified by its function on f-l-extend-region-functions, it will need to adjust those bounds again, to a syntactically acceptable place. This can't be the Right Thing. > >> 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. > No, it is just good design to keep complexity under check. ??? > >> 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. > AFAIK CC-mode does not provide any bounds. Instead it uses > font-lock-extend-after-change-region-function which changes the part of > the buffer that is invalidated, which is something different. No it's not different. The bounds CC Mode provides are those around the region which is to be invalidated, and later refontified. I think you're picking nits here. > The relationship between the two is brittle and subtle, so relying on it > is crazy and a good way to get impenetrable code with special cases > tacked on top of special cases with lots of unspecified assumptions that > only hold in common cases. What is the alternative? CC Mode knows exactly what portion of the buffer needs refontifying, Font Lock doesn't, and can't. Any chance of a robust way of communicating those region bounds to Font Lock? > > You yourself pointed out that CC Mode is the sole user of the > > functionality for expanding FL regions. > Indeed. Others use font-lock-extend-region-function. > font-lock-extend-after-change-region-function can be useful when > a *change* on line N can cause a highlighting change on a line when it causes a highlighting change on a line >N and you don't like the > jit-lock-context-time delay (or you want it to work correctly even if > jit-lock(-context) is not in use). Yes. > Stefan -- Alan Mackenzie (Nuremberg, Germany).