Support onDidExecuteCommand

[waderyan]

I am building an extension for VS Code. My extension will show the key bindings associated to a recently action (I am a fan of this for helping me learn key bindings).

Looking through the documentation there seems to be a way to access the commands in the editor, but no way that I can find to listen for actions / commands as they are invoked.

I would like the ability to listen for all user actions and then react to their actions.

[egamma]

This is currently supported by calling this method:

vscode.commands.getCommands(filterInternal?: boolean): Thenable<string[]>;

Does this unblock you?

[waderyan]

Not quite. From what I can tell in the docs, this function will return a list of commands. What I want is to listen to commands as they happen.

My specific use case is:

• Listen for commands
• When command occurs, determine if their is a key binding for that command
• Display in the status bar (or some UI element) the key binding for the command the user just executed.

[egamma]

Got it, this is currently not supported.
@jrieken fyi.

[siegebell]

I would also like to see this feature.

I am writing an extension that needs to monitor cursor movements and make slight cursor position adjustments on occasion. The only way I've found to do this is to override the keybinding for e.g. 'left', call 'cursorLeft' from my command, and then validate the cursor's position.

Even without validation, intercepting 'left' and then immediately calling 'cursorLeft' from an extension causes the UI to be much less responsive than binding directly 'left' to 'cursorLeft'. (Because extensions are given low priority.)

[jrieken]

@johnfn for the VIM extension do you need onDidExecuteCommand, or onWillExecuteCommand, or both? The first (onDidExecuteCommand) is fairly easy to implement but the latter raises many questions...

[johnfn]

@jrieken I assume this is for tab complete? If so, post-trigger would be the most useful.

[rebornix]

@jrieken we will benefit a lot with onDidExecuteCommand, for example, code snippet then we know how to handle those selections.

// Remove words which are wrong.

[jrieken]

@johnfn @rebornix not quite sure what you guys mean by 'Tab complete'?

[rebornix]

@jrieken A common user case is like:

1. User types ab in a TypeScript file
2. Code will suggest abstract
3. User press <Tab>, Code will do autocomplete and we will get abstract.
4. User press . to repeat previous action.

Since the only user does is pressing a, b, Tab but we have no idea about the final result of these three keystrokes. so when we repeat previous action, the result will be just another ab, which is not what we want. The reason that we don't get <Tab> is we are listening to type command and <Tab> (Up, Down, Left, Right, etc) will not be passed to us.

So if we can bind handlers to onDidExecuteCommand and we know it's an autocomplete, maybe we can put it in our cached history and repeat correctly?

[alexdima]

@rebornix I am not convinced that "spying" on commands will help you in any meaningful way. For example, in the example you make, where a user types ab followed by <Tab>, you will find out the command acceptSelectedSuggestion has executed.

But IMHO this does not help you to repeat the action, as the command acceptSelectedSuggestion is completely contextual. Perhaps the suggest widget has even closed in the meantime, so executing it programmatically will result in a no-op.

Perhaps . can be supported only for vim commands rather than for any command plugged into vscode? Would that be a vim adoption blocker?

[rebornix]

@alexandrudima Thanks for your input. I agree that acceptSelectedSuggestion execution doesn't solve this problem. But since we are only monitoring type command then we have no idea what's the exact content being inserted into the editor, we can't implement . perfectly.

. is a Vim adoption blocker as well as u (undo). Since you are enriching Code's undo/redo commands, will there be any additional info to help implement repeat?

[alexdima]

@rebornix My question stands: "Perhaps . can be supported only for vim commands rather than any command plugged into vscode?".

There are a lot of commands in VSCode out of the box and even more from extensions. Types of commands that I can think of:

• commands that edit the document: e.g. toggle line comment (ctrl+/ or cmd+/)
• commands that change the editor "view" state: e.g. actions.find (ctrl+f or cmd+f), find all references, show hover, toggle word wrap
• commands that change the workbench state: e.g. open markdown preview to the side, show references, go to definition, hide sidebar

There are also edits to the document that don't stem from a command (e.g. format on type)

The commands are not categorized statically in any meaningful way. They execute and they do something. Sometimes, that results in a document edit (that can be observed via onDidChangeTextDocument).

Also note the textEditor.edit API that is currently in place. The only information I get from that are the edits to be aplied to a text document, which are immediately reflected in onDidChangeTextDocument.

Is it possible to point me to an example/explanation of how . should work in Vim?

[johnfn]

The big thing we need is the ability to know that an action such as tab complete or snippet insert or any other sort of text change has taken place. If you guys can't figure out exactly how to let us repeat it, that's okay; we can just manually diff the document and figure out what happened (most of the time).

Quick explanation for .: The idea is that it allows you to repeat an action somewhere else in the document. So if you inserted some text on the first line, then navigated to the last line, . would add the text down there. If you tab-completed a word on the first line and hit . on the last line, it'd insert the full word. etc, etc. . only concerns itself with text-related actions.

[jrieken]

only concerns itself with text-related actions

Isn't that an argument for the TextDocumentChangeEvent? We could maybe enrich it with a source-thing - similar to TextEditorSelectionChangeEvent#kind. That would indicate (somehow?) that this textual change was done because of a command and the .-feature would then remember it for repeated execution

[alexdima]

@jrieken 👍 However, the source is currently a string (not an enum) and at least for edits coming from the extension host the source is set to MainThreadTextEditor -- see https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/api/node/mainThreadEditorsTracker.ts#L342

[jrieken]

As long as the strings being sort well defined we can do something like this

[jrieken]

@johnfn @rebornix I have extracted #10801 for the last bit of this discussion since this issue is still about events for command execution.

[jrieken]

Most (not sure if all) should be named _internal_command_delegation_TIMESTAMP, so in theory ignore _'ed command should work

[hedgerh]

Pushed up my work and opened up a RFC/WIP PR of what I came up with. Interesting enough, none of the internal commands actually go through the event emitter in the command service, so they don't surface on the extension side. I verified that internal commands were firing, just not through the emitters.

Interested if there are any performance implications with talking between the two processes like this. Possible enhancement would be to allow a glob/regex/array of strings/wildcard as the first param that would act as a filter for what events surface to the extension.

[jrieken]

This PR is merged but there is some little (design) work left

• revive/massage arguments
• decide if we should hide private/underscore commands
• deal with the internal command delegation commands
• add some more tests
• understand perf implications of sending arguments around

[jrieken]

Closing this for July testing

[alexr00]

This seems to work well, but I'm seeing the event get triggered twice when running this hello world command:

export function activate(context: vscode.ExtensionContext) {
	// Use the console to output diagnostic information (console.log) and errors (console.error)
	// This line of code will only be executed once when your extension is activated
	console.log('Congratulations, your extension "helloworld-sample" is now active!');

	// The command has been defined in the package.json file
	// Now provide the implementation of the command with registerCommand
	// The commandId parameter must match the command field in package.json
	const disposables: vscode.Disposable[] = [];
	disposables.push(vscode.commands.registerCommand('extension.helloWorld', () => {
		// The code you place here will be executed every time your command is executed

		// Display a message box to the user
		vscode.window.showInformationMessage('Hello World!');
	}));

	disposables.push(vscode.commands.onDidExecuteCommand((e: vscode.CommandExecutionEvent) => {
		console.log(e.command);
	}));

	context.subscriptions.push(...disposables);
}

The command isn't actually running twice, but the listener for onDidExecuteCommand does get called twice.

Bug: #78274

[jrieken]

We have decided against this API: #78091 (comment)