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: Sat, 21 Mar 2015 10:55:06 -0400 Message-ID: References: <20150319230136.GC2753@acm.fritz.box> <20150320160744.GA3493@acm.fritz.box> <20150321000003.GF3493@acm.fritz.box> <20150321131924.GB3001@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426949789 3965 80.91.229.3 (21 Mar 2015 14:56:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 14:56:29 +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 15:56:14 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 1YZKos-0000Bc-AL for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 15:56:10 +0100 Original-Received: from localhost ([::1]:48017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZKor-0004rF-K8 for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 10:56:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZKon-0004r9-PB for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 10:56:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZKok-0003tU-IG for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 10:56:05 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZKok-0003tQ-FX for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 10:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZKok-0008Rs-68 for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 10:56:02 -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 14:56:02 +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.142694971332412 (code B ref 20146); Sat, 21 Mar 2015 14:56:02 +0000 Original-Received: (at 20146) by debbugs.gnu.org; 21 Mar 2015 14:55:13 +0000 Original-Received: from localhost ([127.0.0.1]:59971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZKnw-0008Qh-G9 for submit@debbugs.gnu.org; Sat, 21 Mar 2015 10:55:13 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:39779) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZKnt-0008QX-TQ for 20146@debbugs.gnu.org; Sat, 21 Mar 2015 10:55:10 -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 t2LEt67H023943; Sat, 21 Mar 2015 10:55:07 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 88EC3127B; Sat, 21 Mar 2015 10:55:06 -0400 (EDT) In-Reply-To: <20150321131924.GB3001@acm.fritz.box> (Alan Mackenzie's message of "Sat, 21 Mar 2015 13:19:24 +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 RV5252=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5252> : inlines <2455> : streams <1409190> : uri <1886417> 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:100746 Archived-At: >> 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 whole set of functions is under the control of the major-mode. So if you don't like the other two functions, you can remove them just fine (as you've done). But as you've now seen in this bug#20146, removing font-lock-extend-region-wholelines is probably not a good idea because your own font-lock rules rely on it. And font-lock-extend-region-multiline has no effect if you don't use set the `font-lock-multiline' property, so removing it would only affect performance, not behavior. > 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? Of course: most font-lock-keywords will misbehave if the region is not made up of whole lines. So if font-lock-extend-region-multiline extends the region to something that's not made of whole lines we have a problem. Similarly, if font-lock-extend-region-wholelines extends the region to start or end in the middle of a font-lock-multiline property we have a problem. So they need to be cycled. >> 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, f-l-extend-region-functions is run *after* font-lock-fontify-region is called, so I don't understand what you mean by "already". And those bounds aren't changed afterwards. >> No, it is just good design to keep complexity under check. > ??? For example, it means, that if the highlighting is incorrect, it *can't* be because of a bug in jit-lock. A highlighting problem can only come from jit-lock in case the highlighting has simply not been (re)applied. >> 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. I'm definitely not picking nits. Those two concepts are similar yet different and independent. > 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? Yes: font-lock-extend-region-functions. Stefan