From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Effect of deletions on indirect buffers (Bug#8219) Date: Fri, 11 Mar 2011 22:07:54 +0200 Message-ID: <838vwlto85.fsf@gnu.org> References: <877hc5bfqy.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1299874094 21035 80.91.229.12 (11 Mar 2011 20:08:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Mar 2011 20:08:14 +0000 (UTC) Cc: 8219@debbugs.gnu.org, emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 11 21:08:07 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Py8d4-0001uc-9V for ged-emacs-devel@m.gmane.org; Fri, 11 Mar 2011 21:08:07 +0100 Original-Received: from localhost ([127.0.0.1]:59239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Py8d2-00071l-JF for ged-emacs-devel@m.gmane.org; Fri, 11 Mar 2011 15:08:04 -0500 Original-Received: from [140.186.70.92] (port=38203 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Py8cv-0006zC-FZ for emacs-devel@gnu.org; Fri, 11 Mar 2011 15:08:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Py8cr-0006Ry-Q7 for emacs-devel@gnu.org; Fri, 11 Mar 2011 15:07:57 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:65040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Py8cr-0006RT-F9 for emacs-devel@gnu.org; Fri, 11 Mar 2011 15:07:53 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LHW00H00SJB1Y00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 11 Mar 2011 22:07:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.58.59]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LHW00F9KT92OPQ0@a-mtaout22.012.net.il>; Fri, 11 Mar 2011 22:07:51 +0200 (IST) In-reply-to: <877hc5bfqy.fsf@stupidchicken.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:137123 Archived-At: > From: Chong Yidong > Date: Fri, 11 Mar 2011 14:48:21 -0500 > Cc: 8219@debbugs.gnu.org > > Now consider what happens when a deletion is performed in buffer A, > which is the base buffer for an indirect buffer B. It appears that the > responsible functions, such as del_range_2, only update the attributes > of buffer A, making no effort to update buffer B. > > Hence, in the aftermath of a deletion, buffer B's values of PT (and > BUF_BEGV and BUF_ZV) can be larger than BUF_ZV. Isn't that a bug, right there? Why doesn't del_range_2 update the indirect buffer (B) as well, when deletion removes text so that its PT becomes invalid? The ELisp manual says: The text of the indirect buffer is always identical to the text of its base buffer; changes made by editing either one are visible immediately in the other. This includes the text properties as well as the characters themselves. In all other respects, the indirect buffer and its base buffer are completely separate. They have different names, independent values of point, independent narrowing, independent markers and overlays (though inserting or deleting text in either buffer relocates the markers and overlays for both), [...] This makes a lot of sense, but your description seems to point out that the implementation does not behave according to the docs: if markers are (or should be) relocated in sync as result of insertion and deletion, the same should happen with PT, BUF_BEGV, etc. Am I missing something? If not, the solution is to update the attributes of the indirect buffer so as to preserve the invariants, like PT <= BUF_Z etc. > However, I suspect that we have other places in the code that assumes > that if a point is smaller than BUF_ZV, it's necessarily smaller than > BUF_Z It is madness IMO to allow BUF_Z and BUF_ZV be out of sync.