Subject: [sup-talk] redo ideas

From: [email-masked] (Nicolas Pouillard)
Date: Mon, 27 Apr 2009 21:47:00 +0200

Excerpts from Mike S's message of Mon Apr 27 14:43:46 +0200 2009:
> I'm graduating in a few weeks, so I'll have some free time I can dedicate 
> to sup again.
> 
> Recently redo functionality was suggested, I believe this was meant to be 
> a solution for something, but I have been thinking about it for a while.
> I'd like to register Ctrl-R to keep with the vim bindings.

Just some thoughts about this... I was more thinking about the repeat feature
of Vi/Vim (the '.' command) than the redo one.

Two other ways of doing the undo/redo:

1/ Save the actions using a data type that we can inverse.
   Example in Ruby syntax
   a = Action.add_labels(:foo, :bar)
   a.apply # actually do the job
   a.invert # equals to Action.remove_labels(:foo, :bar)

2/ Save the state (has to be defined) at each action.
   This solution would be limited to actions where the state is manageable.

Best regards,

-- 
Nicolas Pouillard

---

From: [email-masked] (William Morgan)
Date: Wed, 29 Apr 2009 11:22:41 -0700

Reformatted excerpts from Mike S's message of 2009-04-27:
> I'm graduating in a few weeks, so I'll have some free time I can
> dedicate to sup again.

Congrats! Great!

> I'd like to register Ctrl-R to keep with the vim bindings.

Sure.

> Ugly method 2: write code in duplicate, register a redo and call redo
> This saves duplication of code, but it seems unnecessarily complex.
> 
> * create undo lambda
> * create redo lambda
> * register undo and redo, but 'queue up' redo
> * UndoManager.redo

Redo is actually a slightly different operation from do. Do has to ask
for user input (what label do you want to apply?), redo just reuses it.
Maybe that's not such a big deal though; do/redo can just check to see
if it already has the value from the user, and ask if not.

> Slightly clever method: have primitives return their own undo/redo.
> This can be seen in toggle_starred where actually_toggle_starred
> returns its inverse. This shifts the complexity down and keeps higher
> level code clean.

That sounds eminently reasonable to me.
-- 
William <wmorgan-sup at masanjin.net>