Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let features know about undo batch #2722

Closed
jodator opened this issue May 13, 2019 · 5 comments · Fixed by ckeditor/ckeditor5-undo#98
Closed

Let features know about undo batch #2722

jodator opened this issue May 13, 2019 · 5 comments · Fixed by ckeditor/ckeditor5-undo#98
Assignees
Labels
package:undo status:discussion type:feature This issue reports a feature request (an idea for a new functionality or a missing option).
Milestone

Comments

@jodator
Copy link
Contributor

jodator commented May 13, 2019

So I have an issue with undoing automatic text transformations. Scenario:

  • user types "woot"
  • feature replaces "woot" to „woot” (using a new batch)
  • users decides to undo change (CTRL-Z) to "woot"
    Now the feature does not know if that "data:change" event is for undoing batch. I can listen to undo command execution and filter out those batches but it looks like we could add another type of batch?

This is rather open discussion as I only know about: default and transparent type of batches ATM.

@jodator
Copy link
Contributor Author

jodator commented May 13, 2019

So after F2F talks with @scofalik we came to a conclusion that adding a batch type "undo" makes sense:

  • there's an actual need of other features to know about that change is coming from "undo" not user interaction
  • another solution for this problem looks less clean (ie checking if batch is in undo stack)
  • the redo should also have "undo" type - as in such scenario:
    1. user types "foo bar"
    2. text transformation changes to „foo bar”
    3. user undo (1): text becomes "foo bar" again
    4. user undo (2): part of text (depending on buffer) is removed: "foo
    5. user redo (1): the text should be "foo bar" (and no automatic transformation to be applied)
    6. user redo (2): the transformation i re-applied: „foo bar”

At the moment I see that undo type makes sense as

  • features might introduce other types of batch.
  • the undo batch will be present only with Undo plugin enabled
  • the batch type should be documented in feature description

//cc @pjasiun

@pjasiun
Copy link

pjasiun commented May 13, 2019

I'm fine with marking "undo" and "redo" batches as "undo" with a special flag.

@jodator
Copy link
Contributor Author

jodator commented May 13, 2019

batches as "undo" with a special flag.

@pjasiun: To be precise: batch.specialFlag = true or batch.type = 'undo' - the latter (batch.type=undo) was proposed here.

@jodator jodator changed the title Let features know about undo batch. Let features know about undo batch May 13, 2019
@pjasiun
Copy link

pjasiun commented May 13, 2019

After F2F talk we agreed that we can try to mark these baches as transparent.

@jodator
Copy link
Contributor Author

jodator commented May 13, 2019

After another F2F talk with @pjasiun & @scofalik we agreed on checking first if the undo feature shouldn't use transparent batches in the first place (instead of currently default).

@jodator jodator self-assigned this Jun 18, 2019
Reinmar referenced this issue in ckeditor/ckeditor5-undo Jun 27, 2019
Other: Use transparent batches in undo & redo commands. Closes #97.
@mlewand mlewand transferred this issue from ckeditor/ckeditor5-undo Oct 9, 2019
@mlewand mlewand added this to the iteration 25 milestone Oct 9, 2019
@mlewand mlewand added status:discussion type:feature This issue reports a feature request (an idea for a new functionality or a missing option). package:undo labels Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:undo status:discussion type:feature This issue reports a feature request (an idea for a new functionality or a missing option).
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants