Language server vs native development

[usig]

I am not familiar with language server but reading about it it seems they provide lots of functional overlapping with features supported by SublimeText. I wonder how well do they integrate? I imagine the look and feel remains the same after LSP had been integrated into ST? Or are there overlapping, conflicts, shortcomings to be expected?

[bschaaf]

LSP doesn’t replace a lot of Sublime Text features, mainly just autocomplete, popups and goto-definition. See the LSP plugin.

[usig]

Independent of the current development state, are LSP limited to language services or are build systems possible, as well? The gif animation from the link provided shows code linting, i suppose, but a build system could be used just as well.

If LSP can provide intelligent code completion that would be really awesome, but what about my custom snippets? With ST i’m used to modify code completions to my liking but i wonder how intrusive LSP would be when 2 code completion systems are used simultaneous. Can server side completions be overwritten by client side completions?

Also, multiple LSP can be used simultaneously but for some features this makes more sense than for others. For example, i could use 2 server for linting but not 2 server for code completion.

[rwols]

Independent of the current development state, are LSP limited to language services or are build systems possible, as well? The gif animation from the link provided shows code linting, i suppose, but a build system could be used just as well.

On a high level, generally speaking, the “server” is a long-running subprocess of the “client” (in this case, plugin_host (which is itself a long-running subprocess of Sublime Text)). These servers are not fit to be ran for a short while like is done with a build system.

If LSP can provide intelligent code completion that would be really awesome, but what about my custom snippets? With ST i’m used to modify code completions to my liking but i wonder how intrusive LSP would be when 2 code completion systems are used simultaneous. Can server side completions be overwritten by client side completions?

Your snippets will still show up in the auto-complete widget. This isn’t really particular to language server completions. Generally speaking, any plugin can decide to hide/show your word/snippet completions.

Also, multiple LSP can be used simultaneously but for some features this makes more sense than for others. For example, i could use 2 server for linting but not 2 server for code completion.

That’s correct The LSP plugin linked above actually does this. It can run multiple langservers for a single view. If it makes sense to combine features it does so, for example for linting results like you mentioned. It also merges all code actions. Otherwise, a selector is used to choose the “best” langserver for a particular feature and point in the view.

[tajmone]

Does anyone know if ST4 will provide native support for LSP, and if language servers are going to be a main feature of v4?

I haven’t really followed much all the announcements regarding ST4, so I might be asking something that was already discussed many times — I apologize if I’m asking a redundant question. It’s just that when I discovered the LSP protocol I was quite enthusiastic about it, but I didn’t get the impression that LSP support for ST3 got very far, so I was wondering if ST4 might have an edge over ST3 in this respect.

[jfcherng]

Does anyone know if ST4 will provide native support for LSP, and if language servers are going to be a main feature of v4?

No. ST 4 provides some new plugin APIs which help the LSP plugin to do its job better. But still, LSP is a 3rd-party plugin.

[tajmone]

No. ST 4 provides some new plugin APIs which help the LSP plugin to do its job better.

Thanks for the prompt reply @jfcherng!

That’s good news. I believe (and hope) that we’ll see a growing number of language servers becoming available in the future, especially official ones released by the creators/maintainers of open source languages.

But still, LSP is a 3rd-party plugin.

I was hoping that LSP would become natively supported in ST4, or something along the lines of ST3’s package manager, which started as a third party tool and then become a natively shipped package.

The LSP standard is likely to evolve in the future, with new features being added to its official specification (e.g. to offer better support for code refactoring); so it would have been preferable is LSP became a native ST4 feature, meaning that it would be updated and developed by ST devs, offering a solid and unique interface — as opposed to having multiple user-packages, which might end up being updated at different rates (e.g. a given package embodying the latest LSP features and updates at a given time, then another package taking the leading position, due to inconsistent maintenance by the third parties).

For me, LSP has been (and is) the main factor in deciding whether to migrate to ST4 or VSCode in the near feature. One of the major points of strength in VSCode, IMO, has been indeed its native support for LSP (which makes sense from the VSCode perspective, since they are both MS products); one might reasonably argue that VSCode has been a major driving force towards the adoption of language servers.

I’m afraid that VSCode already has an edge regarding LSP support, compared to other editors, by the mere fact that the core team members behind LSP and VSCode are all part of the MS team, which means that decisions and efforts for advancing both products tend to go hand in hand. Another edge factor is official documentation, where the VSCode team invests great energy in covering all native features in the official docs; in the case of LSP, they’ve also created dedicated tutorials and tools to simplify creating new lang servers.

When ST4 will be officially out, I’ll probably end up waiting for a while to see how LSP supports develops, and keep using ST3 in the meanwhile. Having used ST3 on a daily basis for years, it’s going to be hard for me to switch to another editor (e.g. VSCode), whereas upgrading to ST4 would be a much smoother transition. But LSP support is so important to me that I’ll be ultimately willing to switch editor for the sake of it.

I work a lot with AsciiDoc, which is a good example of a syntax that is too complex to handle well with RegEx-based definitions — indeed, capturing nested blocks might not even be possible, since AsciiDoc uses variable-length balanced block delimiters, and RegEx based syntax definitions are not able to store information such as the length of the opening delimiter that pushed the current context. Similar syntaxes can’t be supported well without LSP — sure, there are various AsciiDoc packages out there in the wild, but none of them capable of providing detailed semantic highlighting of AsciiDoc documents.

AsciiDoc is also another good example of a syntax that could greatly benefit from advanced LSP features in terms of document linting and enforcing consistent formatting. Since language servers fully parse the document, and build an AST, they can provide a great editing experience for documentation syntaxes.