Skip to content
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

Merged
merged 1 commit into from
Sep 30, 2019

Conversation

svenefftinge
Copy link
Contributor

@svenefftinge svenefftinge commented Sep 29, 2019

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)

  • Start theia
  • change preferences, adding the following property:
"emmet.includeLanguages": {
    "typescript": "typescriptreact"
  }
  • open a TS file
  • start using content assist.

Without this change, there will be an error in the console.

see also #4050
fixes #4048

Review checklist

Reminder for reviewers

Copy link
Member

@akosyakov akosyakov left a 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

@AlexTugarev
Copy link
Contributor

testing right now...

@AlexTugarev
Copy link
Contributor

Uncaught (in promise) Error: Unknown actor StorageExt

I don't think this is related, but it's a new error.

// 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();
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

@svenefftinge svenefftinge Sep 30, 2019

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

  1. the internal language-specific commands from monaco (i.e. those starting with _execute) are registered in our command registry as part of @theia/monaco,
  2. those commands are aliased with vscode._execute... and proper conversion in plugin-ext-vscode and
  3. I remove the monaco.d.ts from plugin-ext-vscode

you are ok with that?

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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 */
Copy link
Contributor

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.

Copy link
Contributor Author

@svenefftinge svenefftinge Sep 30, 2019

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.

@AlexTugarev
Copy link
Contributor

Just verified that without this change there are no emmet suggestions for typescriptreact:

Screen Shot 2019-09-30 at 09 30 54

with this PR emmet suggestions are available 🎉

Screen Shot 2019-09-30 at 08 57 20

Copy link
Contributor

@AlexTugarev AlexTugarev left a 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.

@svenefftinge
Copy link
Contributor Author

@benoitf Ok to merge?

@svenefftinge svenefftinge force-pushed the se/plugin_vscode_executeDocumentSymbol branch from f66dd74 to 3fa4936 Compare September 30, 2019 08:45
Signed-off-by: Sven Efftinge <sven.efftinge@typefox.io>
@svenefftinge svenefftinge force-pushed the se/plugin_vscode_executeDocumentSymbol branch from 3fa4936 to 67217ea Compare September 30, 2019 08:47
id: 'vscode.executeDocumentSymbolProvider'
},
{
execute: (resource: URI) => commands.executeCommand('monaco._executeDocumentSymbolProvider',
Copy link
Contributor

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 ?

Copy link
Contributor Author

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?

Copy link
Contributor

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()

Copy link
Contributor Author

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.

@svenefftinge svenefftinge merged commit 821b9dc into master Sep 30, 2019
@svenefftinge svenefftinge deleted the se/plugin_vscode_executeDocumentSymbol branch September 30, 2019 09:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

implement vscode.executeDocumentSymbolProvider command for emmet VS Code extension
4 participants