Re: REDO ?

Re: REDO ?

[A Soare]

> 
> > What do you think about inserting a redo command for the next version ? (23)
> > For me it could be very useful.
> 
> Yes, it's pretty much on my todo list.  Note that we already have "redo",
> just not as a command.  The current way to do "redo" is to use the command
> "undo".  The only difference is that if the last modification was not an
> "undo" the undo command will not fail (as "redo" would) but will simply undo
> instead.  Also if the last command was an "undo", the undo command will keep
> undoing instead of doing a "redo" (i.e. undoing the last undo).
> 

Logically in this moment the redo should be done by a negative
argument. But:

a
b
c

C-/ => Undo!

a
b


Now it should be possible to apply a redo.

M-- M-1 C-/ => Undo!

But the text did not change to

a
b
c
.



> > Also, every time when we press undo or redo, to see (optionally) in the
> > minibuffer the current change in yank kill, and the previous, and
> > the next.
> 
> I do not understand.

This would be good if it possible to implement it. I meant to see
in the minibuffer after applying an undo or a redo the text after
applying next an undo and the text after applying next a redo...

Alin Soare.

Re: REDO ?

[Stefan Monnier]

> Logically in this moment the redo should be done by a negative
> argument. But:

> a
> b
> c

> C-/ => Undo!

> a
> b


> Now it should be possible to apply a redo.

> M-- M-1 C-/ => Undo!

That might be a good addition, indeed.

> This would be good if it possible to implement it.  I meant to see in the
> minibuffer after applying an undo or a redo the text after applying next
> an undo and the text after applying next a redo...

Sounds very difficult.  Maybe we could simply highlight the newly
modified text somehow.

And maybe we could additionally provide a "undo-slow" that would first
highlight the about-to-changed text, then wait a short little while, then
perform the undo and highlight the new text (and maybe even highlight the
"next text to be undone").


        Stefan

Re: REDO ?

[Richard Stallman]

    Now it should be possible to apply a redo.

    M-- M-1 C-/ => Undo!

M-- M-1 C-/ is sufficiently inconvenient that I doubt
it is worth having.

Re: REDO ?

[Davis Herring]

>     Now it should be possible to apply a redo.
>
>     M-- M-1 C-/ => Undo!
>
> M-- M-1 C-/ is sufficiently inconvenient that I doubt
> it is worth having.

Just as a comment on the key, C-- C-_ would have the same effect with a
somewhat less frustrating typing effort.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: REDO ?

[Richard Stallman]

    This would be good if it possible to implement it. I meant to see
    in the minibuffer after applying an undo or a redo the text after
    applying next an undo and the text after applying next a redo...

That might be a nice feature.  Please try it out and we'll see
what it's like to use.

Re: REDO ?

[A Soare]

>     This would be good if it possible to implement it. I meant to see
>     in the minibuffer after applying an undo or a redo the text after
>     applying next an undo and the text after applying next a redo...

I will occupy myself of the problem to write a patch after the release so:

1 -> C-u as parameter to UNDO command will reverse the direction from undo to redo or from redo to undo.
2 -> The current undo/redo will be inserted in the buffer with WHITE.
3 -> The previous UNDO/REDO will be inserted with RED.
4 -> And the next UNDO/REDO will be inserted with BLUE.
5 -> When WHITE and BLUE text will be superposed it will be shown in BLUE CIEL, WHITE+RED in LIGHT RED , etcetera.
6 -> pressing another key than the key associated with UNDO will keep permanent the WHITE text and will take out the RED and BLUE text.

Alin Soare.

RE: REDO ?

[Drew Adams]

> >     This would be good if it possible to implement it. I meant to see
> >     in the minibuffer after applying an undo or a redo the text after
> >     applying next an undo and the text after applying next a redo...
> 
> I will occupy myself of the problem to write a patch after the release so:
> 
> 1 -> C-u as parameter to UNDO command will reverse the direction 
> from undo to redo or from redo to undo.
> 2 -> The current undo/redo will be inserted in the buffer with WHITE.
> 3 -> The previous UNDO/REDO will be inserted with RED.
> 4 -> And the next UNDO/REDO will be inserted with BLUE.
> 5 -> When WHITE and BLUE text will be superposed it will be shown 
> in BLUE CIEL, WHITE+RED in LIGHT RED , etcetera.
> 6 -> pressing another key than the key associated with UNDO will 
> keep permanent the WHITE text and will take out the RED and BLUE text.

