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

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

@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

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

@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.

@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.

Work has started on this, maybe Jan, surely Feb

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 I've hooked up TS to use the new API with 7c96862

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

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...

@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.

Moving to Juli for api finalisation