Merging of changes: targeting a change

Do you want to request a feature or report a bug?

discussion

So…?

I will try to explain the issue with an example I am currently dealing with: uploading an image

There are three states the editor can be in.

1. Before, without the image
2. Showing the image while it is uploading (including a progress bar)
3. After, with the image uploaded

In order to provide correct undo behaviour, we have to change the history stack between states 2 and 3.

From state 1 to 2: When entering state 2, the history stack should push an insert_block op so that whilst we are uploading, undo will abort uploading and give us state 1 again.

From state 2 to 3: When entering state 3, the history stack should be modified so that undo will result in state 1. To achieve that, ops must be merged into a previous change.

Edge case 1: between state 2 and 3, the user can perform other operations (like insert_text, etc.), hence merging in this case must occurs not at top level of the stack, but somewhere below. We must somehow target a given change (array of ops) and merge into that change, modifying the history accordingly.

Get to the point, you fool

My question is, how can we possibly achieve edge case 1? Namely, target a change that has happened in the past and merge new operations into that change so we get the desired history?

Any ideas?

[ianstormtaylor]

This is something that I’ve wrestled with. The simplest solution I think I’ve come to, is to only have two states. And instead of inserting a “placeholder” block, don’t actually insert anything until the image is fully uploaded and insertable.

This can be communicated differently in the UI. Maybe with the upload indicator in the bottom corner or something. Or if you don’t need interstitial editing, then in a modal.

One of the reasons for doing it this way is if you’re doing collaborative editing, it’s strange for a 2nd user to randomly see a big “placeholder” jump in without any content in it. Better to just only have the image show up once it’s fully loaded. And then the history is a lot easier to manage.

[bryanph]

Well I resolved this by implementing @ianstormtaylor’s recommendation, so I’ll just close this.