# vim-lsp-settings for Vim Language Server Setup

> vim-lsp-settings adds guided installation, updates, and removal commands for Language Servers used through vim-lsp. It suits Vim users who want file-type-aware server setup without assembling every download command by hand, but it depends on vim-lsp and cannot install every supported server.

**mattn/vim-lsp-settings** — Auto configurations for Language Server for vim-lsp

- Repository: https://github.com/mattn/vim-lsp-settings
- Stars: 1,425 · Forks: 248
- Language: Vim Script
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/mattn-vim-lsp-settings

## Why vim-lsp-settings Exists Alongside vim-lsp

vim-lsp addresses a specific setup problem in Vim: Language Servers usually have to be obtained and installed outside the editor before an LSP client can use them. vim-lsp-settings adds a configuration layer for that operation. It provides `:LspInstallServer` as the normal entry point when editing a supported filetype, along with a removal command for cases where a server is no longer needed.

The project is aimed at Vim users who have already chosen prabirshrestha/vim-lsp and do not want to reproduce installation procedures for each Language Server. It is not a replacement editor, language runtime, or completion engine. Its README explicitly requires both vim-lsp and vim-lsp-settings to be installed. Users also remain responsible for choosing an optional completion integration such as asyncomplete.vim or ddc.vim if they want completion through those stacks.

This separation matters. vim-lsp-settings handles server discovery, installation, update behavior, and storage according to the configuration represented by the repository's `data/`, `settings/`, and `installer/` directories. Vim still supplies the editing environment, vim-lsp remains the client, and the Language Server performs language analysis. Completion presentation is another layer handled by an integration plugin. For teams standardizing on vim-lsp, that division avoids bundling several unrelated responsibilities into one package.

## Filetype Mapping, Installer Data, and Server Storage

The supported-language table maps Vim filetypes to candidate Language Servers and records two separate capabilities: whether the project can install the server and whether it can install from a local source. For example, the documentation lists `clangd` for C/C++, `gopls` for Go, `eclipse-jdt-ls` for Java, and `typescript-language-server` for JavaScript. Astro has several listed choices, including `astro-ls`, `biome`, `oxlint`, and `oxfmt`. This means matching a filetype does not necessarily produce one automatic choice. The documentation presents the server choices associated with that language, and users need to select or configure the desired one according to the vim-lsp workflow available to them.

The server binary is placed below a project-specific data directory after `:LspInstallServer` runs. On Windows, that location is `%LOCALAPPDATA%\vim-lsp-settings\servers`. On MacOS and Linux it is `$HOME/.local/share/vim-lsp-settings/servers`. If `$XDG_DATA_HOME` is defined, the documented location changes to `$XDG_DATA_HOME/vim-lsp-settings/servers`.

The `g:lsp_settings_servers_dir` variable changes this location when set to a full path. This is useful where user data is mounted, synchronized, or restricted differently, but it also means the server path becomes configuration that must remain consistent with vim-lsp. The repository layout separates generic plugin code, settings, language data, and installer scripts, which fits a metadata-driven approach rather than a single hard-coded installation command for every language.

## Installing vim-lsp-settings with vim-plug

The documented vim-plug setup installs the client first and the settings repository second. Add both plugin declarations to the Vim configuration used by vim-plug. The README presents the syntax with the `viml` fence used there, reproduced here without changing any names:

```viml
Plug 'prabirshrestha/vim-lsp'
Plug 'mattn/vim-lsp-settings'
```

After vim-plug processes the configuration, Vim has both plugin repositories declared. The README does not document a separate command for installing a prerequisite Language Server runtime, nor does it promise that declaring the plugins installs every supported server. Server installation remains an explicit later action.

Automatic completion is optional in this setup. With asyncomplete.vim, the documented declarations are:

```viml
Plug 'prabirshrestha/asyncomplete.vim'
Plug 'prabirshrestha/asyncomplete-lsp.vim'
```

For ddc.vim, the documented declarations are:

```viml
Plug 'Shougo/ddc.vim'
Plug 'shun/ddc-vim-lsp'
```

Choose one integration path if Vim completion is the goal. The installation documentation presents these as alternatives, while `vim-lsp-settings` itself remains focused on configuring and installing servers. External prerequisites for a particular Language Server, such as a language runtime or platform tool, are not enumerated in the supplied documentation.

## First Server Installation and the Upgrade Rule

Open or edit a file whose filetype has installer support, then run the installation command in Vim:

```viml
:LspInstallServer
```

According to the README, the supported filetype tells vim-lsp-settings which Language Server configuration to use. The server is downloaded into the documented `servers` directory after installation. Vim should report the installation operation and show an installed server in the corresponding user-data location. If the language has several mapped servers, such as Astro or JavaScript, the supported-language table is the place to check which choices are marked `Yes` under `Installer`.

