Motivation
JavaScript currently implements organize imports as a command. So does Java. Each extension also has its own keybinding for organize imports.
With common actions like organize imports that will be implemented by multiple extensions, we risk making each extension reinvent the wheel and possibly creating conflicts other extensions. It is already very easy to forget to properly scope your organize imports command when defining it, which may cause vscode to trigger the wrong language's organize imports for a file.
Proposal
Provide an API that allows extensions to register file-level actions, such as organize imports, in a standard way. VS Code can use this API to provide a standard keybinding for common actions such as organize imports, and also ensure that we correctly handle cases where multiple organize imports actions exist for a single file
Proposed Implementation
Leverage the existing CodeAction class to create the concept of a source code action. Introduce a new scope source.* scope to define source code actions.
We can then either leverage the existing CodeActionProvider api or introduce a new SourceCodeActionProvider class that allows extensions to return source code actions.
The expected ux in either case:
-
Do not show source code actions in the light bulb menu or when using the editor.action.quickFix keyboard shortcut
-
Provide a right context click menu that shows a list of all source code actions for the current file. Do not show an entry in this context menu if no source code action providers are registered for the file
-
Also provide a way to setup a keybinding for specific source code actions. This could either reuse the existing editor.action.codeAction command or introduce a new editor.action.sourceCodeAction command
@jrieken Let me know if you have any concerns or ideas about the proposal or implementation. We can also cover this at the API sync. Overall, I'm leaning towards reusing our the existing CodeActionProvider class for this. The main downside of this approach is that I don't think we could make the source context menu only show up if these is an actual source code action provider since we could not know whether a registered CodeActionProvider will returns source actions or not
Motivation
JavaScript currently implements
organize importsas a command. So does Java. Each extension also has its own keybinding fororganize imports.With common actions like
organize importsthat will be implemented by multiple extensions, we risk making each extension reinvent the wheel and possibly creating conflicts other extensions. It is already very easy to forget to properly scope yourorganize importscommand when defining it, which may cause vscode to trigger the wrong language'sorganize importsfor a file.Proposal
Provide an API that allows extensions to register file-level actions, such as
organize imports, in a standard way. VS Code can use this API to provide a standard keybinding for common actions such asorganize imports, and also ensure that we correctly handle cases where multipleorganize importsactions exist for a single fileProposed Implementation
Leverage the existing
CodeActionclass to create the concept of asourcecode action. Introduce a new scopesource.*scope to define source code actions.We can then either leverage the existing
CodeActionProviderapi or introduce a newSourceCodeActionProviderclass that allows extensions to return source code actions.The expected ux in either case:
Do not show source code actions in the light bulb menu or when using the
editor.action.quickFixkeyboard shortcutProvide a right context click menu that shows a list of all source code actions for the current file. Do not show an entry in this context menu if no source code action providers are registered for the file
Also provide a way to setup a keybinding for specific source code actions. This could either reuse the existing
editor.action.codeActioncommand or introduce a neweditor.action.sourceCodeActioncommand@jrieken Let me know if you have any concerns or ideas about the proposal or implementation. We can also cover this at the API sync. Overall, I'm leaning towards reusing our the existing
CodeActionProviderclass for this. The main downside of this approach is that I don't think we could make thesourcecontext menu only show up if these is an actual source code action provider since we could not know whether a registeredCodeActionProviderwill returns source actions or not