From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#20146: font-lock-extend-jit-lock-region-after-change: results are discarded instead of being returned. Date: Fri, 20 Mar 2015 22:29:16 -0400 Message-ID: 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 X-Trace: ger.gmane.org 1426905028 26014 80.91.229.3 (21 Mar 2015 02:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 02:30:28 +0000 (UTC) Cc: 20146@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 21 03:30:15 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 1YZ9Ay-0008Hg-NO for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 03:30:12 +0100 Original-Received: from localhost ([::1]:46417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ9Ax-0000h8-Rc for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Mar 2015 22:30:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ9Au-0000ff-Sf for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 22:30:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ9Ar-0001RW-N2 for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 22:30:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ9Ar-0001R5-KH for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 22:30:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZ9Ar-0004kt-0h for bug-gnu-emacs@gnu.org; Fri, 20 Mar 2015 22:30:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Mar 2015 02:30:04 +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.142690496118165 (code B ref 20146); Sat, 21 Mar 2015 02:30:04 +0000 Original-Received: (at 20146) by debbugs.gnu.org; 21 Mar 2015 02:29:21 +0000 Original-Received: from localhost ([127.0.0.1]:59445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZ9A8-0004iu-Uj for submit@debbugs.gnu.org; Fri, 20 Mar 2015 22:29:21 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:58643) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZ9A7-0004im-41 for 20146@debbugs.gnu.org; Fri, 20 Mar 2015 22:29:20 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t2L2TG5k020577; Fri, 20 Mar 2015 22:29:17 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id BAE9EE57; Fri, 20 Mar 2015 22:29:16 -0400 (EDT) In-Reply-To: <20150321000003.GF3493@acm.fritz.box> (Alan Mackenzie's message of "Sat, 21 Mar 2015 00:00:03 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5251=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5251> : inlines <2455> : streams <1408905> : uri <1886017> 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:100731 Archived-At: >> > 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. 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. > As I pointed out to Daniel, the major mode is the expert in where > font-locking must start Indeed, and it instructs font-lock on how to extend the region by setting font-lock-extend-region-function. >> 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. 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. > 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 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). Stefan