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

Open VSX client #421

Closed
zulus opened this issue May 6, 2020 · 5 comments
Closed

Open VSX client #421

zulus opened this issue May 6, 2020 · 5 comments

Comments

@zulus
Copy link
Contributor

zulus commented May 6, 2020

Hi, I think would be nice if WWD could install extensions directly from http://open-vsx.org/

@mickaelistria
Copy link
Contributor

Wild Web Developer isn't a VSCode compatible editor, and the goal is not to make a general puprose editor which users have to extend. It's a narrower-scope solution which is based upon the generic editor.
Support for VSX means binding "internal" VSCode APIs to the Java world with a layer of adaptation/transformation/emulation. It's IMO not the right grain for integrations. the right grains are language servers, and if we want to do some work to more easily install language servers for the Eclipse IDE, this would have to be handled by LSP4E.

@zulus
Copy link
Contributor Author

zulus commented May 6, 2020

OK, LSP4E also doesn't look as correct scope for this feature. This should be something similar like Marketplace Client, as http://open-vsx.org/ is also Eclipse project.

Would be good to have bridge that will consume vsix package:

  1. Download
  2. Extract
  3. Download dependencies
  4. Register content types, text mate grammars and language servers using standard eclipse/lsp4e endpoints

@mickaelistria
Copy link
Contributor

There is no direct binding of VS Code extensions to Eclipse IDE. So it's not only a fetch/package issue, it would also mean that to support VS extensions, some Eclipse plugin will need to implement all VSCode APIs (basically an alternative VSCode implementation) so that extensions could use that API and see it reacting as expected in the Eclipse IDE.
To me, it's plain utopy to assume a good binding can be provided and made sustainable in less than 2-3 years, so it's clearly a path I would deprecate.

Some time ago, there was an attempt at Eclipse Foundaiton of some language server registry. I also made experiments about automatically configurating and associating a language server by asking DockerHub APIs. And although many project managers seemed to think it was the best idea ever, those ended become abandoned, and the energy wasted.
IMO, your proposal echoes that, and I'm afraid if anyone start investing the huge effort it takes for it to work, it will end the same way.

@zulus
Copy link
Contributor Author

zulus commented May 6, 2020

I had hope because Eclipse Theia + Eclipse Che already are able to consume them :P (I know different project, different languages).

Anyway I understand your point of view and potential risk. Thank You for explanation. I have to rethink general idea, how-to simplify lsp/grammars installation.

@mickaelistria
Copy link
Contributor

I have to rethink general idea, how-to simplify lsp/grammars installation.

For Grammars, you can see eclipse-tm4e/tm4e#157
If some reliable registry or search engine would exist for language servers, a similar functionality could be offered by LSP4E.

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

No branches or pull requests

2 participants