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: Wed, 31 Aug 2016 08:24:58 -0400 Message-ID: References: <20160731121642.GB2205@acm.fritz.box> <83a8gxq288.fsf@gnu.org> <87h9ag3j8c.fsf@russet.org.uk> <87pooqcolw.fsf@russet.org.uk> <8760qh6w4q.fsf@russet.org.uk> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472649820 3316 195.159.176.226 (31 Aug 2016 13:23:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Aug 2016 13:23:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 31 15:23:33 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 1bf5UJ-0008SP-Ln for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2016 15:23:31 +0200 Original-Received: from localhost ([::1]:54182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf5UH-0008AG-Ak for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2016 09:23:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf5Tk-0008A5-Os for emacs-devel@gnu.org; Wed, 31 Aug 2016 09:22:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bf5Th-0001pv-Hz for emacs-devel@gnu.org; Wed, 31 Aug 2016 09:22:56 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:52273) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf5Th-0001pO-EE for emacs-devel@gnu.org; Wed, 31 Aug 2016 09:22:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXFACJI6tX/+V1oWxdHAEBgyeES4VQsF2BfYYXBAICgV07EgEBAQEBAQFdJ4RfAQEDAVYjBQsLNBIUGA2IYAjBXAEBCAIlineKGwWZPJhZhXyOcIE8JQskghIcgWggh14BAQE X-IPAS-Result: A0CXFACJI6tX/+V1oWxdHAEBgyeES4VQsF2BfYYXBAICgV07EgEBAQEBAQFdJ4RfAQEDAVYjBQsLNBIUGA2IYAjBXAEBCAIlineKGwWZPJhZhXyOcIE8JQskghIcgWggh14BAQE X-IronPort-AV: E=Sophos;i="5.28,500,1464667200"; d="scan'208";a="270374595" Original-Received: from 108-161-117-229.dsl.teksavvy.com (HELO pastel.home) ([108.161.117.229]) by smtp.teksavvy.com with ESMTP; 31 Aug 2016 09:22:49 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 607596436C; Wed, 31 Aug 2016 08:24:58 -0400 (EDT) In-Reply-To: <8760qh6w4q.fsf@russet.org.uk> (Phillip Lord's message of "Wed, 31 Aug 2016 12:00:37 +0100") 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:207023 Archived-At: >> 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'". > I think it does not, I am afraid, because the "end" position of b-c-f is > not reliably correct. The `end' position of b-c-f is correct (barring bugs), but is indeed different from the `end' position of a-c-f (the difference is provided by `length'). All I'm saying is that with the code I provided you could do (in a-c-f) what Alan considered doing: (goto-char start) (let ((new-text (delete-and-extract-region start end))) (insert old-text) (let ((old-end (+ start (length old-text)))) (run-my-b-c-f-code start old-end) (goto-char start) (delete-region start old-end) (insert new-text))) Doing it this way would be really annoying, so it's better if your code is able to work directly with `old-text' without having to insert it into the buffer, but at least all the needed info is available. > Ah, yes. But, unfortunately, I cannot calculate the location of the END > position in the cognate buffer. If subst-char-in-region did just what > you are suggesting I do (i.e. signally the maximal extent on a-c-f, as > it does on b-c-f), then there would be no problem. The code I provided does just that (except it does it inside a-c-f but the result is *exactly* the same as if subst-char-in-region were to do it for you). Stefan