Now that I understand this functionality better, you may be right. I'm on the fence about whether it really should be built-in, but I can appreciate why you'd want it to be.
In effect, you're asking for the ability to extend the list of supported languages by specifying them on an ad hoc basis, and I can definitely see why that's an absolute must-have if you're working in a language that isn't built into the editor. (I really hope I'm capturing the functionality correctly.)
That being said, I suspect most developers rarely work in languages that aren't supported, so even IF this should be built-in, it seems like something that most users would never use. While I think that's perfectly reasonable in an IDE, I think a text editor should be limited to features that are used by a majority of its users for the majority of the time.
It's not that I'm saying this isn't crucial functionality. It's that if we start requiring text editors to have every bit of crucial functionality that anyone might have, you end up with an IDE.
I still think the problem is the plugin ecosystem. What would stop the Sublime team from saying, in effect: "This is functionality that should always and reliably be available for those who need it, so we're going to take responsibility for maintaining this as a plugin"?
> I suspect most developers rarely work in languages that aren't supported
Well, obviously, developers who work in language A aren't going to use an editor that doesn't support language A. They might want to use that editor, though.
No argument there. But Sublime does support those languages. You just need to install the right plugin.
The question is whether this should be baked in, or whether it should be managed with plugins.
There are lots of features people might want. Including them all creates a bloated text editor at worse, and a mediocre (IMHO) IDE at worst. I maintain that Sublime isn't and shouldn't be an IDE.
So they're better off only including the features that are very widely needed for a text editor, and then supporting the rest as plugins.
After all, isn't the ability to extend Sublime with plugins one of the biggest selling points? By being lean, it wastes as little computing power as possible on stuff you don't need, while giving you the ability to include virtually any functionality you do need.
I get that sometimes plugins fall out of active development or are broken for unacceptably long periods of time. But if the feature is something that the Sublime dev team wanted to support, there's no reason they couldn't support it as a plugin. Baking it in doesn't solve this problem, but it does create bloat.
I guess what I'm saying is: Why does language server support deserve to be baked-in more than any other feature? I have plenty of mission-critical needs that are supported by plugins. I don't expect them to be baked in just because they're important to me. I accept that the plugin ecosystem is the solution for my needs.
What makes language server support -- or any other beloved functionality -- so special?
> What makes language server support ... so special?
It allows creating plugins across multiple editors that all use a single language server project, rather of making plugin authors reimplement functionality from scratch based on a particular editor's quirks.
I had that reaction when I first learned about LSP. “It sounds like you’re reinventing the wheel by, say, coming up with another way to autocomplete Python in addition to what was already there. Oh wait, what do you mean that you’re planning on implementing LSP once for each language and once for each editor and then we’re in programming heaven? Ohh….”
In effect, you're asking for the ability to extend the list of supported languages by specifying them on an ad hoc basis, and I can definitely see why that's an absolute must-have if you're working in a language that isn't built into the editor. (I really hope I'm capturing the functionality correctly.)
That being said, I suspect most developers rarely work in languages that aren't supported, so even IF this should be built-in, it seems like something that most users would never use. While I think that's perfectly reasonable in an IDE, I think a text editor should be limited to features that are used by a majority of its users for the majority of the time.
It's not that I'm saying this isn't crucial functionality. It's that if we start requiring text editors to have every bit of crucial functionality that anyone might have, you end up with an IDE.
I still think the problem is the plugin ecosystem. What would stop the Sublime team from saying, in effect: "This is functionality that should always and reliably be available for those who need it, so we're going to take responsibility for maintaining this as a plugin"?