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

[Jonas Sicking]

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?

/ Jonas