[whatwg] Fixing undo on the Web - UndoManager and Transaction

[Annie Sullivan]

On Tue, Aug 9, 2011 at 6:25 PM, Jonas Sicking <jonas at sicking.cc> wrote:

> On Tue, Aug 9, 2011 at 2:59 PM, Annie Sullivan <sullivan at google.com>
> wrote:
> >
> >
> > On Tue, Aug 9, 2011 at 4:59 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> >>
> >> On Tue, Aug 9, 2011 at 12:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> >>
> >> > On Tue, Aug 9, 2011 at 1:17 AM, Jonas Sicking <jonas at sicking.cc>
> wrote:
> >> >
> >> >> On Tue, Aug 9, 2011 at 12:42 AM, Ryosuke Niwa <rniwa at webkit.org>
> wrote:
> >> >> > On Tue, Aug 9, 2011 at 12:31 AM, Jonas Sicking <jonas at sicking.cc>
> >> >> wrote:
> >> >>  >> Likewise I still haven't heard of any examples where the
> >> >> apply function
> >> >> >> isn't simply init+reapply. So it still seems better to me to have
> a
> >> >> >> init/apply/unapply split rather than a apply/reapply/unapply
> split.
> >> >> >
> >> >> > This is also pending for developer feedback.
> >> >>
> >> >
> >> > I've talked about this with Alex, and we both agreed that having
> >> > apply/reapply split is cleaner because in many cases you'd like to
> know
> >> > whether you're in redo or not.  i.e. more work is done in reapply than
> >> > in
> >> > apply.
> >> >
> >>
> >> Could you please provide examples. I feel like I'm fighting an elusive
> >> shadow.
> >>
> >> I.e. please provide an example where "apply" isn't just init+reapply.
> >> "There
> >> are many cases" isn't a particularly compelling argument unless you can
> >> show
> >> these cases :-)
> >>
> >> And ideally also some estimate how common that case will be compared to
> >> "apply" simply being init+reapply. This is important since if that is
> very
> >> rare, people can always implement it themselves using init+reapply
> >> semantics
> >> by having a flag on the object which indicates if you're in the first
> call
> >> or not.
> >
> >
> > As an author, I would really love to have as much information as possible
> > about what the user was trying to do. I might want to keep my own
> > bookkeeping about what is going on in the document, in some other format
> > besides HTML.
> > For example, if I were writing a collaborative editing app, and I decided
> > that any user could unapply/reapply any change, I might end up with a
> > sequence like this:
> > Susan made change X
> > Bob unapplied change X
> > Susan reapplied change X
> > Bob unapplied change X
> > Susan reapplied change X
> > ...
> > It would be great to show that in the document history view of my app
> very
> > clearly. I think knowing that a change was unapplied/reapplied instead of
> > just showing text diffs between revisions would be great.
>
> I'm not quite sure I understand what API you are arguing for and how
> that API would help you.
>
> If you're wanting to show that a change was unapplied/reapplied,
> wouldn't you also want to show who did the unapply/reapply? In that
> case you'd have to do your own book keeping anyway, no?


Yes, if you're keeping additional metadata, you have to do your own
bookkeeping, but it's much easier to get the info about whether the change
was applied or reapplied if the API is set up so that you have an
apply/reapply instead of init/apply.

>