From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: Unbalanced change hooks (part 2) Date: Thu, 01 Sep 2016 07:49:46 +0100 Message-ID: <87shtkxgfp.fsf@russet.org.uk> 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 1472712610 2256 195.159.176.226 (1 Sep 2016 06:50:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Sep 2016 06:50:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 01 08:50:06 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 1bfLp4-0008Df-H8 for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 08:50:02 +0200 Original-Received: from localhost ([::1]:57470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfLp2-0004FY-2q for ged-emacs-devel@m.gmane.org; Thu, 01 Sep 2016 02:50:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfLou-0004FR-FK for emacs-devel@gnu.org; Thu, 01 Sep 2016 02:49:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bfLor-00060H-9D for emacs-devel@gnu.org; Thu, 01 Sep 2016 02:49:52 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:45485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bfLor-00060C-1Z for emacs-devel@gnu.org; Thu, 01 Sep 2016 02:49:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=sQl0MpUGgG3FS3qgv6DLIpRIa+0nZp0cDd9fUVaYoZ4=; b=I/+At3e249Oew6pkHY5hWvZY8n 99f2WASdY0VGfLd7IF9HXIFAIeVC8w2MIerlnjovnjUOIo5pYcTXM0LIOs3pKfwjES/3FoJUm1QYr ypXQlgbPjuq+uHekChKSO3PB/laDoJDt2M6KqT+QUKEWgvtJAXxhfb4AZKJrCu6Q/VY3STemmwvje KsTPdS3jFDVFNPrhWAx2ICm2zzCq5jqKzYPMZYVWCuM+zniH/wGI7jWVRbUFXy2ZAItFrcl0ZQP2S Eu65FIiCuIyySBuSqhq4OE8pd4hM5ayou4GuYQDVC+w4qqiHKXqzHAC97MGJUMl5F4jH6lVEzo7BK k2XCsGVg==; Original-Received: from cpc14-benw10-2-0-cust305.16-2.cable.virginm.net ([92.234.125.50]:58484 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bfLop-004G4s-Mk; Thu, 01 Sep 2016 07:49:47 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 31 Aug 2016 08:24:58 -0400") X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 31.216.48.48 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:207046 Archived-At: Stefan Monnier writes: >>> 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). So, on a-c-f revert the change, do what we are currently doing on b-c-f, then reapply the change and run what we are currently running on a-c-f. Yes, that does seem a possibility albeit a fairly hideous one. It's really not something I'd want to be doing after every command. I'll test out expanding the region with the code you suggested earlier. (let ((diff (- (cdr lentic--b-c-pos) (+ start length)))) (cl-incf length diff) (cl-incf end diff)) and see if this works. Phil