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

[Jonas Sicking]

On Tue, Aug 9, 2011 at 3:29 PM, Annie Sullivan <sullivan at chromium.org> wrote:
> 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.

We're talking about a line of code setting a single boolean flag.
That's not a whole lot of code. And for a very narrow usecase that can
hardly be considered the common usecase. I.e. wanting to display if a
change has been unapplied/reapplied, but not wanting to show any other
metadata about the change (such as who or when), in a collaborative
editor.

Any feature that is so easy to replace and is going to be used that
rarely I'd cut in a heartbeat.

It did sound like selection management could be a much stronger use case though.

/ Jonas