5 ms·

Used this a few years ago in early stages before VS code remote was a thing. It's very useful to add some interface extensibility components into VS Code's fram

by cbxyp 2y ago

Used this a few years ago in early stages before VS code remote was a thing. It's very useful to add some interface extensibility components into VS Code's framework. I suspect microsoft made some intentional design decision to make this harder to do in VS code's apis, totally eschewing any real editor extensibility in favor of a "apps in the editor, not extending the editor" design vs Atom's much more open ended allowance for modifications. For example, if you wanted to make a form builder in VS code for VS code extensions - that would not be usable outside of the Webview tab functionality without modifying the editor source. Glad eclipse foundation recognized this and is providing some groundwork to make a real IDE out of VS code. Theia was also the first to provide support for running vscode-as-a-platform and run via web browser, at least support that was functional and working.

dmix 2y ago
> I suspect microsoft made some intentional design decision to make this harder to do in VS code's apis, That's probably giving how software is made at these orgs too much credit.
- wkat4242 2y ago
  Yeah I'm always amazed how Microsoft can make both the best performing electron app, Vs code, and the absolute worst one in ms teams. At the same time. Clearly zero coordination going on there :(
bad_user 2y ago
When comparing VS Code with Atom, vim, Emacs, others, an underappreciated fact is that extensions just work, and are very easy to install and configure, which has much to do with its model. Atom was unusable for me, because, as you installed extensions, something always broke. This is also similar to the old Firefox vs Chrome. The former was great for power users, but it crashed a lot and Firefox installs of regular people were riddled with insecure extensions that broke the browser and that couldn't even be un-installed. VS Code does have flaws, but having limited extensions is not one of them, IMO.
- ReleaseCandidat 2y ago
  > VS Code does have flaws, but having limited extensions is not one of them, IMO. Exactly. Of course as somebody who writes extensions I'd sometimes like the possibility to change stuff at a "deeper" level - like having multi-line text decorations. But as a user I really prefer the model to the Emacs' one. Emacs (and I guess *vim) works best if the user writes all the code themselves.
- sureglymop 2y ago
  They don't "just work". There are many many extensions that require external tools in the path etc. and some even go as far as to try to download such dependencies (and leave them on the system). Generally one should definitely read the extension documentation and there may be some manual steps needed (meaning that they don't just work). It's true that the most popular extensions work fairly well though.
  - satvikpendem 2y ago
    For the purposes of the general end user who really doesn't care whether extra dependencies are on the system, it does "just work." Indeed, they might even want such behavior, that plugins manage their own dependencies without any end user input.
  - deleted 2y ago
    [deleted]
- satvikpendem 2y ago
  Yep, I routinely get breaking changes with my neovim config, so I now keep both VSCode and neovim installed.
  - gradientsrneat 2y ago
    I keep hearing of bugs and breaking changes in neovim, with no sign of it affecting the upstream vim. I am a little frustrated that neovim could give people a bad impression of vim from a stability/compatibility standpoint. Unlike emacs and atom, where you can modify the editor fundamentally, vim is extended with sandboxed scripting language(s) (I assume the same is true with neovim as well), so there's no fundamental reason why an update should break your plugins. Conflicts can occur due to overlapping hooks, but VSCode has the same problem. To be clear, I'm not suggesting people switch their text editor. Would love to hear from a more seasoned vim user if I'm missing some egregious stumbles in vim's updates that affected their workflow.

by cbxyp 2y ago

dmix 2y ago

> I suspect microsoft made some intentional design decision to make this harder to do in VS code's apis, That's probably giving how software is made at these orgs too much credit.

wkat4242 2y ago
Yeah I'm always amazed how Microsoft can make both the best performing electron app, Vs code, and the absolute worst one in ms teams. At the same time. Clearly zero coordination going on there :(

bad_user 2y ago

When comparing VS Code with Atom, vim, Emacs, others, an underappreciated fact is that extensions just work, and are very easy to install and configure, which has much to do with its model. Atom was unusable for me, because, as you installed extensions, something always broke. This is also similar to the old Firefox vs Chrome. The former was great for power users, but it crashed a lot and Firefox installs of regular people were riddled with insecure extensions that broke the browser and that couldn't even be un-installed. VS Code does have flaws, but having limited extensions is not one of them, IMO.

ReleaseCandidat 2y ago
> VS Code does have flaws, but having limited extensions is not one of them, IMO. Exactly. Of course as somebody who writes extensions I'd sometimes like the possibility to change stuff at a "deeper" level - like having multi-line text decorations. But as a user I really prefer the model to the Emacs' one. Emacs (and I guess *vim) works best if the user writes all the code themselves.
sureglymop 2y ago
They don't "just work". There are many many extensions that require external tools in the path etc. and some even go as far as to try to download such dependencies (and leave them on the system). Generally one should definitely read the extension documentation and there may be some manual steps needed (meaning that they don't just work). It's true that the most popular extensions work fairly well though.
- satvikpendem 2y ago
  For the purposes of the general end user who really doesn't care whether extra dependencies are on the system, it does "just work." Indeed, they might even want such behavior, that plugins manage their own dependencies without any end user input.
- deleted 2y ago
  [deleted]
satvikpendem 2y ago
Yep, I routinely get breaking changes with my neovim config, so I now keep both VSCode and neovim installed.
- gradientsrneat 2y ago
  I keep hearing of bugs and breaking changes in neovim, with no sign of it affecting the upstream vim. I am a little frustrated that neovim could give people a bad impression of vim from a stability/compatibility standpoint. Unlike emacs and atom, where you can modify the editor fundamentally, vim is extended with sandboxed scripting language(s) (I assume the same is true with neovim as well), so there's no fundamental reason why an update should break your plugins. Conflicts can occur due to overlapping hooks, but VSCode has the same problem. To be clear, I'm not suggesting people switch their text editor. Would love to hear from a more seasoned vim user if I'm missing some egregious stumbles in vim's updates that affected their workflow.