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, 30 Aug 2016 11:11:56 -0400 Message-ID: References: <20160731121642.GB2205@acm.fritz.box> <83a8gxq288.fsf@gnu.org> <87h9ag3j8c.fsf@russet.org.uk> <87pooqcolw.fsf@russet.org.uk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472569897 28858 195.159.176.226 (30 Aug 2016 15:11:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Aug 2016 15:11:37 +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 Tue Aug 30 17:11:27 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 1bekhC-0006iZ-HT for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 17:11:26 +0200 Original-Received: from localhost ([::1]:49616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bekhA-0003tm-3Z for ged-emacs-devel@m.gmane.org; Tue, 30 Aug 2016 11:11:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56337) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bekfH-0002vI-1A for emacs-devel@gnu.org; Tue, 30 Aug 2016 11:09:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bekfC-0002P8-Qf for emacs-devel@gnu.org; Tue, 30 Aug 2016 11:09:25 -0400 Original-Received: from [195.159.176.226] (port=35448 helo=blaine.gmane.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bekfC-0002Lx-Hp for emacs-devel@gnu.org; Tue, 30 Aug 2016 11:09:22 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bekev-0003ZZ-7O for emacs-devel@gnu.org; Tue, 30 Aug 2016 17:09:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:zWd9ZMUwyHfopT3m04JB73NGtiw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:206939 Archived-At: >> But it can admittedly be cumbersome since the old-text is now in a string >> rather than being inside the buffer. > Because, I am not using the before and after positions just to recognise > the string that has changed. I was not suggesting to use those position to recognize the string: I was suggesting to use the suggested code to get the old-string so that you can then do what you need on the "before change" state. > I am have to calculate the equivalent positions in the other "lentic" > buffer; and this can only be done before the change, since the two > buffers are them in a consistent state. The idea is that my suggested code gives you the needed info. More specifically, the other buffer is (well, should be) in a state consistent with "the current buffer where start..end is replaced (back) with `old-text'". So that should give you the info needed to update things without doing a "complete flush". As mentioned, it may be inconvenient to use it (depending on details of how the rest of the code is implemented) since the old-text is now in a string rather than being right there in the buffer. >> Note that in the subst-char-in-region you could "make it pairup" >> yourself by hand: if you have (< (+ start length) (cdr lentic--b-c-pos)), >> then you can just >> >> (let ((diff (- (cdr lentic--b-c-pos) (+ start length)))) >> (cl-incf length diff) >> (cl-incf end diff)) >> >> such that (eq (+ start length) (cdr lentic--b-c-pos)). > So, this works because subst-char-in-region is guaranteed not to change > the size of the region right? No. It works because a-c-f's arguments say "nothing was changed before START and after END", so it's always safe (conservative) to move START towards BOB or move END towards EOB (of course, when updating END you also need to update LENGTH correspondingly). Stefan