I imagine that this will be discussed before it is adopted, but if it does get adopted, please provide an option to avoid all of that and get back the "classical" Emacs undo.

Re: REDO ?

[A Soare]

> I think it is a bad idea to have a separate redo command,
> simply because there is no room on the keyboard for a
> convenient one, and an inconvenient one won't do much good.
> 

Not different. Just the same, but to be possible to reverse the direction of the yank (using a parameter for example), even from the beginning of the action, not to be obliged first to apply an undo, etcetera.

Re: REDO ?

[David Reitter]

On 23 Apr 2007, at 16:46, A Soare wrote:

> Not different. Just the same, but to be possible to reverse the  
> direction of the yank (using a parameter for example), even from  
> the beginning of the action, not to be obliged first to apply an  
> undo, etcetera.

A while agao, we integrated an undo/redo function into Aquamacs,  
because that's what users generally get in programs running on that  
specific OS.

A few of our users preferred the original `undo', so it makes sense  
to leave C-_ as it is. (The idea to bind a prefix key combination to  
the new `redo' makes sense.)

Additionally, our `undo' and `redo' restore the region.

The code (based on the `redo' package by Kyle E Jones) is available  
below. If people are interested, I could rewrite it to fit into Emacs  
after the release.


http://aquamacs.cvs.sourceforge.net/*checkout*/aquamacs/aquamacs/src/ 
site-lisp/aquamacs-redo.el

Re: REDO ?

[Stefan Monnier]

>> Not different.  Just the same, but to be possible to reverse the
>> direction of the yank (using a parameter for example), even from the
>> beginning of the action, not to be obliged first to apply an
>> undo, etcetera.

> A while agao, we integrated an undo/redo function into Aquamacs, because
> that's what users generally get in programs running on that specific OS.

> A few of our users preferred the original `undo', so it makes sense to
> leave C-_ as it is. (The idea to bind a prefix key combination to the new
> redo' makes sense.)

> Additionally, our `undo' and `redo' restore the region.

> The code (based on the `redo' package by Kyle E Jones) is available below.
> If people are interested, I could rewrite it to fit into Emacs after
> the release.

We already have the "undo" half of your undo/redo, under the name
"undo-only".


        Stefan

Re: REDO ?

[Ken Manheimer]

i would like to chime in with a strong request integration of a rel
"redo", when the time is right.

i've used kyle jones' redo.el for a few years, and wouldn't go back to
the painful layering of undo-on-undo in order to redo.  undoing feels
like a delicate, hazardous operation without redo, because of the
obstacle of geometrically mounting undo length in the case of
overshoot.  i used to get lost in that labrynth much too commonly, and
expect that people unfamiliar with how well it is mitigated by redo
don't realize what they're missing - but may recognize the experience
of tension while undoing, needing to not overshoot...

(i've settled for using the usupported redo.el for years, but there
are some bugs that i'm sure would have been resolved if it were a
commonly used part of the main distribution.)

--
Ken Manheimer
http://myriadicity.net

Re: REDO ?

[Davis Herring]

> i've used kyle jones' redo.el for a few years, and wouldn't go back to
> the painful layering of undo-on-undo in order to redo.  undoing feels
> like a delicate, hazardous operation without redo, because of the
> obstacle of geometrically mounting undo length in the case of
> overshoot.  i used to get lost in that labrynth much too commonly, and
> expect that people unfamiliar with how well it is mitigated by redo
> don't realize what they're missing - but may recognize the experience
> of tension while undoing, needing to not overshoot...

My take on this is somewhat simpler.  I use the following function (which,
though it works fine for me, could easily screw things up badly, so use at
your own risk):

;; In order to propertly handle "already performing undos", this must be
;; bound to a key (not run via M-x).
(defun undo-permanently ()
  "Undo the most recent change and forget about it.
Selective undo is not supported, so no prefix argument is accepted, and
Transient Mark mode is ignored.
If already performing undos, undo one more change and then forget it and all
changes since."
  (interactive "*")
  (let (transient-mark-mode)
    (when (and (eq last-command 'undo)
               (not (eq pending-undo-list t)))
      ;; In Emacs 22, just test `undo-in-region' instead of all this:
      (let ((pbul buffer-undo-list))
        (while (not (eq pbul pending-undo-list))
          (if pbul (setq pbul (cdr pbul))
            (error "Can't `undo-permanently' during a selective undo")))))
    (undo)
    (message "Permanently undone!")
    (setq buffer-undo-list (unless (eq pending-undo-list t)
                             pending-undo-list))))

