sublimelsp/LSP: Installation and First Use in Sublime

Why sublimelsp/LSP Exists for Sublime Text Users

sublimelsp/LSP solves the gap between Sublime Text and tools built around the Language Server Protocol. The repository describes the project as the "Client implementation of the Language Server Protocol for Sublime Text." That wording places the package inside the editor, but outside each individual language toolchain. The package supplies the client side, while a separate language server supplies language-specific behavior.

This distinction matters for Python, TypeScript, and other languages that can be supported by an LSP-compatible server. Installing this package alone does not give every file the same completion, navigation, or diagnostic behavior. The README sends users to the documentation's language-server directory and tells them to follow the installation steps for a specific server. The package therefore fits users who work in Sublime Text but need a standard protocol connection to external language tooling.

It is aimed at editors, not at people looking for a standalone compiler installation. The expected first visible sign is specific: after opening a supported document, the status bar should report that the language server is starting. If a user cannot identify or install the appropriate server, this package does not remove that requirement. The project is an integration layer, not a replacement for language runtimes, compilers, analyzers, or server executables.

The Client and Language-Server Split in sublimelsp/LSP

The repository layout supports a two-part architecture. The root contains `boot.py`, while most implementation code appears under `plugin/`. A `protocol/` directory and `plugin/core/protocol.py` place protocol-related code at the center of the package. Settings files such as `LanguageServers.sublime-settings` and `LSP.sublime-settings` provide configuration surfaces, while menu, command, and keymap files expose actions through Sublime Text's interface.

Based on that layout and the repository description, the client package handles the connection between Sublime Text and a language server. The external server remains responsible for its language environment. The README does not enumerate every request type, lifecycle transition, transport, or supported protocol capability, so those details cannot be established from the installation guide alone. The project documentation and its dedicated troubleshooting guide are the appropriate sources for more specific behavior.

This arrangement explains why server availability is an adoption constraint. A client cannot provide language intelligence without a compatible server behind it. The TypeScript server example shown in the README demonstrates the general model, but it does not establish that any particular server is bundled. Users must select a server from the documentation, install it according to that server's requirements, and open a document covered by its language configuration.

The package is therefore better understood as the Sublime Text side of a larger system. That design can reduce the amount of editor-specific integration needed for each server, but it also transfers setup responsibility to the user. A working editor plugin installation is only the first part of getting language intelligence.

Installing the Stable LSP Package in Sublime Text

The supported installation path starts inside Sublime Text rather than with a Python package command. From the command palette, run the exact Package Control action below and select `LSP` when prompted.

Package Control: Install Package

This is a command-palette entry, not a shell command. The README does not provide a terminal installation command, an end-user dependency version, or a Package Control channel name beyond selecting `LSP`. The project badge states Sublime Text 4132 or newer, which is the editor requirement shown in the README.

For a development checkout, the README instead says to clone the repository into Sublime Text's Packages directory and satisfy its libraries. The README does not give a terminal clone command.

The user must place the cloned directory in the local Sublime Text Packages directory. The README does not give a platform-specific path for that directory, so this article does not invent one. After placing the checkout there, use this Package Control command-palette entry:

Package Control: Satisfy Libraries

The stable Package Control route is the documented choice for ordinary installation. The development route is for contributors or users intentionally working from the repository. It adds source and library handling concerns without providing any additional language server by itself.

Connecting Your First Language Server

After installing `LSP`, choose a language through the language-server documentation at `https://lsp.sublimetext.io/language_servers`. The README does not include one universal server command, executable name, or configuration snippet because installation depends on the selected language server. A configuration example for a particular server would go beyond the documented scope.

The first-use check is short. Open a document whose language is supported by the configured server, then inspect the Sublime Text status bar. The README says it should report that the language server is starting. That message confirms that the editor recognizes a situation in which LSP is engaging with a server, although the README does not say that this status message guarantees every server feature is working.

The package does not turn one installation procedure into every server procedure. Depending on the language, the server may require its own executable, runtime, or configuration outside Package Control. The README does not claim that Package Control installs those external prerequisites for `LSP`. Their presence therefore needs to be handled through the selected server's instructions.

