Extension Development: Offer a way to "clear undos" for specific filesystem scheme(s) or document(s).

[boltex]

I know there exists an 'all-or-nothing" configuration option that prevents it globally (files.restoreUndoStack), but I would need a less drastic method for a better user experience so as not to force this setting globally on all files...

USE CASE:
My extension (https://github.com/boltex/leointeg) uses vscode's filesystem provider api to implement custom 'editors' for my needs, (a temporary scratch pad) as indicated in the documentation here https://code.visualstudio.com/api/extension-guides/virtual-documents#file-system-api .

I need to be able to 'block' or 'clear' undos when closing or switching from one of them to another. (e.g. resetting the scratchpad)

OLD WORKAROUND:
It used to be that doing vscode.WorkspaceEdit "rename" operation would 'clear' or 'block' all undos for the newly named document. And as such effectively prevented them to traverse across the point where the document was renamed. Which was a desired outcome in my use case.

But lately, the newer versions of vscode tries to uphlod undo operations past a 'rename' or 'save as new name"... This is problematic for when a clear document separation was intended with the 'rename' operation... More specifically: This new problematic behavior opens a document with the old name when pressing ctrl+Z on a newly renamed document (in a custom filesystem)... Is there a way to disable that? Or a way to clear the undo stack for a given document URL? or for a filesystem scheme only in particular?

PROPOSED SOLUTION(S):

• Provide a command, or a vscode.WorkspaceEdit action, to clear undo stack of a given document, or filesystem scheme.
• Provide a way to opt-out specific file scheme(s) from the 'persist undos across closed/renamed/saved' files behavior (similar to files.restoreUndoStack config option, but for specific schemes)
• Make an explicit side-effect of clearing the document history of a file that it also clears any undo stack associated with it, i.e. the vscode.commands.executeCommand('vscode.removeFromRecentlyOpened', p_textEditor.document.uri.path); command.

Thank you for your consideration!
Edit: typo

[boltex]

Addendum: I've discovered that the files.restoreUndoStack option that I refer in the opening paragraph, does not even apply for this issue. So this is a different side-effect for which my extension development is affected. (Requiring an option to clear the undo stack for a renamed/saved-as-new-name document) I just thought I'd mention this, as files.restoreUndoStack is not even an option I can use (or tell my users to use) as a possible workaround.
Edit:typo

[jrieken]

I need to be able to 'block' or 'clear' undos when closing or switching from one of them to another. (e.g. resetting the scratchpad)

I don't quite understand why switching requires to block undo?

[boltex]

Hi @jrieken, thanks for your concern!

My use case:

I need to 'clear' the undo stack in my case because undoing past the rename point makes no sense: It's another completely different content. (document).

See https://github.com/boltex/leointeg/blob/master/resources/animated-screenshot.gif (the first gif in the readme of my extension) I unflod some nodes, but also select some, which changes the content of the LEO:BODY text document. (fluidly, without closing/reopening)

Meaning that the switching, and rename operation, was used specifically for its side effect of clearing the undo stack. (So that issuing undo is possible, indeed, to 'undo' last modifications, but not past the rename point which is meant to 'switch' to another document - where it makes no sense that an 'undo' operation would "rename" back the file to its old name, - which is even worse! - and bring in old content back from the other file)

Other use cases:

I might add that many users 'spam' undos to make sure they have 'undone' everything and 'reset' a document to its starting state. Often times a 'rename' is done to ensure that a new document 'starting state' is created. (Say after a major breakthrough or a major commit/push) This is no longer possible since the last few updates of vscode.

Also, some issues for vscode about offering a 'clear undo' feature #100600 and #96601 bring the argument that : "When I finish some changes and commit them, I usually want to clear undo history so that I can start a new commit and not undo changes from previous commit by accident."

Although those issues have a different reason than mine to request the availability of a 'clear undo stack' functionality, I thought it would be a good idea for me to remind you of those in this request.

Please dont hesitate for more precisions, and thanks again for your time!

[boltex]

Addendum: Also, to comply with the spirit of data-loss prevention, I feel the need to mention that stopping undos past a particular point is not data-loss prone, it can be the opposite: When considering 'spamming' undos is used by people to confidently revert to a starting, or "boundary" point after an important code change, commit or other reasons, which is often intended to be set with a 'rename' operation.

e.g. A user which renames file-1.txt to file-2.txt sometimes intends to save the document with a different name to create another file and preserve the original, and the new one as a milestone... But also to clear the undo stack in the newly renamed document to prevent extraneous accidental 'ctrl-z' undos presses.

Although it is not my particular use-case reason, I felt the need to give this additional reason for a 'clear undo' functionality for a given document.

Thanks again.

[jrieken]

The undo stack cannot be modified for selected resources as it might create inconsistencies. For all what we know, another extension might have created an edit that spans across your file system and another file system and we simply cannot ignore half of the edits.

It's another completely different content. (document).

Why don't you then create a new document and delete the old one?

[boltex]

As seen in the first gif of the readme, at https://github.com/boltex/leointeg , selecting a node in the tree (where the 'app' node is selected, then 'test maths and physics' and lastly 'test canvas') instantly shows the changed content in the LEO:BODY editor.

Why don't you then create a new document and delete the old one?

Because then I would lose all U.I. fluidity, (and 'mirroring' of other views into the same file, and column of the opened editor, etc.) if opened in more than one panel.

Meaning that if the document is opened, it would visibly close, and then re-open to show the new content. if more than one instance of the document is opened, then they both would close, and only one would re-open by default... breaking all fluidity and consistence.

Maybe I should re-phrase my intentions as to not mean an 'undo stack clear' for a document, but in fact ask for a way to set an editor's status to mean : "This is a new name and a fresh new file without closing the editor and it's mirrored views". This reasoning also applies for #100600 and #96601 .

I understand the undo stack cannot be modified in ad-hoc manners for the reason you stated above, but I think something like a simple, optional, state of 'fresh file' upon renaming would be reasonable... Obviously i'm not the expert on vscode's huge code base ! :)

On the other hand, perhaps you could tell me if there's a way for extension developers to use an editor - and its "mirroring" (other views of the same file), to change, all at the same time, to another document? (i.e. "reassigning" text-editors to another document) like i'm doing in the gif previously mentioned?

Thanks for your time and attention! It's very much appreciated!!

Edit: typos

[vscode-triage-bot]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!