I bind this to "C-+" (only available on a window system), which on US
keyboards is one key over from "C-_".  Then I use it instead of "undo" for
all the trivial mistakes I make, and when I really want to back out of one
thing and do another, and to undo (ha) the growth of the undo-list if it
acquires too many "redundant" entries on the end.  It doesn't precisely
address your problem, but I find that it simplifies things and so makes
undo less painful.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: REDO ?

[Richard Stallman]

    A while agao, we integrated an undo/redo function into Aquamacs,  
    because that's what users generally get in programs running on that  
    specific OS.

What is the user interface?

Re: REDO ?

[David Reitter]

On 24 Apr 2007, at 17:03, Richard Stallman wrote:

>     A while agao, we integrated an undo/redo function into Aquamacs,
>     because that's what users generally get in programs running on  
> that
>     specific OS.
>
> What is the user interface?

A-z `aquamacs-undo'   (similar to `undo-only')
A-Z `aquamacs-redo'
C-_ `undo'

A-z and A-Z the standard keys on the Mac. Note that A- is bound to  
the "command" key.

This is probably not something that can be done in GNU Emacs.

It would be nice if the region was restored by the revised `undo' (if  
the mark was active) (as a customization option). NB, that would  
interfere with selective `undo'.

Re: REDO ?

[Richard Stallman]

    A-z `aquamacs-undo'   (similar to `undo-only')
    A-Z `aquamacs-redo'
    C-_ `undo'

    A-z and A-Z the standard keys on the Mac. Note that A- is bound to  
    the "command" key.

    This is probably not something that can be done in Emacs.

That is true.

By the way, since Aquamacs ias a modified version of GNU Emacs, it
does come out of GNU.  Please do not constrast "GNU Emacs" and
"Aquamacs", because that would imply that only the former comes from
GNU, and would deny us credit.  It is very unfriendly.

REDO ?

[A Soare]

What do you think aboubt inserting a redo command for the next version ? (23)

For me it could be very useful.

Also,  every time when we press undo or redo, to see (optionally) in the minibuffer the current change in yank kill, and the previous, and the next.


What do you think?

Alin Soare.

Re: REDO ?

[Stefan Monnier]

> What do you think about inserting a redo command for the next version ? (23)
> For me it could be very useful.

Yes, it's pretty much on my todo list.  Note that we already have "redo",
just not as a command.  The current way to do "redo" is to use the command
"undo".  The only difference is that if the last modification was not an
"undo" the undo command will not fail (as "redo" would) but will simply undo
instead.  Also if the last command was an "undo", the undo command will keep
undoing instead of doing a "redo" (i.e. undoing the last undo).

> Also, every time when we press undo or redo, to see (optionally) in the
> minibuffer the current change in yank kill, and the previous, and
> the next.

I do not understand.


        Stefan

Re: REDO ?

[Richard Stallman]

I think it is a bad idea to have a separate redo command,
simply because there is no room on the keyboard for a
convenient one, and an inconvenient one won't do much good.

Re: REDO ?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> I think it is a bad idea to have a separate redo command, simply
> because there is no room on the keyboard for a convenient one, and
> an inconvenient one won't do much good.

C-u C-/ could switch directions between undo and redo.  Something like
that.

-- 
David Kastrup

Re: REDO ?

[Richard Stallman]

    C-u C-/ could switch directions between undo and redo.  Something like
    that.

People could try it and see how convenient it is.