If the expected status does not appear, the README directs users to the troubleshooting guide. It also points unresolved cases to the SublimeHQ Discord `#lsp` channel and the GitHub issue tracker. Those support paths are relevant because installation failures may originate in the client configuration, the external server, or the boundary between them.

The Python Code and Sublime Package Runtime

sublimelsp/LSP is written primarily in Python, but the README does not present it as a terminal application that users invoke with `python`. Its entry point is `boot.py`, and its repository resources include `sublime-package.json`, settings files, menus, and keymaps. This structure indicates a package integrated with Sublime Text rather than a conventional command-line developer tool.

Development tooling has a separate lifecycle. `pyproject.toml` configures `pyright` for the `plugin` and `stubs` directories and `ruff` for formatting and linting. Its `lint` dependency group pins `pyright==1.1.414`, `ruff==0.17.0`, and `orjson==3.13.0`. The `tox` configuration skips source distribution creation and runs static checks under a Python 3 environment.

The normal installation instructions do not ask users to run these checks. That is an important boundary for adoption. Contributors working from a clone may need to satisfy repository libraries and use the declared development tooling, while an ordinary Sublime Text user follows Package Control and then installs a language server. The repository's Python dependencies should not be confused with the external tools required by every language server.

The README does not document a release packaging procedure, a server compatibility matrix, or a configuration generator. Those omissions matter when planning an upgrade. A client release and a language server release are separate events, so selecting the latest `LSP` release does not itself answer which server version or runtime the user should install.

Maintenance, Releases, and MIT Licensing

The repository is not archived, and its last push was on 2026-10-16. Recent releases include `4070-2.15.0` on 2026-10-10, `4070-2.14.0` on 2026-09-27, and `4070-2.13.0` on 2026-06-28. These facts show recent repository and release activity. They do not establish compatibility with every language server or prove that any specific server will work with a given project.

The stated license is MIT. That identifies the repository's licensing model, but it does not automatically cover separately installed language servers or their dependencies. The README does not summarize those external licenses or explain how they affect a particular deployment. Users with organization-specific compliance requirements need to inspect the license of each external tool they install. This is a scope observation, not legal advice.

Upgrade cost depends on where a change or failure lies. A new `LSP` release may change the Sublime client, while language analysis behavior can change because of an independently installed server or its runtime. The project documentation separates client setup from server setup, but the README does not publish a language-server compatibility table. A conservative upgrade process must check both sides rather than treating the package and server as one product.

There is also no documented rollback procedure in the README. Users comparing versions should therefore consult the release notes and the project's troubleshooting documentation rather than assume that downgrading has a prescribed rollback command.

Why a Separate Sublime Plugin Differs from sublimelsp/LSP

A direct alternative is a language-specific Sublime Text plugin that implements an editor integration without going through the Language Server Protocol. The repository does not identify a particular alternative or document its capabilities, so it would be inaccurate to claim that a named plugin supports more completions, diagnostics, or language versions.

The difference in approach can still be stated precisely. sublimelsp/LSP is explicitly a common client implementation for compatible language servers. Its behavior and available language coverage depend partly on servers that can be installed separately. A language-specific plugin would depend on its own documented integration mechanism and would not necessarily use LSP. The README does not document such a plugin, configuration file, or installation path, so the comparison stops there.

Another alternative is using Sublime Text without external language-server support. Syntax files can identify the language of a buffer, but the README does not claim that syntax definitions alone create an LSP connection. Adopting sublimelsp/LSP therefore adds a distinct client layer rather than merely adding syntax highlighting.

This architecture is a poor fit when one language has no compatible server, when the server's prerequisites cannot be installed, or when users expect the Sublime package to include every compiler and analyzer. It is relevant when users want a documented Sublime Text client and are prepared to install and maintain an external language server.

Editorial conclusion

Adopt sublimelsp/LSP if you use Sublime Text and want language-server support through a package-based client. Do not choose it if you need a self-contained language environment, because the README requires separate language-server installation. Verify first that the documentation has setup instructions for your language, that the server's prerequisites are available, and that Sublime Text reports the server starting in the status bar.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sublimelsp/LSP on GitHub