From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Tue, 02 Aug 2016 10:39:49 -0400 Message-ID: References: <20160731121642.GB2205@acm.fritz.box> <83a8gxq288.fsf@gnu.org> <20160731172804.GD2205@acm.fritz.box> <834m75ptij.fsf@gnu.org> <20160731212635.GF2205@acm.fritz.box> <83shuoocwp.fsf@gnu.org> <20160801165323.GB15055@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1470505064 16415 195.159.176.226 (6 Aug 2016 17:37:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2016 17:37:44 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 19:37:40 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bW5XQ-0002Zk-Uy for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 19:37:33 +0200 Original-Received: from localhost ([::1]:50121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW5XN-00071k-Kv for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2016 13:37:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW5XD-0006yP-9m for emacs-devel@gnu.org; Sat, 06 Aug 2016 13:37:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bW5XB-0006yJ-9V for emacs-devel@gnu.org; Sat, 06 Aug 2016 13:37:18 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:5873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bW5XB-0006yE-33 for emacs-devel@gnu.org; Sat, 06 Aug 2016 13:37:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtFgA731xV/2/xd0tcgxCEAoVVu0CHSwQ+gQI7EgEBAQEBAQGBCkEFg10BBAFWKAsLNBIUGA0DG4g9CM9PizqEIIEChBcBBLM/gUUjgUcME4IuIoE0gUQBAQE X-IPAS-Result: A0AtFgA731xV/2/xd0tcgxCEAoVVu0CHSwQ+gQI7EgEBAQEBAQGBCkEFg10BBAFWKAsLNBIUGA0DG4g9CM9PizqEIIEChBcBBLM/gUUjgUcME4IuIoE0gUQBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="250424349" Original-Received: from 75-119-241-111.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([75.119.241.111]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Aug 2016 13:37:18 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id DDE7FAE539; Sat, 6 Aug 2016 13:37:15 -0400 (EDT) Original-Lines: 37 Original-Received: from list by blaine with local (Exim 4.84_2) (envelope-from ) id 1bUaox-0004OE-LY for emacs-devel@gnu.org; Tue, 02 Aug 2016 16:37:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:eukReq+RR1+EpLNboK6hiX1Es4Q= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206454 Archived-At: > And in such calls, what are the parameters BEG, END, and OLD-LEN supposed > to mean? Same as ever: that compared to the last time the hook was run, nothing was changed before BEG, nothing as changed after END and that the chunk of text between those two had length OLD-LEN last time the hook was run. > An empty buffer is a fully defined state. A buffer immediately following > a deletion is in an undefined state, which requires to know what was > deleted to make it defined again. If you need to know something about the deleted text, you can always keep track of that info in things like text-properties (or buffer-local vars). E.g.: >> > As a concrete example of this, suppose we have this in a buffer: >> > >> > #define foo() first line \ >> > second line \ >> > third line \ >> > fourth line >> > >> > , and the change consists of deleting the backslash on L2. You can handle this case with nothing more than an a-c-f and something like a cc-mode-multiline property applied to the whole CPP construct: in a-c-f you look at the cc-mode-multiline property at BEG and at END and you expand the "area to recompute" according to that property. That's the strategy used by font-lock. Another strategy is the one used by syntax.el which is to simply consider everything after BEG as being in need of review (actually, font-lock also uses this strategy via jit-lock-context). Stefan