From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ilya Zakharevich Newsgroups: gmane.emacs.help Subject: Re: Redo/Undo (was: etags: M-. jump to the tag(called func), ...) Date: Tue, 20 Sep 2005 22:50:44 +0000 (UTC) Organization: U.C. Berkeley Math. Department. Message-ID: References: <1126436508.461480.28080@z14g2000cwz.googlegroups.com> <85mzm8rwer.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1127257026 13283 80.91.229.2 (20 Sep 2005 22:57:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 20 Sep 2005 22:57:06 +0000 (UTC) Bcc: ilya Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Sep 21 00:56:58 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EHr1I-0007Ww-3y for geh-help-gnu-emacs@m.gmane.org; Wed, 21 Sep 2005 00:55:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHr1H-0003Eq-6q for geh-help-gnu-emacs@m.gmane.org; Tue, 20 Sep 2005 18:55:23 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!news-hog.berkeley.edu!ucberkeley!agate.berkeley.edu!ilya Original-Newsgroups: gnu.emacs.help Original-Lines: 79 Original-NNTP-Posting-Host: powdermilk.math.berkeley.edu Original-X-Trace: agate.berkeley.edu 1127256644 56415 169.229.140.13 (20 Sep 2005 22:50:44 GMT) Original-X-Complaints-To: usenet@agate.berkeley.edu Original-NNTP-Posting-Date: Tue, 20 Sep 2005 22:50:44 +0000 (UTC) User-Agent: trn [how to get a version via %-escapes???] with a custom header X-How-To-Reach-Me: The From: address is valid X-How-To-Disable-Cc: Put in the headers the line: Mail-Copies-To: never \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw Originator: ilya@powdermilk Original-Xref: shelby.stanford.edu gnu.emacs.help:134042 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:29603 Archived-At: [A complimentary Cc of this posting was sent to David Kastrup ], who wrote in article <85mzm8rwer.fsf@lola.goethe.zz>: > > [A complimentary Cc of this posting was sent to > > B. Smith > > ], who wrote in article > > : > > Your practice of "complimentary copies" is a pain in the ass, in > particular when sent from a spam-address. There is no reason for you > to assume that people replying to you on a mailing list do not > actually read the mailing list. a) What makes you think it is a spam-address? b) What makes you think I send it to a mailing list? If you actually read the headers, you can see that your assumptions are both wrong. > > With redo you can do the following (and I do it all the time): > > > > a) go back in time; > > > > b) Maybe I overshoot? go forward in time a little bit. No I did not; > > > > c) So I go back in time some more. > > > > d) Jump to b. > > There is no clear notion about when to abandon history, and which > parts of "going back in time" are actually intended as a forward > change. Of course there is. If you want to keep the maximum amount of state, and allow "linear access" to all these states, then "redoing an undo" should not add states to undo stack, but remove them: Current logic of having the stack of states after doing undo, overshooting and redoing, then editing: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\ | /<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>| | new branch | |>>>>>>>>>>>>>>>>>>>>>> This has the same set of stored states, but avoids the "exponential growth" effect: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>\ | B --> /<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>> One can also keep the information about what are branch points (like B above), and let the users choose what they want to do at point B when they start to undo the whole diagram above: they may want either a) go to the right branch, where they would effective "redo the dead end"; b) go directly to the left branch (which is similar to what the other editors with undo/redo functionality do - they forget about dead ends). > If you want to ignore this, there is redo.el Is it in the distribution now? Thanks, Ilya