There is no dedicated update command. The README gives a direct operational rule: run `:LspInstallServer` again, and the newer version will be installed. That makes reinstall the documented upgrade path. It also means an adoption decision should account for repeated installer runs rather than assuming an in-place `:LspUpdateServer` workflow.

Removal uses an explicit server identifier:

```viml
:LspUninstallServer server-name
```

The literal `server-name` here comes from the README's syntax example, not from a listed project-specific server. In practice, users need the exact server name from the supported-language table, such as `clangd` or `gopls`. The documentation does not describe dependency cleanup, partial rollback, or recovery if an installation fails partway through.

## Installer Coverage Gaps and Project Constraints

The largest constraint is visible in the support table itself. Several languages or servers are marked `No` for installer support. Debian entries for `debian-lsp`, the listed Haskell servers, and `java-language-server` do not provide the same automatic installer path. D has two installer-supported choices but is marked `No` for local installation, while Hy has installer support without local installation. This distinction matters for users who depend on managed binaries or offline installation.

The supported list also extends beyond the excerpt shown here, so the README table should be consulted for the current mapping rather than assuming every current editor language is covered. For each language, the important questions are whether `Installer` is `Yes`, whether `Local Install` is `Yes`, and which server identifier is expected by the uninstall command. A language being popular does not by itself establish installer coverage.

A second limitation is the upgrade model. Since the README states that servers have no update mechanism and recommends running `:LspInstallServer` again, teams should test that operation in the target environment. Network access, required runtimes, write permissions, and collisions with an existing binary are not documented here. Likewise, rollback is not documented, so removing a server and reinstalling should not be presented as a proven version restoration procedure.

Finally, the project does not claim to configure completion by itself. The optional asyncomplete.vim and ddc.vim paths are separate integrations. A working server installation may therefore produce language services while leaving completion display dependent on the rest of the Vim setup.

## Maintenance Signals, License, and the vim-lsp Alternative Boundary

The repository is not archived, and its last push was on 2026-10-05. That is a recent recorded change relative to the available release information, but it does not by itself guarantee coverage for every new Language Server. The listed release history contains `v0.0.1`, dated 2019-12-26, while the repository has continued to receive pushes. Maintenance should therefore be judged from current language mappings and installer behavior, not inferred from the age of that release tag.

The repository identifies its license as MIT. That is the project's stated licensing information, while compliance with dependencies and separately installed Language Servers remains outside what this repository can establish. The README does not enumerate licenses for every server downloaded by its installer.

The closest alternative approach is to keep vim-lsp but install and maintain each Language Server manually. That method gives direct control over acquisition and versioning, but it also transfers the file-type configuration, download location, version changes, and removal steps to the user. vim-lsp-settings replaces that repetition with project-provided mappings and commands. A separate LSP client or editor that already manages Language Servers follows a different architecture because Vim is not the client. The choice is therefore between retaining Vim and standardizing server management through vim-lsp-settings, or using tooling whose client and server lifecycle are managed together.

For repository maintenance tasks, the `Makefile` exposes `shellcheck`, `shellcheck-docker`, and `shfmt` targets. These cover installer shell scripts and formatting, but the README does not present them as user installation commands.

## Conclusion

Adopt vim-lsp-settings if you use vim-lsp, want a common installer command across supported filetypes, and accept rerunning installation for upgrades. Do not treat it as a standalone LSP client, a completion stack, or a universal Language Server installer. Verify first that your target filetype and server are marked as installer-supported, that the required runtimes are already available, and that your chosen completion plugin integrates with vim-lsp.

## FAQ

### How do I install a Language Server with vim-lsp-settings?

Install both prabirshrestha/vim-lsp and mattn/vim-lsp-settings, then edit a supported filetype and run `:LspInstallServer`. The README documents this command as the normal server installation path.

### How do I update a Language Server in vim-lsp-settings?

There is no dedicated update command. The README says to run `:LspInstallServer` again, which installs the newer version.

### Does vim-lsp-settings provide Vim completion by itself?

No completion plugin is required by the base installation instructions, but the README presents asyncomplete.vim and ddc.vim as optional integration paths. The selected completion stack still needs its own vim-plug declarations.

## Sources

- [Issues](https://github.com/mattn/vim-lsp-settings/issues)
- [License: MIT](https://github.com/mattn/vim-lsp-settings/blob/master/LICENSE)
- [mattn/vim-lsp-settings on GitHub](https://github.com/mattn/vim-lsp-settings)
- [README](https://github.com/mattn/vim-lsp-settings/blob/master/README.md)
- [Releases](https://github.com/mattn/vim-lsp-settings/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mattn-vim-lsp-settings