Focus on Newly Created Method/Class in "Create Method" Quick Fix

[mamilic]

Description:
The "Create Method/Class" quick fix in VSCode Java is a highly useful feature—thank you for including it! I wanted to suggest an improvement to enhance its usability further.

Request:
When a user selects the "Create Method" or "Create Class"quick fix, it would be helpful if the newly generated method automatically became the focused view. This would allow users to immediately start editing the new method, without needing to scroll to find it manually.

Benefit:
By setting focus on the newly created method/class, developers can seamlessly continue their workflow, especially when working in larger files where locating a new method/class can take additional effort.

Thank you for considering this feature enhancement!

[rgrunber]

Yeah, this has bugged me a bit, particularly when triggering something that creates a new method. I could see it both ways though. For example, sometimes I want to just create a class/method, and deal with it later, but I don't want to be taken away from my current context.

For "create method", we actually started treating them as snippets, since VS Code allows us to do this and because there's many different "parts" of the newly created method declaration that you may want to quickly modify. The result is you should be able to tab through to the actual declaration. See https://idetools.dev/blog/dynamic-proposals/ .

I also notice that the Typescript support has the same issue, so it almost seems like this is some kind of setting VS Code itself should be providing to have it configurable.

[mamilic]

Hi @rgrunber , your point is actually good. As you mentioned, not everyone would want to navigate to the created method every time. However, is there a possibility to set an action that defines this behavior? For example, if a class or method needs to be created and opened in focus, maybe a shortcut like 'CTRL+Enter' could be set, or even defined by the user. If the user wants to stay on the current screen and handle it later, they could just press 'Enter.' I'm not sure if this is technically possible

[rgrunber]

Now that I think of it, I think we could probably have a workaround for this as well. Looking at the LSP spec for code actions : https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeAction . Specifically :

/**
 * A command this code action executes. If a code action
 * provides an edit and a command, first the edit is
 * executed and then the command.
 */
  command?: Command;

In fact, we already do something like this at

vscode-java/src/clientCodeActionProvider.ts

Lines 19 to 31 in 2cd1c83

	provideCodeActions(document: TextDocument, range: Range | Selection, context: CodeActionContext, token: CancellationToken): ProviderResult<(CodeAction | Command)[]> {
	const codeActions = [];
	if (context.diagnostics?.some(diagnostic => diagnostic.code === UNDEFINED_METHOD)
	|| document.lineAt(range.start.line)?.text?.startsWith("import ")) {
	const action = new CodeAction("Configure static import...", CodeActionKind.QuickFix);
	action.command = {
	title: "Configure static import...",
	command: configureStaticImportsCommand,
	};
	codeActions.push(action);
	}
	return codeActions;
	}

where we modify the behaviour of a code action (we create) to perform some other operation (bring up the settings page).

I think for this to work, all we would need to do is detect any code actions (from the language server response) that we know would create a new file, and simply add the command Commands.OPEN_FILE in that code action. For a newly created member in the same file, we could try workbench.action.gotoLine as the command. The file/line info should be there in the code action data.

The only downside is I think a code action can only have one command, so if we're already using a command for a code action that creates a new file / member, it might get complicated to support multiple commands.

Update: I just realized, we do have instances where we already set a command for code actions. For example, "change method signature", many of the "Extract ..." refactorings. This is mainly because they're implemented by returning a command ID that the client can use to send all the parameter data back to the server to get the text edit based on what the user selected in the UI. Given this, implementing the feature would involve some extra work to support multiple commands.