6 ms·

I do not want to crap on either RH or MS devs and the volunteers around surronding projects, but I really like the idea of building backends you can plug into v

by 616c 10y ago

I do not want to crap on either RH or MS devs and the volunteers around surronding projects, but I really like the idea of building backends you can plug into various editors of your own choosing. - Java and emacs/vi: eclim - .Net and whatever: OmniSharp - Haskell and whatever: scion These are all so-so examples. But I wish we would move more towards this notion of abstracting backends out. I am one of those jackasses who loves emacs. And I should be able to impose that on myself AND only myself. I think we are reaching a point where tool lock-in a la Visual Studio and even in the open source space with projects like neovim-spacevim and spacemacs shows we are not cool with it. So is it possible for me to run this JS backend for Java parsing and replace eclim? Haha.

Analemma_ 10y ago
The backend that provides the language services for VSC is an HTTP server contacted over localhost, and the protocol is documented here: https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol. Sounds like it should be easy or at least possible to hook it up to a frontend of your choice.
colemickens 10y ago
Yes, Language Services and the language server protocol is literally exactly what you're asking for... For example RLS (Rust Language Service) is being implemented to conform to this protocol in the hope that the same engine can be used by all IDEs/editors.
iLemming 10y ago
Right. IDEs and editors appear, get their hype, some stale, others get forgotten, people get attached and then whine for years about shortcomings and weak support for certain languages and complain about lack of specific features. Or fell into Stockholm syndrome without slightest realization of how miserable and inefficient their workflow has become. Who remembers Borland C++ Builder? who uses Komodo or TextMate today? And now check the number of projects on Github written in Emacs Lisp. No matter how popular those shiny, fast and noisy F1 supercars would be - there always will be plenty of enthusiasts who'd rather choose Nascar, with its simplicity, openness and customizability. No IDE or editor would ever get even close to the power of Emacs. And the power of Emacs lies within its extensibility. I am not worried about other editors or IDEs getting better, faster or shinier. Because Emacs already can do same things better, or will be doing them better someday soon.
- GFK_of_xmaspast 10y ago
  I coded in emacs for 20+ years and switched to clion last year for c++ work because of things like "good autocompletion" and "refactoring" and "warning about issues before compiling". Emacs has minimal autocompletion facilities, but for ideological reasons it does not and may never have many of the other features. I still use emacs for non-coding text editing, and sometimes for python code and emergencies, but I've moved away from it big time. p.s. please fix your formatting, that quote is unreadable.
nojvek 10y ago
The protocol is based off Json rpc, over cli. Most vscode language services work this way. It should be pretty easy to hook it up with vim/emacs.

by 616c 10y ago

Analemma_ 10y ago

The backend that provides the language services for VSC is an HTTP server contacted over localhost, and the protocol is documented here: https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol. Sounds like it should be easy or at least possible to hook it up to a frontend of your choice.

colemickens 10y ago

Yes, Language Services and the language server protocol is literally exactly what you're asking for... For example RLS (Rust Language Service) is being implemented to conform to this protocol in the hope that the same engine can be used by all IDEs/editors.

iLemming 10y ago

Right. IDEs and editors appear, get their hype, some stale, others get forgotten, people get attached and then whine for years about shortcomings and weak support for certain languages and complain about lack of specific features. Or fell into Stockholm syndrome without slightest realization of how miserable and inefficient their workflow has become. Who remembers Borland C++ Builder? who uses Komodo or TextMate today? And now check the number of projects on Github written in Emacs Lisp. No matter how popular those shiny, fast and noisy F1 supercars would be - there always will be plenty of enthusiasts who'd rather choose Nascar, with its simplicity, openness and customizability. No IDE or editor would ever get even close to the power of Emacs. And the power of Emacs lies within its extensibility. I am not worried about other editors or IDEs getting better, faster or shinier. Because Emacs already can do same things better, or will be doing them better someday soon.

GFK_of_xmaspast 10y ago
I coded in emacs for 20+ years and switched to clion last year for c++ work because of things like "good autocompletion" and "refactoring" and "warning about issues before compiling". Emacs has minimal autocompletion facilities, but for ideological reasons it does not and may never have many of the other features. I still use emacs for non-coding text editing, and sometimes for python code and emergencies, but I've moved away from it big time. p.s. please fix your formatting, that quote is unreadable.

nojvek 10y ago

The protocol is based off Json rpc, over cli. Most vscode language services work this way. It should be pretty easy to hook it up with vim/emacs.