help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Visual Feedback in Undo/Redo


From: Xah Lee
Subject: Re: Visual Feedback in Undo/Redo
Date: Wed, 17 Dec 2008 04:44:21 -0800 (PST)
User-agent: G2/1.0

On Dec 15, 3:10 am, Nordlöw <per.nord...@gmail.com> 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
∑ http://xahlee.org/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]