3 ms·

What would be a reason to use a tool like this in a proper IDE? I mean they should provide these features already. But I see them support eclipse, jetbrains, et

What would be a reason to use a tool like this in a proper IDE? I mean they should provide these features already. But I see them support eclipse, jetbrains, etc.

setr 8y ago
For the user of a fully functioning ide, probably not that much; LSP would be more important for developers of that software, since its less work to maintain, and improvements come free. Otherwise, it’d be things like faster/better support for non-tier-1 languages, like perhaps kotlin on eclipse, or rust on jetbrains, while stealing the benefits of their other work (I feel like outside of the more complex refactoring support, theres not much IDEs provide specific to their target language, that LSP doesn’t, but I’m not that sure) Its basically just less work for everyone involved; end-user-benefit being a byproduct of that
asdkhadsj 8y ago
The line between IDE and "text editor" is fuzzy these days. Mainly I think many people, such as myself, have an editor of choice. The editing process itself is what makes the editor their preference, so that's what they build their experience around. This is why (imo) you get text editors like sublime, vim, emacs serving such an IDE-centric experience. People don't think of it like IDE vs not-IDE, it's all an IDE, if you enjoy it you try to add features you want. Switching to a fully fledged IDE may have better language experiences, but for many that's the lesser factor. Hell, Vim has a lot of this stuff, but I switched to Kakoune a long while back, giving up a ton of my addons/plugins for languages. I can still write them (and am working on it), but the point is Kakoune is not nearly as widely supported on tooling as Vim is. Yet, the editor reigns supreme to me, and I prefer Kakoune.
Too 8y ago
It's quite obvious. Instead of every IDE supporting every language (N*M), you have every IDE supporting language server and one implementation of server per language (N+M).

What would be a reason to use a tool like this in a proper IDE? I mean they should provide these features already. But I see them support eclipse, jetbrains, etc.

setr 8y ago

For the user of a fully functioning ide, probably not that much; LSP would be more important for developers of that software, since its less work to maintain, and improvements come free. Otherwise, it’d be things like faster/better support for non-tier-1 languages, like perhaps kotlin on eclipse, or rust on jetbrains, while stealing the benefits of their other work (I feel like outside of the more complex refactoring support, theres not much IDEs provide specific to their target language, that LSP doesn’t, but I’m not that sure) Its basically just less work for everyone involved; end-user-benefit being a byproduct of that

asdkhadsj 8y ago

The line between IDE and "text editor" is fuzzy these days. Mainly I think many people, such as myself, have an editor of choice. The editing process itself is what makes the editor their preference, so that's what they build their experience around. This is why (imo) you get text editors like sublime, vim, emacs serving such an IDE-centric experience. People don't think of it like IDE vs not-IDE, it's all an IDE, if you enjoy it you try to add features you want. Switching to a fully fledged IDE may have better language experiences, but for many that's the lesser factor. Hell, Vim has a lot of this stuff, but I switched to Kakoune a long while back, giving up a ton of my addons/plugins for languages. I can still write them (and am working on it), but the point is Kakoune is not nearly as widely supported on tooling as Vim is. Yet, the editor reigns supreme to me, and I prefer Kakoune.

Too 8y ago

It's quite obvious. Instead of every IDE supporting every language (N*M), you have every IDE supporting language server and one implementation of server per language (N+M).