Make the undo history extendable #24

Closed
opened 2018-09-03 18:10:06 +02:00 by marijnh · 8 comments
marijnh commented 2018-09-03 18:10:06 +02:00 (Migrated from github.com)

So that custom code can introduce custom history events, that are applied as part of or between the history events created by editing

So that custom code can introduce custom history events, that are applied as part of or between the history events created by editing
schanzer commented 2018-09-04 04:10:54 +02:00 (Migrated from github.com)

An officially-supported way to add data to a history event would be extremely helpful, too. I’d love to be able to store some extra state when CM commits a change, and then get that state on undo/redo.

An officially-supported way to add data to a history event would be extremely helpful, too. I’d love to be able to store some extra state when CM commits a change, and then get that state on undo/redo.
arguiot commented 2019-05-04 17:27:09 +02:00 (Migrated from github.com)

Also, having a method to simply undo/redo something would be great, like having something like EditorView.undo().

Also, having a method to simply undo/redo something would be great, like having something like `EditorView.undo()`.
marijnh commented 2019-05-04 21:51:55 +02:00 (Migrated from github.com)

That already exists—just call the undo command exported from the history package.

That already exists—just call the `undo` command exported from the history package.
marijnh commented 2020-03-31 13:57:46 +02:00 (Migrated from github.com)

This has landed with state effects and the invertedEffects facet.

This has landed with state effects and the `invertedEffects` facet.
schanzer commented 2020-03-31 14:42:31 +02:00 (Migrated from github.com)

Are state affects what one might use to attach data to a history event?

Are state affects what one might use to attach data to a history event?
marijnh commented 2020-03-31 16:16:17 +02:00 (Migrated from github.com)

Yes, you model your actions as effects (which are attached to transactions), and register a handler that, given a transaction, produces the effects the inverse of that transaction should have. The history will store those inversed effects and replay them when the transaction is undone.

Yes, you model your actions as effects (which are attached to transactions), and register a handler that, given a transaction, produces the effects the inverse of that transaction should have. The history will store those inversed effects and replay them when the transaction is undone.
schanzer commented 2020-03-31 17:58:53 +02:00 (Migrated from github.com)

Fantastic. This is a critical feature of making code mirror usably accessible, instead of merely accessible.

Fantastic. This is a critical feature of making code mirror _usably_ accessible, instead of merely accessible.
robinplace commented 2024-01-20 06:27:29 +01:00 (Migrated from github.com)

for future reference, there is an example of this feature on codemirror.net.

for future reference, there is an example of this feature [on codemirror.net](https://codemirror.net/examples/inverted-effect/).
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
codemirror/dev#24
No description provided.