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: Sun, 22 Mar 2015 22:01:53 -0400 Message-ID: References: <20150319230136.GC2753@acm.fritz.box> <20150320160744.GA3493@acm.fritz.box> <20150321000003.GF3493@acm.fritz.box> <20150321210325.GC3001@acm.fritz.box> <20150322141335.GA3053@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1427076205 8890 80.91.229.3 (23 Mar 2015 02:03:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Mar 2015 02:03:25 +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 Mon Mar 23 03:03:11 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 1YZrhu-0005Qd-GN for geb-bug-gnu-emacs@m.gmane.org; Mon, 23 Mar 2015 03:03:10 +0100 Original-Received: from localhost ([::1]:53277 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZrht-0003oF-Tb for geb-bug-gnu-emacs@m.gmane.org; Sun, 22 Mar 2015 22:03:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZrhq-0003oA-5S for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 22:03:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZrhm-0006jw-V1 for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 22:03:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZrhm-0006jp-Rj for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 22:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZrhm-0006Op-Fe for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2015 22:03: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: Mon, 23 Mar 2015 02:03: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.142707612524512 (code B ref 20146); Mon, 23 Mar 2015 02:03:02 +0000 Original-Received: (at 20146) by debbugs.gnu.org; 23 Mar 2015 02:02:05 +0000 Original-Received: from localhost ([127.0.0.1]:32903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZrgq-0006NH-BO for submit@debbugs.gnu.org; Sun, 22 Mar 2015 22:02:04 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:1905) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZrgm-0006Mj-Qb for 20146@debbugs.gnu.org; Sun, 22 Mar 2015 22:02:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRFpZgf/2dsb2JhbAA3gVOhb4EIgXUBAQQBVhwHBQsLDiYHCxQYDSSIE6IRi3gDBwsIBgMDBj2DTQMMAQEHB4NUBKNjhFg X-IPAS-Result: AgUFAGvvdVRFpZgf/2dsb2JhbAA3gVOhb4EIgXUBAQQBVhwHBQsLDiYHCxQYDSSIE6IRi3gDBwsIBgMDBj2DTQMMAQEHB4NUBKNjhFg X-IronPort-AV: E=Sophos;i="5.01,1,1400040000"; d="scan'208";a="114233299" Original-Received: from 69-165-152-31.dsl.teksavvy.com (HELO pastel.home) ([69.165.152.31]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2015 22:01:54 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id ED4611A7E; Sun, 22 Mar 2015 22:01:53 -0400 (EDT) In-Reply-To: <20150322141335.GA3053@acm.fritz.box> (Alan Mackenzie's message of "Sun, 22 Mar 2015 14:13:35 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) 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:100820 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. >> > If only, but this is simply not the case at the moment. >> > jit-lock-fontify-now has a hard-coded extension to whole lines, >> > regardless of the contents of font-lock-extend-region-functions. >> There's no relationship between the two. The bounds that >> font-lock-fontify-region [gets] are not under the major mode's control. > Yes they are. They can be set by > font-lock-extend-after-change-region-function, as described in the elisp > manual. That's where you're confused: font-lock-extend-after-change-region-function affects the region that's declared as "in need of refresh because of a change". But that doesn't mean that this region will then be passed to font-lock-fontify-region. For example, if that region is not currently visible in any window, then jit-lock will typically do nothing. And if only some part of that region is visible in a window, then maybe only that part will be then passed to font-lock-fontify-region so as to actually refresh it. And maybe that part will be combined with some other parts that were also in need of refresh and are now newly visible. Or maybe that part will actually be fontified in several steps (i.e. several calls to font-lock-fontify-region). > Yes. I think you've said, indeed quite often, that font-lock has the > same behaviour regardless of whether jit-lock is enabled or not. That's not exactly what I said. What I said is that any highlighting bug (other than a "lack of highlighting") you see with jit-lock can also be reproduced without jit-lock (in the worst case: with manual calls to font-lock-fontify-region). > I need to care a great deal about what jit-lock does, for the reasons in > this thread. If you need to care about it, it can only be because of incorrect assumptions in your font-lock code. > Looking more critically at jit-lock-fontify-now, there is simply no need > for it to expand the region to whole lines. I agree with this statement (I actually have such a change in my local tree), but that won't help you. Looking at jit-lock as the source of your pain is a waste of time. > As a bonus, not extending (start next) would completely prevent the > condition that triggers (via a timer) jit-lock-force-redisplay, so we > could remove that part of the code and j-l-f-redisplay itself. (It is > true that buffer positions before start could have been refontified, but > that is also true of the existing code). > Likewise, there is then no longer any purpose in extending to whole > lines in font-lock-extend-jit-lock-region-after-change, so we can remove > that bit, too. Obviously you still haven't understood the comment: If we don't extend to whole lines in font-lock-extend-jit-lock-region-after-change, then any change on a line which causes a previous char's highlighting to be changed will require a second redisplay before this change is visible. The current code could handle it right (i.e. use jit-lock-force-redisplay to make sure this second redisplay happens right away), but if you additionally get rid of jit-lock-force-redisplay, then the incorrect display would stay visible until something else causes a redisplay. IOW extending to whole lines in font-lock-extend-jit-lock-region-after-change is an optimization, but is definitely not indispensable. > So, as an opener, I propose the following improvement: Non-starter, especially given that you have shown repeatedly that you don't understand the very fundamental design choice that it's perfectly correct to call font-lock-fontify-region with any bounds whatsoever. Stefan