From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Mon, 08 Aug 2016 20:17:42 +0300 Message-ID: <83d1lji3ih.fsf@gnu.org> References: <20160731121642.GB2205@acm.fritz.box> <20160802101549.GA2328@acm.fritz.box> <83r3a7md69.fsf@gnu.org> <20160802165545.GD2328@acm.fritz.box> <83fuqnm6og.fsf@gnu.org> <83eg67m3aq.fsf@gnu.org> <20160808143614.GA7208@acm.fritz.box> <83mvkni7xf.fsf@gnu.org> <20160808165449.GB7208@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1470676724 17951 195.159.176.226 (8 Aug 2016 17:18:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Aug 2016 17:18:44 +0000 (UTC) Cc: ofv@wanadoo.es, rcopley@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 08 19:18: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 1bWoBv-0001ds-NJ for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 19:18:19 +0200 Original-Received: from localhost ([::1]:58889 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWoBs-00014T-FA for ged-emacs-devel@m.gmane.org; Mon, 08 Aug 2016 13:18:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWoBl-00014L-UO for emacs-devel@gnu.org; Mon, 08 Aug 2016 13:18:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bWoBh-00010h-Pg for emacs-devel@gnu.org; Mon, 08 Aug 2016 13:18:08 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35607) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bWoBh-00010d-MU; Mon, 08 Aug 2016 13:18:05 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4825 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bWoBZ-0003VC-73; Mon, 08 Aug 2016 13:17:57 -0400 In-reply-to: <20160808165449.GB7208@acm.fritz.box> (message from Alan Mackenzie on Mon, 8 Aug 2016 16:54:49 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:206492 Archived-At: > Date: Mon, 8 Aug 2016 16:54:49 +0000 > Cc: ofv@wanadoo.es, rcopley@gmail.com, rms@gnu.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > What triggers that code? > > before/after-change-functions. For example, in C++ Mode, if a "<" > template delimiter is about is in a region about to be deleted, and the > matching ">" is after that region, the pertinent function called from > c-before-change (c-before-change-check-<>-operators) removes the > syntax-table properties from each of them. > > > E.g., when a file is visited, what invokes that code, and how much of > > the buffer it processes when invoked? > > On a newly visited file, the entire buffer is scanned by (the components > of) c-before-change and c-after-change, setting the text properties. So, if worse comes to worst, you could trigger such a complete scan after revert-buffer, e.g. in a specialized revert-buffer-function. Do you have a way of completely forgetting everything about a certain region of buffer text, and rescanning that region anew? If so, would it work to do this in c-after-change, since its arguments tell you both the old and the new buffer positions where the changes were made? If this works, it might be less expensive then rescanning the entire buffer. > What I'm looking at at the moment is calling revert-buffer a second time > if CC Mode signals a missing before-change-functions the first time. > After the test scenario, M-x revert-buffer works, so it might work if > called from the code instead. I don't understand how this could work reliably: it has the same problems as the original recipe. Am I missing something?