Throttle save participants when low auto save delay is configured to allow for undo

[rebornix]

• VSCode Version: 1.48-Insiders
• OS Version: macOS

Steps to Reproduce:

1. Turn on files.insertFinalNewline
2. Open a file which has more than 1 line
3. Select all, type a
4. Try undo, it will never bring back the original data

Ran into this issue twice today when I was typing really fast and replaced several lines with random characters by mistake and then lost all my work.

Does this issue occur when all extensions are disabled?: Yes

[jrieken]

Doesn't reproduce for me...

[rebornix]

I have auto save on and its delay is 100ms, even though I tried to press CMD+Z real fast, it still

• Undo the insertFinalNewline
• Document saved
• insertFinalNewline is executed again
• Insert another insertFinalNewline into the Undo stack

Then I got stuck. Workaround for me is slowing down the auto save but it's still bad.

[bpasero]

I can reproduce but I cannot see how to fix this easily given autosave is at 100ms? Here is what seems to happen:

• you undo once
• the final new line is removed
• auto save kicks in and adds the final new line
• you undo again
• the final new line is removed
• ...and so on...

You could only go back if you managed to undo faster than auto save kicking in, right?

One possible solution maybe on the editor would be to merge the undo stack into one, e.g. the change the user did and the result of the save participants become one operation? Though that might cause a lot of issues when people want to undo the result of a formatter...

[jrieken]

Though that might cause a lot of issues when people want to undo the result of a formatter...

Yeah, we code in place to make sure that automagically made edits are in one undo stack which is separate from manual edits.

Wouldn't be a simple fix to put a lower-cap on the auto save timeout? For instance it doesn't get faster than 700ms or so? It's like the font size which doesn't go below 6

[bpasero]

Yeah we can put a cap as last resort, but then again maybe people really rely on save kicking in instantly. Two more ideas:

Cap auto save when undoing
Essentially, when you are undoing, auto-save will run only at 1s minimum to allow the user to undo.

Do not run save participants when undoing
Do not run any save participants when you are undoing. In other words, as long as the version of the model is from a state in the past, no participants would trigger until you type again. Could be a breaking change in behaviour though because it allows to get the model into a state where save participants did not have a chance to run, so it is very dangerous.

[bpasero]

Pushed the following fix:

• remember when the model content was changed from a undo/redo operation (that information is carried via model content change event)
• measure the time it took from such an operation until auto save triggers (only auto save, explicit save will not be throttled ever)
• if that time is below 500ms, delay the save operation until 500ms is reached

This should give a user a chance to trigger the undo command repeatedly, provided the user can do that multiple times below 500ms each.

[rebornix]

@bpasero thanks for the quick turnaround! I set the delay to a low number as I wish to see errors/warnings from build task as soon as possible, the solution is reasonable as whenever I found cmd+z not working, I try to cmd+z a couple of times more so the 500ms delay can solve this problem.