-
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
[plugin] support vscode.executeDocumentSymbol
command.
#6291
Conversation
8a3f2ca
to
f66dd74
Compare
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.
Code-wise it looks good, but I have not tried whether it works. cc @AlexTugarev
testing right now... |
I don't think this is related, but it's a new error. |
packages/plugin-ext-vscode/src/browser/plugin-vscode-commands-contribution.ts
Show resolved
Hide resolved
// Register built-in language service commands | ||
// see https://code.visualstudio.com/api/references/commands | ||
// tslint:disable: no-any | ||
const instantiationService = monaco.services.StaticServices.instantiationService.get(); |
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 would avoid to use monaco object directly.
We have a theia/monaco
package that should be used provide the communication to monaco.
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.
Why and how would adding an indirection help? This is clearly dependening on monaco so obfuscating that will only add unnecessary code and make it harder to understand.
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.
There is DI objects in @theia/monaco
Here you're asking for services and you're in the need of importing some monaco definition
By using @theia/monaco
there is no need to add this index.d.ts and tracking of what is used is clearly identified.
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.
The fact is there are too many command registries. If each service is managing its way (and internal way) to get a command registry it's not clean.
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.
Those commands are internal monaco commands and only added to our command registry through this contribution. I don't want to add them raw to our command registry and then have this contribution adding them once more using the vscode.
prefix and needed conversion. Maybe I don't understand what you mean, but adding this to @theia/monaco would do nothing other than exposing it through our API. I don't see how this would help. We do it like this in other places as well and especially here we are vscode-specific so directly using monaco makes perfect sense.
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.
well, if I read the discussion from one year, there are still a lot of discussions about the command registries, mapping, wrappers, ranges, etc. so something is not clear.
https://spectrum.chat/theia/dev/plugins-two-problems-related-to-command-parameters~11b89e76-1695-4eb1-b73e-49fb62cfb3f4
#4050
and latest discussion #5590
so I would fix it for once.
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 don't think I can or should fix all the confusion from those discussions in the PR.
But again if I change this PR so that
- the internal language-specific commands from monaco (i.e. those starting with
_execute
) are registered in our command registry as part of@theia/monaco
, - those commands are aliased with
vscode._execute...
and proper conversion inplugin-ext-vscode
and - I remove the monaco.d.ts from
plugin-ext-vscode
you are ok with that?
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.
@benoitf I have updated the code accordingly.
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.
@svenefftinge yes I think code is more maintainable
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.
@svenefftinge thx a lot
|
||
/// <reference types='@theia/monaco/src/typings/monaco'/> | ||
|
||
/* expose internal APIs in @theia/monaco/src/typings/monaco */ |
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 shouldn't be there, vscode is a client of theia-monaco, if there is something to be exposed, it should be exposed , it shouldn't use extra d.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.
That is what it says: Don't expose here but do so in @theia/monaco/src/typings/monaco
.
Actually, it is exactly how we do it elsewhere.
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 tested with the emmet builtin extension as described, and it was working nicely with typescript react. Though I couldn't reproduce the error to be logged on console.
@benoitf Ok to merge? |
f66dd74
to
3fa4936
Compare
Signed-off-by: Sven Efftinge <sven.efftinge@typefox.io>
3fa4936
to
67217ea
Compare
id: 'vscode.executeDocumentSymbolProvider' | ||
}, | ||
{ | ||
execute: (resource: URI) => commands.executeCommand('monaco._executeDocumentSymbolProvider', |
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.
just a question: why not use async/await instead of the callbacks ?
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.
sorry, I don't understand what you mean. Could you clarify?
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.
callback :
commands.executeCommand(...).then((foo) => {return foo.something() })
vs
async/await:
const foo = await commands.executeCommand(...)
return foo.something()
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.
Ah, I see. No specific reason but as this is a single expression I find it more readable and it has less code this way.
What it does
Registers the
vscode.executeDocumentSymbol
command, which is one of the commands vscode extensions might use.See https://code.visualstudio.com/api/references/commands for the full list.
How to test
Install the emmet extension (https://registry.npmjs.org/@theia/vscode-builtin-emmet/-/vscode-builtin-emmet-0.2.1.tgz)
Without this change, there will be an error in the console.
see also #4050
fixes #4048
Review checklist
Reminder for reviewers