emacs-devel
[Top][All Lists]
Advanced

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

RE: AW: AW: New undo element (fun . args)


From: klaus.berndl
Subject: RE: AW: AW: New undo element (fun . args)
Date: Mon, 7 Feb 2005 17:29:48 +0100

Stefan Monnier wrote:
>> Then these are your experiences with "your" users... but for me an
>> undo is annoying (and even quite unuseable) which doesn't protect me
>> against accidentally "undoing some undos" (i.e. with current
>> Emacs-undo i get no information from Emacs that my undo-action is
>> not really an undo but a redo of a previous undo - if you understand
>> what i try to say ;-) 
> 
> Of course I understand what you say.  I worked on this specific part
> of the behavior to implement undo-only.  And your remark is not quite
> true: 
> the echo area tells you either "Undo!" or "Redo!" depending on whether
> you're undoing an undo or not.

Yes, that's right, so my statement was i simplification, i admit: IMHO
a message in the echo-area is not eye-catching (or something elso ;-) enough,
to protect me really against this - when i want to undo soem things i often
hit the undo-keybinding very fast in sequence so i have really no chance
to see when the echo-reports what you say and then stop my undoing - no chance.

> Actually my own local Emacs has a further hack such that when `undo'
> notices it's actually undoing an undo it asks me whether I want to
> "redo" or not (if not, it does what `undo-only' would have done,
> skipping the redo-undo pair). This is an experiment and I'm not
> satisfied with it as it is (it's too annoying).

Hmm, maybe there is no undo-behavior available which satisfies all people
of the world and maybe this is really often a matter of taste or habit
but for your experiment sounds very interesting - interesting enough so
i would ask for an option where i can switch on this behavior (it would
be very ok for me, if then default value would switch off this behavior -
all what i want - and a lot of other Emacser i know ;-) - is the possibility
to get an undoing which can be intuitively (or lets call it simpler - i'm up for
it) being used than the current one...

> 
>> And when undoing some steps i often reach a point where i do not know
>> exactly where i'm in the undo-chain - whereas with redo.el i exactly
>> know when i have undone all and when there is nothing more to undo -
> 
> Yes, redo.el is much more limited and has a much simpler linear model,
> whereas Emacs's undo keeps track of a tree of buffer modifications,
> which is more difficult to model in your head.

a tree? really? That's indeed new for me - does the Emacs-manual explain me
this tree in an understandable way?...let's have a look...

I found for example this in the manual of 21.3.1:

"... Consecutive repetitions of `C-_' or `C-x u' undo earlier and earlier
changes, back to the limit of the undo information available.  If all
recorded changes have already been undone, the undo command displays an
error message and does nothing."

I have tried this and have to say that this simply not true. I have deleted
some regions from a buffer an d inserted some text and then i called undo
in a infinite sequence and never Emacs stops undoing - i could do this until
i get black-colored (a german phrase, i could also write "...until i die" ;-)

and i found 

"... Any command other than an undo command breaks the sequence of undo
commands.  Starting from that moment, the previous undo commands become
ordinary changes that you can undo.  Thus, to redo changes you have
undone, type `C-f' or any other command that will harmlessly break the
sequence of undoing, then type more undo commands...."

IMO i found this mechanism very clumsy that i have to call some "harmless"
command (which i don't need in this moment) to "break" the undoing and
can redoing now my undos....

Sorry, maybe i'm too stupid but IMHO this is really not intuitive.., and i
found nothing in this description what would lead me to a undo-tree as you
wrote...

> I wouldn't call it more intuitive, but simpler.

Often simpler is better ... ;-)

Ciao,
Klaus




reply via email to

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