From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione 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 04:36:07 -0700 Message-ID: <550D57A7.5040107@dancol.org> References: <20150319230136.GC2753@acm.fritz.box> <20150320160744.GA3493@acm.fritz.box> <20150321000003.GF3493@acm.fritz.box> <550CC42F.7050302@dancol.org> <20150321105841.GA3001@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KDWXXcOQTR6GeIn6akALPuNNaBrO5NCkJ" X-Trace: ger.gmane.org 1426937843 20997 80.91.229.3 (21 Mar 2015 11:37:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Mar 2015 11:37:23 +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 12:37:13 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 1YZHiI-00011K-DP for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 12:37:10 +0100 Original-Received: from localhost ([::1]:47474 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZHiH-0004Gc-Hm for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Mar 2015 07:37:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZHiD-0004GU-0y for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 07:37:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZHiA-00083W-9k for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 07:37:04 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZHiA-00083R-2z for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 07:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZHi9-0003UK-IZ for bug-gnu-emacs@gnu.org; Sat, 21 Mar 2015 07:37:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Mar 2015 11:37: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.142693777913345 (code B ref 20146); Sat, 21 Mar 2015 11:37:01 +0000 Original-Received: (at 20146) by debbugs.gnu.org; 21 Mar 2015 11:36:19 +0000 Original-Received: from localhost ([127.0.0.1]:59612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZHhS-0003TA-Sn for submit@debbugs.gnu.org; Sat, 21 Mar 2015 07:36:19 -0400 Original-Received: from dancol.org ([96.126.100.184]:38636) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YZHhP-0003T0-Nm for 20146@debbugs.gnu.org; Sat, 21 Mar 2015 07:36:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9Y3oJbakhgjuwPne5aS96zIHqKTPhkc+iRtmCQQDTxI=; b=f+Q7N2KGg/+K9VTAEe98RJC0wKA78Pw6XIMbR5kMmNrpfBDSJKMXwzvnbqCNTVr0p9gMMFxO1bp6DbpisRhYsefQrVmf6GKze5XUGhUyCfxvvXiwcvGuMV892PTmRj5sTgOadHaAWUjSYJA339jGVlNmGt8hvxphtOL8b/EpaXqY4PZd5TPuuye0H54/67BGFTipbpi7CrKVi7tesPFBZvOQk0KQp3igOhV3v4f1MfcKTxPpYOElPeHPqIGtJCRAZ4YDRmXJMQBrhHs4zVavGZMGeZ52U1XZT4jH1Gsnk/g+OEUJPPKuP+gqAhQe8/W9B8XkRFSX1CePeStOw1la9w==; Original-Received: from [2620:10d:c083:1004:56ee:75ff:fe20:83dc] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YZHhN-0003wS-H0; Sat, 21 Mar 2015 04:36:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <20150321105841.GA3001@acm.fritz.box> 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:100742 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KDWXXcOQTR6GeIn6akALPuNNaBrO5NCkJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/21/2015 03:58 AM, Alan Mackenzie wrote: > Hello, Daniel. >=20 > On Fri, Mar 20, 2015 at 06:06:55PM -0700, Daniel Colascione wrote: >> On 03/20/2015 05:00 PM, Alan Mackenzie wrote: >>>> 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 p= art: >>>> 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). >=20 >>> 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" fontificat= ion, >>> leaving only "level triggered". >=20 >>> 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, som= e >>> other means will have to be found to transmit this info to Font Lock = - >>> the ugly advice used by earlier Emacs versions, for example. >=20 >> Level-triggered fontification is the only correct scheme. >=20 > Can you offer any evidence, or argumentation for this opinion? As I > said, edge-triggered fontification works in AWK Mode and works well. I= 'm > not quite sure at the moment whether the other CC Mode modes use it. If fontification depends on recent buffer history, then fontification depends on recent buffer history. That's non-determinism. I think it ought to be obvious why we want to highlight the same characters with the same faces no matter how those characters came to be in the buffer. >> You don't need fine-grained control over the font-lock region. >=20 > Major modes need absolute control over where font-locking analysis star= ts > - they must be able to chose a position with a neutral syntactic contex= t. > For example, when Font Lock asks for fontification starting in the > inside of a C++ declaration, C++ Mode needs to be able to say STOP! GO= > BACK! CARRY ON! The mode can start analyzing wherever it wants. There is no rule saying that a mode's font-locking functions can't look at buffer positions before `beg'. font-lock is telling you were it wants you to apply fontification. You can go back further than that to analyze. This analysis does not requiring that we forbid font-lock from arbitrarily extending the region. Why can't cc-mode figure out a "neutral syntactic position" before an arbitrary point? >> You need better cache invalidation. >=20 > When, where, of what? Whatever you're trying to achieve by constricting the font-lock region, you can achieve equally well by maintaining the right caches of buffer context and consulting these caches when servicing font-lock fontification requests. >> Font-lock can ask for the right to ask for the fontification of any >> range of characters. If I want to, I can install customization that >> changes the font-lock region to a whole paragraph, a whole defun, or a= >> whole file. None of that should matter. >=20 > Of course. But AFTER that selection, the major mode decides where to > start analysing based on the selection. As I pointed out to Stefan, we= > don't distinguish between "place to start analysing" and "place to star= t > applying face properties", so we can only talk about "the Font Lock > region". I think the critical point is: Several things can choose, > expand (?or contract) a region to fontify. But the major mode must be > the last entity that does so. Like I said, the mode can analyze whatever buffer text it wants. Why does the analysis region (which is implicit in program logic) depend on the font-lock region? >> Some modes might have caches that reflect buffer contents --- they >> should invalidate these caches in before- and after-change-functions, >> before font-lock even runs. >=20 > Not quite sure exactly what sort of caches you're thinking about, but > they will get updated, rather than invalidated, in the > before/after-change-functions functions, surely? >=20 >> Let me put it another way: a highlighter's job is to find the correct >> face for a given buffer position. In order to not drive the user insan= e, >> that face must be a function solely of the contents of the buffer and >> cached information about the contents of the buffer. Otherwise, >> fontification will change depending on scrolling, jit-lock chunk size,= >> and other factors. None of these things should affect the faces that w= e >> ultimately apply to characters. >=20 > Of course. But they affect the way we calculate those faces. Why? --KDWXXcOQTR6GeIn6akALPuNNaBrO5NCkJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVDVenAAoJEN4WImmbpWBl43MP/3BtUEm7M2ECI+R5GSdAC86D 9JpZWoktXiameC2d5q4sOIN+1Wc1WKhXwzjnvk61npGhRmw4zTWyn87evgcbad1x aPzn9LleFI7xXlETgdC7LN03wKoj9DPmM+98J7BG6zLRBDeddfUMPHe/2UTHB+HQ zLfNSno0geWY1fP2dwcUkyIAo2DAGXExxGTAfyAXY91Vl6uOF/dHjbe57MDYdhaC X7u6LuYJdYQVmCKoIKA0P3b3gB7e6FDSYaT+WUXbMiMiCXK8whEBz1ki9tHjVxbv 29pynhNf6eHj32xneQlbHfOMccyoVnlLnU1IRXVtcToxg9JXpK64rwEFFYnTbkGi a3sp9VjLl/9irN+KdTxPiUoL28KEAOvEiJ7pzHHSqgsdbRV6XOrV6XoUQWRKqOfj 3N+V7XHGEdml8yjHV6lg7vOTWu2Aq40nP3NAKvNsxUWC3UMByM2Lf4J/RzzA81Ni pgl8HBIwjZFhM/N6QjE0VmWCHGqalWue26YeamUR5J4Cv1ecCx3tzFwzWSVWJLgw cr7HiAFHuQihJtltvCzVbKJ9v1JybGKzILJtjC6nCnlmnNV/LW94gq9ZgKduA6mH d71NtwwN+tVx7qdWMjSV/I89GXqY/TWSz4bDcIS/1q2WdmA0KmfpJwIPmU3ra+oO vAGx4wJWC04DVBkuCpvj =NelE -----END PGP SIGNATURE----- --KDWXXcOQTR6GeIn6akALPuNNaBrO5NCkJ--