-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provided mapping from vscode command ids to internal command ids #5590
Conversation
This is a master list of all missing vscode commands from the vscode keybinding page that this PR provides. A 1 in the registered correctly column means the internal command id representation is the same as vscode api's (and thus nothing needs to be done because its already correctly registered). A 0 or nothing means that there is no command with that command id. A 1 in the forwarded in plugin column means that the vscode command is is mapped to an internal theia command id. A 0 or nothing either means that it doesn't need to be mapped or an internal theia command doesn't exist.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Due to the fact we have to map vscode commands to internal theia commands, attempting to add in something like editor.action.formatSelection into keymaps.json will not work because keymaps.json expects that command to be monaco.editor.action.formatSelection.
It sounds fine to me since we are trying to develop the Theia platform, adding VS Code support. So it makes sense that our services expect our own structures. Now if we happen to load keybindings / commands from an external source, the mapping as you've done is perfect (in case we ever parse an actual keymaps.json coming from VS Code, in this case we could benefit from what is done here by having a parser doing the mapping).
- Finding the vscode command in the keybindings widget will fail because theia's internal command id would be monaco.editor.action.formatSelection rather than editor.action.formatSelection.
Dependency-wise, I'm not sure we should make the keybindings extension depend on the plugin-ext, so it goes along what you are saying: It would be hard to have an inverse lookup. But then again, why would someone using a Theia application look for the VS Code ids? Unless we were to change each command to match VS Code, but I don't know what kind of issues that would bring or if it is something we even want to do.
It is a bit unfortunate that we have to do such a mapping, but it sounds like the best solution :)
* Copyright (c) Microsoft Corporation. All rights reserved. | ||
* Licensed under the MIT License. See License.txt in the project root for license information. | ||
*--------------------------------------------------------------------------------------------*/ | ||
// copied from https://github.com/microsoft/vscode/blob/master/src/vs/workbench/api/common/extHostTypes.ts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We require a CQ for the copied code.
https://github.com/theia-ide/theia/wiki/Registering-CQs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you have to be an official commiter in order to register a CQ? Following the document linked, I login and go to the project page but there isn't anywhere that says intellectual property or create a contribution questionnaire
@JPinkney we should be able to parse keybindings from VS Code. It would be fine with me to register Monaco command twice as you suggested before, if there is no way to get rid of Very cool that you sorted out generic transformation between monaco and vscode APIs. Did you test it with code lenses? Could you provide how you test it? |
@vince-fugnitto @marechal-p @akosyakov what do we need to do to move this PR forward? File a CQ? |
Yes, I believe a CQ should be registered for the copied code (only a committer can successfully register a CQ), the conflicts should be addressed, and perhaps document in the PR's description on how to test the PR? I think the only thing reviewers have done for the moment is to look at the source code. |
@tsmaeder rebasing and providing Also please file an issue that we should be able to parse VS Code keybindings, i.e. without |
@vince-fugnitto @akosyakov @JPinkney
|
@tolusha that's cool, but PR needs rebase and explanation how to test from the user perspective. As far as I understood for a user there are 2 issues should be solved: (1) now a command can be triggered from code lenses and (2) custom keybindings can be used. Is it right? I assume @JPinkney used some VS Code extensions to ensure it. It would be good to share it to speed up review. |
@akosyakov Yeah! You can do that, ping me when you're done and i'll test |
@akosyakov @JPinkney is not shirking responsiblity, but got shanghaied into doing some OpenShift related work. |
fe30277
to
cf6b330
Compare
I'm very busy this week. @eclipse-theia/eclipse-theia Could someone help testing it?
|
I am trying to test this pull request with the typescript VS Code extension. Could Anton @akosyakov or someone kindly provide me some guidance on how to uninstall native Theia typescript extension ? Thank you in advance ! |
You can remove the |
@JPinkney Could you remind pleas why cannot we drop |
@akosyakov In the PR it is registering without monaco prefix as well: https://github.com/eclipse-theia/theia/pull/5590/files#diff-3e78733f92a6f6b63b219e5fec2097f6R55 and then it hides anything with the monaco prefix in the keybinding view. From what I understood we had to keep the monaco prefix because other extenders of theia might be using it? |
We can ask extenders to drop monaco prefix. It was more to avoid changing core and monaco extensions, only apply changes to the plugin system. But since we cannot avoid it, i wonder can we just drop monaco prefix? Otherwise we introduce for example an implicit dependency from core to monaco by checking kebindings. There are excluded commands which should not be registered. I think we should keep it like is but rather than that rest of monaco commands can be registered only without a prefix. |
Typescript VS Code extension works better with this PR 🎉 I can use refactoring code actions. I have issues with keybindings:
|
e0fb066
to
41df06c
Compare
@JPinkney let me know when it is possible to test again. I see that tests are failing. Please also search through the repo for command invocations with |
41df06c
to
d266d81
Compare
@JPinkney is it good now for testing? there seem to be some conflicting files |
d266d81
to
8efa9fc
Compare
@akosyakov Just fixed the conflict, should be good to test now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super strange, the old keybinding still works. I've tried to give a different keybiding for rename symbols and format document.
@@ -273,7 +274,7 @@ export class MonacoEditorCommandHandlers implements CommandContribution { | |||
} | |||
protected newMonacoActionHandler(action: MonacoCommand): MonacoEditorCommandHandler { | |||
const delegate = action.delegate; | |||
return delegate ? this.newCommandHandler(delegate) : this.newActionHandler(action.id); | |||
return delegate ? this.newDelegateHandler(delegate) : this.newActionHandler(action.id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not seem that newCommandHandler
is used anywhere else. Should not we just change it?
Oh, I suspect the issue is that no keybinding matches in our registry, so then the default Monaco keyboard handler is called. 🙈 We should replace Monaco keybinding service with the null implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is good. The issue with calling default Monaco keyboard handler if our registry does not have such keybinding is present on the master as well.
@JPinkney could you file a follow-up issue for it? I will explain on the issue how to fix it.
Adding a record to CHANGELOG with a breaking change that |
Signed-off-by: Josh Pinkney <joshpinkney@gmail.com>
8efa9fc
to
4495b30
Compare
What it does
This PR introduces mappings from vscode command ids to internal theia commands ids as part of #5113 and #4247.
All commands listed here that are not registered under vscode's command id but instead have a command id native to theia are mapped. E.g. workbench.action.files.saveAs is mapped to file.saveAs so that when an extension calls workbench.action.files.saveAs the command that actually gets executed is file.saveAs.
However, there are still a lot of commands missing that either don't have an internal theia command that is relatable or don't have an implementation at all.
Also, when commands are being registered inside of plugins, vscode command ids must be mapped to their corresponding internal command id so that when you use that keybinding it understands to use the mapped internal command id rather than the vscode command id. This is because without the mapping the keybindings thinks that it should execute editor.action.formatSelection which doesn't have a registered handler, rather than monaco.editor.action.formatSelection which does have a handler.
After looking into multiple approaches on how to solve this problem this seems to be the best approach I can find. However, there are some shortcomings to this approach:
Due to the fact we have to map vscode commands to internal theia commands, attempting to add in something like editor.action.formatSelection into keymaps.json will not work because keymaps.json expects that command to be monaco.editor.action.formatSelection.
Finding the vscode command in the keybindings widget will fail because theia's internal command id would be monaco.editor.action.formatSelection rather than editor.action.formatSelection.
As far as I could find, this is the best solution that is doesn't change core or break any existing theia extensions.
How to test
Install vscode-java, alphabotsec.vscode-eclipse-keybindings
Then clone git@github.com:JPinkney/Theia-Extension-Test-Repo.git
How to test execute commands:
Set "java.referencesCodeLens.enabled": true
Open 'helloworld.java'
From the command pallete run 'open Java language server log file'
From within that java file test references
Then start the hosted instance on the cloned project and run
Test by commenting this line
from the command paletteHow to test the keybinding mappings work:
Try these mapped keybindings on the helloworld.java file
alt+shift+r/cmd+alt+r -> rename a variable
ctrl+alt+j/cmd+alt+j -> join lines
ctrl/cmd+shift+c -> comments the line
ctrl+h -> brings up search in side search bar
cmd+l/ctrl+l -> brings up go to line prompt
Review checklist
Reminder for reviewers
Signed-off-by: Josh Pinkney joshpinkney@gmail.com