From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: A new(?) warning of erase-buffer, which was not seen before. Date: Sat, 24 Mar 2007 11:41:50 +0900 Message-ID: <87d52zs6q9.fsf@catnip.gol.com> References: <45FDF35F.6030605@ubin.jp> <45FF5975.1070602@ubin.jp> <4602639A.8030606@ubin.jp> <87vegsj244.fsf@catnip.gol.com> <460407F6.2070708@gmail.com> <46040FD2.70300@gmx.at> Reply-To: Miles Bader NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1174704138 22414 80.91.229.12 (24 Mar 2007 02:42:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 24 Mar 2007 02:42:18 +0000 (UTC) Cc: "Lennart Borgman \(gmail\)" , Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 24 03:42:04 2007 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.50) id 1HUwCh-00008J-4e for ged-emacs-devel@m.gmane.org; Sat, 24 Mar 2007 03:42:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUwEe-0000ed-St for ged-emacs-devel@m.gmane.org; Fri, 23 Mar 2007 21:44:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HUwEb-0000de-Es for emacs-devel@gnu.org; Fri, 23 Mar 2007 22:44:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HUwEZ-0000cV-Pi for emacs-devel@gnu.org; Fri, 23 Mar 2007 22:44:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HUwEZ-0000cM-H9 for emacs-devel@gnu.org; Fri, 23 Mar 2007 21:43:59 -0500 Original-Received: from smtp02.dentaku.gol.com ([203.216.5.72]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HUwCZ-0007Vz-Oe; Fri, 23 Mar 2007 22:41:56 -0400 Original-Received: from 203-216-100-100.dsl.gol.ne.jp ([203.216.100.100] helo=catnip.gol.com) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1HUwCU-0005yV-Tf; Sat, 24 Mar 2007 11:41:51 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 6346B2F43; Sat, 24 Mar 2007 11:41:50 +0900 (JST) System-Type: i686-pc-linux-gnu In-Reply-To: <46040FD2.70300@gmx.at> (martin rudalics's message of "Fri\, 23 Mar 2007 18\:35\:14 +0100") Original-Lines: 29 X-Abuse-Complaints: abuse@gol.com X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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:68452 Archived-At: martin rudalics writes: > You can't do that by simply scanning the buffer-undo-list and comparing > positions. If I recall correctly `erc-update-undo-list' doesn't even > handle the simple case where the undo list records an insertion from A > to B, and you want to insert a text from C to D where A < C and D < B. > It would either modify both A and B or none of them. For uses like erc and comint it hardly matters. I don't know if it's worth trying to support the general case. In the case of comint, I'd actually like to try supporting a model where the undo-list-updating is _not_ handled directly by the text modifying code -- i.e. `insert/delete-without-undo' wouldn't work. The reason is that some text modification is done by various hook functions in comint, and those are harder to control (e.g. they may be written by the user). I don't think this is too much of a problem given the restrictions of comint mode (where non-undoable and undoable modifications are separated by a clear boundary). To support this model in a more general manner I guess would require primitive support (e.g., something like an `inhibit-undo' variable which would cause primitives to adjust the undo list instead of recording undo information). -Miles -- Is it true that nothing can be known? If so how do we know this? -Woody Allen