Fill in package for newly created file

[jrieken]

When creating a new file, e.g Foo.java inside the com.mycomp.app-folder then the extension should use the new vscode.workspace.on[Will|Did]CreateFile-api to fill in some default content, esp the package-declaration package com.mycomp.app etc.

Environment

• Java extension pack 0.8.1

Steps To Reproduce

1. Use the vscode file explorer to create a new file

Current Result

File is empty

Expected Result

File should be pre-populated

[akaroml]

@testforstephen will adopt this.

[testforstephen]

From the API documentation, the file events could be from file explorer, or workspace.applyEdit-api.

If the new file is created from file explorer, it makes sense to pre-populate some contents based on the context.

But if the new file is from workspace.applyEdit operation, and populating some contents by the client watcher is probably not a good choice. Generally the applyEdit operation is from quick fix or refactoring, where the workspace edit would contain both file changes and text changes on the same file. And the client just watched that a new file is created, and then adding contents immediately will cause duplicated contents added to the target file.

For example, the Java extension provides a quick fix to create the missing type, where the workspace edit will contain an operation to new a file and a text edit to populate the class contents. The client doesn't need do anything for this file create event.

There are similar issues on the rename event. When an user is renaming a class name from the symbol, the Java extension will return a workspace edit to rename its Java file too. It's unnecessary for the client to watch such events to do something.

// @jrieken
My question is whether VS Code API allows me to only watch the file events from file explorer?

[jrieken]

No, you cannot know what triggered the event. Still, when using onDid-events then the first round of edits have already happened. E.g a refactoring has already finished and your listener can check the newly created files before sending off another edit, e.g only add the package-statement when the file is empty

[testforstephen]

this is the ideal situation, but the actual sequence won't support that.

See the sequence i observed:
-> Apply quick fix to add the missing type
-> onDidCreateFiles event
-> didOpen
-> didChange

So at the onDidCreateFiles event, actually the language server didn't receive the previous edit change yet, so cannot tell the file is empty.

[jrieken]

See the sequence i observed:

You can "change" the sequence by opening the document while handling the event. The onDid-event doesn't wait for you and it can use these files just as hint as way of "this file has been created, keep this in mind and fill in default when I know more and when it makes sense"

[testforstephen]

ok, thanks. I managed to exclude non-empty new files via workspace.openTextDocument(uri) api during workspace.onDidCreateFiles handler.

Now regarding to the rename events, it's a little complicated.

• If it's file name rename operation, then it's workable to update the main class name in the workspace.onDidRenameFiles listener.
• But if it's a file move operation (e.g. move class from package a to package b), the references (e.g. imports) update calculation need be done before the actual move happens. We may have to use workspace.onWillRenameFiles listener for the file move case. For this scenario, it seems hard to distinguish the event trigger between the file explorer and applyEdit. Are the text changes in the first round of applyEdit visible to the onWillRenameFiles event? // @jrieken

[jrieken]

For us, rename and move are the same. So, I don't know how you would differentiate between them?

Are the text changes in the first round of applyEdit visible to the onWillRenameFiles event

Not sure what you mean? Are you concerned that you could have caused the move and that there is nothing that needs to be done? Is there a "move to new folder" refactoring or how does this happen?

[testforstephen]

I understand rename in VS Code is generic, it's just because our Java implementation uses different logic to handle them. Currently i will check whether the oldUri and newUri is in the same directory to tell it's a rename or move.

yes, the Java extension provides a "move" refactoring in the editor context. And when the menu is clicked, it will prompt a quick pick to tell user to select the destination, after that the language server calculates a workspace edit and apply the move operation. What i want is to exclude such kind of rename event in the client rename listener, because the move refactoring already contains both file rename and import update.

[jrieken]

Understood - we could add a reason or source property that tells you what caused the workspace edit, in the spirit of TextDocumentSaveReason or TextEditorSelectionChangeKind. That could tell you if an edit was caused by a user gesture or not.

[jrieken]

I have created microsoft/vscode#93470 for this

[testforstephen]

Cool. that's exactly what i want.

[fbricon]

Fixed:

When the project uses JDK 14, the proposals look different to accomodate for the different record content: