Vscode: WorkspaceEdit should support creating, deleting, and renaming of files

[dbaeumer]

• VSCode Version: 1.4

Languages like Java require that renaming the top level class needs to rename the file as well. Currently the rename provider doesn't allow me to do that.

[jrieken]

Yeah, maybe it's enough to enrich the WorkspaceEdit to allow renaming of files

[dbaeumer]

Agree. May be we should support create, rename and delete of files.

[gorkem]

@jrieken @dbaeumer I am looking at providing a patch to LSP and language-server-node for rename with file operations and move but without this API it is really hard to continue that work. Do you have an ETA for this one? Any way to prioritize this? /cc @egamma

[egamma]

@gorkem I cannot give an ETA, but it is on the backlog and it is on the radar for our next iteration plan.

[gorkem]

@egamma @dbaeumer Do you mind, if we propose a change to LSP and implement it for instance on Che as the reference implementation. I guess vscode can eventually catch up but it would provide the language servers implementors to something to work with.

[dbaeumer]

@gorkem no I don't as long as it doesn't beak existing clients. However it would be nice if you could implement this for VS Code :-). It shouldn't be too hard.

[jrieken]

Work has started on this, maybe Jan, surely Feb

[jrieken]

That's the new methods we have added on WorkspaceEdit

        /**
         * Renames a given resource in the workspace.
         *
         * @param from Uri of current resource.
         * @param to Uri of renamed resource.
         */
        renameResource(from: Uri, to: Uri): void;

        /**
         * Create a new resource in the workspace.
         *
         * @param uri Uri of resource to create.
         */
        createResource(uri: Uri): void;

        /**
         * Delete a given resource in the workspace.
         *
         * @param uri Uri of resource to delete.
         */
        deleteResource(uri: Uri): void;

        /**
         * Get the resource edits for this workspace edit.
         *
         * @returns A shallow copy of uri-tuples in which a rename-edit
         * is represented as `[from, to]`, a delete-operation as `[from, null]`,
         * and a create-operation as `[null, to]`;
         */
        resourceEdits(): [Uri, Uri][];

        /**
         * Get all edits, textual changes and file changes. The order is the order
         * in which edits have been added to this workspace edits. Textuals edits
         * are grouped and the first textual edit for a resource matters.
         *
         * @returns A shallow copy of all changes.
         */
        allEntries(): ([Uri, TextEdit[]] | [Uri, Uri])[];

[jrieken]

Unfortunately testing un-covered too many issues, esp. in the rename and deletion paths. We decided to pull back for January to finish this in February.

[jrieken]

All issues can be found here: https://github.com/Microsoft/vscode/issues?q=is%3Aopen+assignee%3Ajrieken+label%3Aworkspace-edit. Technical challenge is an incomplete file service and some laying problems with the text file service

[DanTup]

@jrieken Is this still on track to be done this month? I haven't looked at it yet, but if you think it's good to go I have a bug that I can fix with it so I'd be happy to test it out in insiders.

[jrieken]

Sorry, will slip as I have been on vacation until today...

[DanTup]

No worries, thanks for the update!

[jrieken]

Because our underlying services are too limited (and at the wrong layer) this will take longer than anticipated. We have not planned this for March

[DanTup]

@jrieken I don't suppose this is on the table in the near future?

[jrieken]

maybe may

[jrieken]

The underlying blockers have been fixed and we can now go ahead with this

[mjbvz]

@jrieken I've hooked up TS to use the new API with 7c96862d379b21d3fe603f34f3daf6f60d8c1ca7

One small complication: TS doesn't tell us which files need to be created so I believe the code still has to use openTextDocument to check if the file exists first. Not sure if this problem is common enough for us to worry about with our API

[jrieken]

TS doesn't tell us which files need to be created so I believe the code still has to use openTextDocument to check if the file exists first

Yeah, I stumbled over that when looking into how TypeScript uses this and I have an item on my todo-list. One option would be to ignore files that already exist. However that might violate your assumption about the file being empty... Alternatively, we could expose more options on the create-call, like { overwrite: boolean } with similar semantic as FileSystemProvider.writeFile...

[jrieken]

@mjbvz I have added an ignoreIfExists option which will skip create requests for files that already exists. I have have also added an overwrite option but that will throw when the file already exists.

[jrieken]

Moving to Juli for api finalisation