From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: A new(?) warning of erase-buffer, which was not seen before. Date: Sat, 24 Mar 2007 10:09:40 +0100 Message-ID: <4604EAD4.4090207@gmx.at> 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> <87d52zs6q9.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174728549 28314 80.91.229.12 (24 Mar 2007 09:29:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 24 Mar 2007 09:29:09 +0000 (UTC) Cc: "Lennart Borgman \(gmail\)" , Stefan Monnier , emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 24 10:29:06 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 1HV2YZ-0003rq-Lj for ged-emacs-devel@m.gmane.org; Sat, 24 Mar 2007 10:29:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HV2aY-0005s9-LA for ged-emacs-devel@m.gmane.org; Sat, 24 Mar 2007 04:31:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HV2aW-0005ou-4I for emacs-devel@gnu.org; Sat, 24 Mar 2007 05:31:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HV2aS-0005fv-Bm for emacs-devel@gnu.org; Sat, 24 Mar 2007 05:31:03 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HV2aS-0005fl-7A for emacs-devel@gnu.org; Sat, 24 Mar 2007 04:31:00 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1HV2YQ-0005cP-CL for emacs-devel@gnu.org; Sat, 24 Mar 2007 05:28:55 -0400 Original-Received: (qmail invoked by alias); 24 Mar 2007 09:28:49 -0000 Original-Received: from N828P027.adsl.highway.telekom.at (EHLO [62.47.47.123]) [62.47.47.123] by mail.gmx.net (mp042) with SMTP; 24 Mar 2007 10:28:49 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/NaqwqJNjNIpo5jHoLdvg8/tmB7jQYj9aStTL2ub XyIA3Y2o0tarR2 User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <87d52zs6q9.fsf@catnip.gol.com> X-Y-GMX-Trusted: 0 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:68458 Archived-At: > 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). Agreed. > 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). I think it's not feasible. I tried to write such code for customization buffers - where undo can erase entire buffer contents - but didn't get very far. It should be possible though since these undos have "clear boundaries" as for the comint case (hence you could try to have a look at this - maybe you come up with a solution that works for both). A general solution would virtually have to undo every single action on the undo list to check how a current non-undoable modification interferes with undoable ones.