Visual Feedback in Undo/Redo

Visual Feedback in Undo/Redo

[Nordlöw]

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?

/Nordlöw

Re: Visual Feedback in Undo/Redo

[Stefan Kamphausen]

Hi,

Nordlöw <per.nordlow@gmail.com> writes:

> 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?

wouldn't it be nicer to ediff the last available state of a buffer
(with all the undos undone) and the current state?  

Then you could apply all the changes you want to and skip the others,
view the changes nicely and use whatever features of ediff you like.

?

Cheers,
Stefan
-- 
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.

Re: Visual Feedback in Undo/Redo

[Xah Lee]

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/

☄

Re: Visual Feedback in Undo/Redo

[Samuel Wales]

To me, the lack of an ordinary redo command (see
http://www.emacswiki.org/emacs/CategoryUndo#toc9 -- redo.el corrupts
the buffer) is the biggest user need.

I am very surprised at the lack of a redo in emacs, actually.

I don't mind if there are fancy geeky features also tucked away,
however, as long as they don't cause bugs or get in the way of the
basic functionality.

Re: Visual Feedback in Undo/Redo

[Xah Lee]

On Dec 17, 11:26 am, "Samuel Wales" <samolog...@gmail.com> wrote:
> To me, the lack of an ordinary redo command (seehttp://www.emacswiki.org/emacs/CategoryUndo#toc9-- redo.el corrupts
> the buffer) is the biggest user need.
>
> I am very surprised at the lack of a redo in emacs, actually.
>
> I don't mind if there are fancy geeky features also tucked away,
> however, as long as they don't cause bugs or get in the way of the
> basic functionality.

i concur.

I used emacs daily for more than 8 hours a day since 1998.  In my now
one decade of using emacs, i don't recall i ever needed undo of
undos.  To achieve redo, i do “type something and undo”. But once this
is done, any undo history before that point are effectively useless to
me, because the roller-coasting undo history is too convoluted for the
mind to keep up.

I started to use “redo.el” in about 2006 with Carbon emacs on the Mac.
Supposedly, it solves the problem. However, i've also noticed that
sometimes it does weird things not expectated. Also, it does not seems
to actually make emacs's undo system into just undo and redos. The
emacs's “undo of undos” seems still available...

Even having lived in emacs for 10 years, first 5 years being purely in
a text terminal, and having programed elisp weekly since 2006, i've
never taken the time to investigate what exactly “redo.el” is doing...
(a look at emacs wiki indicates that there are few others too)

They say linux is a black hole of your time. Emacs geeks might say you
should read the doc, and that your confusing is caused by your
ignorance, etc. When one post this in so much as a complaint to emacs
forums, then emacs geeks insist in some chastising tone that you
should either read the fucking manual to clear your confusion, or
(further) take your time to report the bug. If one is to spend time on
all these little details, one wouldn't go anywhere in life.

Many emacs geekers may feel that the above sentiment is just mine, not
shared by many. The fact is, the defensive view of emacs's ways is
some 0.01% of professional programers. Emacs geeks are just a tight
clique among themselves. In a similar way, Apple computer users is
some ~5% in the past 10 years, and linux/unix some less, and lesser is
Common Lisp or Scheme Lisp programers among programers. Some issues
comes up frequently in online forums of these communities, and in the
ensuing defensive discussion, any outsider can see how bizarre and
silly these geekers have become, but not by themselves. Although many
aspects of Mac and Lisp are simply superior, but not necessarily
immune to the fast changing computing world, especially in the last 10
years. The tech geekers, have ceased to be capable to see things
outside their world.

In 2006, i selected some 5 items that i consider emacs should change.
These items are selected roughly by their ratio of “impact”/“ease of
fix”.

• The Modernization of Emacs
  http://xahlee.org/emacs/modernization.html

2 of the items, are now fixed in the upcoming emacs 23, namely:
highlighting text selection and cursor moving by visual line.

Having a simple undo/redo is one of them.

Here's a excerpt on the undo/redo issue:

Q: Emacs's undo is superior, because the prevalent Undo/Redo system
actually lose info.

A: Emac's undo is very confusing and does not have a Redo command. To
redo after a undo, people are told to type something then do a undo.
Long time emacs user argue that it is technically superior because it
lets user to revert to any possible state of the past.

A practical problem with the way of emacs undo is that it repeats the
states in the action record. In the prevalent undo model, the action
record is linear, and each entry is unique. A user can easily arrive
at a desired previous state using undo and redo. Think of it as a time-
line with a needle. “Undo” is like moving the needle backward, and
“redo” moves the needle forward. A user does a sequence of undos and
redos to move the needle to where he wants, then he starts there
fresh.

Emacs's undo is not based on simple time-line. In emacs, every undo
pushes a state to a stack. If we think in terms of a time-line of
unique states, then each emacs's “undo” may move the needle backward
or it may move it forward. If a user ever did a redo (by typing
something then undo), then a series of undos will traverse the time-
line back and forth. It is hard for a user to know when to do undo or
do “some random typing followed by undo” to get to the state he wants.
In particular, once a person did more than once of “some random typing
followed by undo”, the undo record becomes too convoluted for a person
to keep in mind and the benefit of undo facility is ruined at that
point.

If you take a survey among programers who use emacs for at least 1
year, perhaps more than 90% will report it confusing and not
productive. If you take a survey of software users other than emacs, i
do not think anyone will complain that they are unable undo their
undos.

It is reasonable to argue, that people work better with a simple undo/
redo model. Undo is practically used to erase a mistake or doing a
simple one-time revision. Once a user did a sequence of undos and
redos, we can assume that he arrived at a satisfactory point and
intends to start fresh from that point. If he needs extra revision
control, a more proper mechanism, one that people actually use, is to
revert to the saved version.

For some discussions, see: http://briancarper.net/2008/05/25/emacs-undo-is-horrible/,
http://www.reddit.com/r/programming/info/6kscz/comments/.

------------------------------

If you feel that emacs's undo is hard to use, perhaps it is welcome in
“Alt+x report-emacs-bug”.

Alternatively, use Aquamacs Emacs on the Mac, or send a mail to
Lennart Borgman (author of EmacsW32 for Windows). Maybe Lennart can
take the burden of modernization of emacs by broadening his EmacsW32's
Windows UI conformity.

  Xah
∑ http://xahlee.org/

☄