From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Lee Newsgroups: gmane.emacs.help Subject: Re: Visual Feedback in Undo/Redo Date: Wed, 17 Dec 2008 04:44:21 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <595463eb-f642-4fb4-8ca3-5597e2d6f27f@v5g2000prm.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1229522560 17776 80.91.229.12 (17 Dec 2008 14:02:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2008 14:02:40 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 17 15:03:45 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LCwzj-0003p4-W8 for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Dec 2008 15:03:24 +0100 Original-Received: from localhost ([127.0.0.1]:34170 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCwyY-0002W0-2w for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Dec 2008 09:02:10 -0500 Original-Path: news.stanford.edu!newsfeed.stanford.edu!postnews.google.com!r10g2000prf.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help,comp.emacs Original-Lines: 63 Original-NNTP-Posting-Host: 76.102.50.240 Original-X-Trace: posting.google.com 1229517861 7451 127.0.0.1 (17 Dec 2008 12:44:21 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Wed, 17 Dec 2008 12:44:21 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r10g2000prf.googlegroups.com; posting-host=76.102.50.240; posting-account=bRPKjQoAAACxZsR8_VPXCX27T2YcsyMA User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; en) AppleWebKit/525.27.1 (KHTML, like Gecko) Version/3.2.1 Safari/525.27.1, gzip(gfe), gzip(gfe) Original-Xref: news.stanford.edu gnu.emacs.help:165399 comp.emacs:97482 X-Mailman-Approved-At: Wed, 17 Dec 2008 08:55:01 -0500 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:60731 Archived-At: On Dec 15, 3:10 am, Nordl=C3=B6w wrote: > I often get a feeling of being a bit lost when navigation large undo/ > redo histories. I have two suggestions on how to reduce this > "lostness": > > 1. Provide a rational number X/N at the end of undo/redo minibuffer > message where X is the current position in the undo/redo history and N > is the size of the whole history. This directly applies to the > behaviour of redo.el but I don't know how to apply this concept Emacs > vanilla undo-behaviours as all undos are add to the undo history. I > believe a tree-based history structure would be more intutitive but of > course more complicated to visualize. I have tried to implement the X/ > N feedback in redo.el but the complexity of this file is above my > current capacity as an elisp programmer. > > 2. Highlight undo/redo-history entries in the buffer like is done in > isearch-mode. > - Next upcoming kill is highlighted in a stronger colored red face > or perhaps even better overstriked in red. > - The rest of the pending kills are highlighted like the next kill > but in a more red-fainter color. > - Already performed inserts could be highlighted in some opposite > attribute say in green color but without the overstrike attribute. > > Comments on that? I think it makes it too complex. Emacs's undo system is already too complex. In general, based on my past few years of study of emacs, i find many of emacs's system too complex. This situation is similar to unix or other tech geeking system. It has one million functionalities to cope with one million situations. But in practical use, 90% of need is just on the 10% of functionalities. In emacs, the 10% does not do well, and requires the users to learn about A, B, C, D, E, F, G. Tech geekers like to think this is powerful and precise and comprehensive. In practice, it's comparatively less useful that way. Emacs's undo system is one of the concrete example. Nobody really need undo of undos (which is the one million precision functionality). Yet there's no simple redo (which is the 10% functionalites that is needed 90% of time) Then, you are suggesting to complicate the undo by more elaborate visual feedback system... ... i've been using the Mac since ~1991, daily, for maybe more than 8 hours a day on average. Over the years, there are 3rd party utilities or in editors that support multiple clipboards. Apple indeed has incorparted many functionalities that was originally a 3rd party product (in particular, System Extensions of the Classic Mac OS era (roughly pre 2000)). However, the multiple clipboard never caught on. Technically, sure it is superior. But in practice, it make things more complex, and is not really needed for 99% of users or is not common need. This applies to much of tech geeker's software, which often is not successful. Such systems typically are limited to a small clique of users, and each different tech geeking software has its own complete competing complex systems that supposedly cover complex situations that looks good on paper. For exmaples of sucessuful software design or philosophy, look at Microsoft, Apple, Google. Xah =E2=88=91 http://xahlee.org/ =E2=98=84