Sublime Forum

Do you have plans to add native LSP support in next releases?



I would like to know if there any plans to add native LSP support.


1 Like


Is there anything you hope to achieve from this that the third-party LSP package doesn’t fulfill currently?



I don’t think it’s a stretch to say that for the next 5 years of Sublime Text’s existence in the marketplace, the LSP package is probably the single most important package. It needs all the support it can get.



I use the third party LSP plugin extensively since the last few months. So far I am absolutely loving it. I use it primarily for JS . Here are my pet peeves so far

  1. Every now and then for some reason , I have to restart LSP service for my project.
  2. During this course of time, I had to reinstall Sublime quite a bit , because sometimes ST would become untenable (not because of ST , but because I had installed a “bad” package and I didnt know which one was it ). Everytime, I had to install ST , I had to install LSP plugin.
  3. There are a certain set of dependencies for LSP and when I had to install LSP for the first time , I had to install all these dependencies without which the LSP will not work.
  4. I also work on a number of VMs and installing these dependencies each and every time I am working on a VM, is a painful adventure.

I believe providing LSP support natively is going to help a lot and will resolve all these issues. ST can take care of handling these dependencies natively.




There is also the possibility to add incremental support for LSP without fully committing to LSP itself. Here are some self-contained suggestions, in order of importance:

  1. Support for explicit replacement ranges in completions:
  2. A richer completion widget:
    a) The kind of completion (Text, Method, Function, Constructor, Field, Variable, Class, Interface, Module, Property, etcetera) denoted as a little square symbol or something similar.
    b) Be aware of the difference between a label for presenting to the user in the widget and a filter for actually matching the characters that the user is typing.
    For instance, the label could be def foobar(x, y, z), which the user sees in the completion widget, but the filter could be foobar, the identifier that the user is actually typing.
    c) An optional return type field for languages that want it.
    d) An additional documentation widget underneath/above the completion widget.
    e) An additional “sort text” property of the completion that ST should use as string key to sort the completions.
    f) Additional text edits not directly under the cursor. e.g. a text edit for adding an additional import statement at the top of the file in case it is missing.
  3. A “signature help” widget. A widget that displays the current parameter + signature of the function-call that the user is typing out, along with room for documentation of the current parameter that the user is typing.
  4. Asynchronous completion provider API. In my ideal world, the API would look like this:
    async def on_query_completions(self, view, locations):
        response = await self.some_long_process.request_completions(view, locations)
        return self.format_response(response)
  1. Centralized “diagnostics” API along with possible “Fix My Mistake” actions. This would be a refiment of the phantoms API.
  2. Semantic highlighting API. Allow a plugin to provide additional scopes, in an asynchronous manner, to various identifiers in the view.
  3. Centralized “external process communication” API. Both over STDIO as well as TCP.

All of these suggestions are not LSP-specific and can benefit ST in the long run.



For the uninitiated (ie. me), is this “the third-party LSP” package that you’re referring to?



Yes (this post needs 10 characters).

1 Like