On Fri, Oct 28, 2011 at 11:36 AM, Aryeh Gregor <a...@aryeh.name> wrote:
> On Fri, Oct 28, 2011 at 12:59 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > > I don't want string because then I'd have to do: > > if (mode == 'reapply') > > instead of > > if (isReapply) > > and the former is much more verbose. > > It's a few extra characters. I really think the increase in clarity > is worth it. Boolean parameters are much more confusing, and should > be avoided wherever possible. > +1. I'm also OK with the argument if it's a string. > > That won't work for a collaborative editor because undo/redo may need to > > make DOM changes other than just restoring DOM states. For > example, changes > > made by other users can't be undone/redone by the local user, and those > > changes may also have mutated the highest node affected by automatic > > transactions. And authors still want to be able to sync the list of > > undo/redo items with UAs (e.g. to enable "undo" item in "Edit" menu). > > Okay, good. That's another use-case. I think it would be helpful if > you added these use-cases to the spec so that it's easier to see why > it's designed the way it is. > > Now I suggest that automatic transactions behave as I described, also > running reapply/unapply but undoing any DOM changes they do. Thus for > things like tracking canvas state, the author can still use them > safely. For collaborative editing, I suggest that we avoid the > problems due to mixing manual and automatic transactions by making it > per-UndoManager instead of per-transaction. So instead of an > isAutomatic property for transactions, have methods on UndoManager, > maybe enableManualTransactions() and disableManualTransactions(). > Then when one of these is called, clear the transaction history. That > way, we don't have to worry about undefined behavior when manual and > automatic transactions are mixed, and we still satisfy all use-cases. > Collaborative editors won't want to use automatic transactions, right? > Another use-case: a (possibly collaborative) slide editor (e.g. Google Presentations). Imagine that each text box in a slide is a contentEditable. You want adding/removing textboxes and/or slides to be manual transactions, but actual text editing in the text boxes to be automatic. And you want all this in the same undo stack.