unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Xah Lee <xahlee@gmail.com>
To: help-gnu-emacs@gnu.org
Subject: Re: Visual Feedback in Undo/Redo
Date: Wed, 17 Dec 2008 04:44:21 -0800 (PST)	[thread overview]
Message-ID: <ab4dcadd-5635-4681-8fd1-28036607b25b@r10g2000prf.googlegroups.com> (raw)
In-Reply-To: 595463eb-f642-4fb4-8ca3-5597e2d6f27f@v5g2000prm.googlegroups.com

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/

  parent reply	other threads:[~2008-12-17 12:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 11:10 Visual Feedback in Undo/Redo Nordlöw
2008-12-15 12:51 ` Stefan Kamphausen
2008-12-17 12:44 ` Xah Lee [this message]
2008-12-17 19:26   ` Samuel Wales
     [not found]   ` <mailman.2972.1229542872.26697.help-gnu-emacs@gnu.org>
2008-12-18 21:37     ` Xah Lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab4dcadd-5635-4681-8fd1-28036607b25b@r10g2000prf.googlegroups.com \
    --to=xahlee@gmail.com \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).