From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: [Request for Mentor] subst-char-in-region Date: Fri, 12 Dec 2014 15:05:42 +0000 Message-ID: <87bnn8j4c9.fsf@newcastle.ac.uk> References: <87r3w5jdow.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418396766 17896 80.91.229.3 (12 Dec 2014 15:06:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2014 15:06:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 12 16:05:59 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XzRn4-0007up-Fo for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2014 16:05:58 +0100 Original-Received: from localhost ([::1]:57738 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzRn3-0003cd-WF for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2014 10:05:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzRmv-0003c7-NA for emacs-devel@gnu.org; Fri, 12 Dec 2014 10:05:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XzRmq-0002qs-TN for emacs-devel@gnu.org; Fri, 12 Dec 2014 10:05:49 -0500 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:34046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XzRmq-0002qe-Lx for emacs-devel@gnu.org; Fri, 12 Dec 2014 10:05:44 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1XzRmp-00024P-FY; Fri, 12 Dec 2014 15:05:43 +0000 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XzRmo-0007z7-NK; Fri, 12 Dec 2014 15:05:42 +0000 In-Reply-To: (Stefan Monnier's message of "Fri, 12 Dec 2014 09:35:16 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179919 Archived-At: Stefan Monnier writes: >> ooo >> bbb > >> Changing ooo to xxx reports the following from Emacs > >> before(1,8) >> after(1,4,3) > > That looks correct to me. Why? The doc says "the positions of the beginning and end of the old text to be changed" for before-change-function. But the text from 4 to 8 is not changed. As indeed the after-change-functions value says. If the doc means "the position of the beginning and end of the old text which is potentially open for change but may not actually change", then that would have been a different issue. Given that the change in this case is a substution why is it not: before(1,4) after (1,4,3) This could be calculated, of course, by subst-char-in-region, although it would potentially require scanning the region twice (once to find start and stop, once to actually make changes). >> origin/fix/subst-char-in-region >> (hopefully adding a new branch is okay for this, obviously it can be >> deleted later). After adding this fix I get... > > Please use "scratch/" rather than "fix/". Will do. > >> before(1,8) >> after(1,8,8) > > This wouldn't be wrong, but would be less precise. Yep, I agree. > >> Assuming others agree with me that this behaviour is wrong, I would like >> to fix the problem, but would welcome some help and code review. > > Assuming a close&direct correct correspondence between > before-change-functions and after-change-functions is just a bad idea. > Does you code *really* need that? At the moment, yes, it does. I am keeping two buffers in sync by transfering changes between them. It does this by removing the text in "that buffer" between the before change values and replacing it with the text in "this buffer" (it's slightly more complex than this, but that's the basic idea). In general, I have found that this works. For instance, replacing subst-char-in-region with a more traditional search and replace operation would work fine. Whether it could be done in another way, not assuming that this correspondence, I just do not know. At the moment, I do not see an obvious way. Even if I did see an obvious way, I might be wrong. I've already found quite a few edge cases which I didn't think about when I started. Phil