nvim-lspconfig nonfunctional, does not show under `Configured server list` nor attach

[uwidev]

textlsp does not seem to be detected after installation using nvim-lspconfig. Is there more I'm supposed to do after adding it under the config?

Relevant but gutted init.lua

```lua require('lazy').setup({ { -- LSP Configuration & Plugins 'neovim/nvim-lspconfig', dependencies = { { 'williamboman/mason.nvim', config = true }, -- NOTE: Must be loaded before dependants 'williamboman/mason-lspconfig.nvim', 'WhoIsSethDaniel/mason-tool-installer.nvim', { 'j-hui/fidget.nvim', opts = {} }, { 'folke/neodev.nvim', opts = {} }, }, config = function() vim.api.nvim_create_autocmd('LspAttach', { group = vim.api.nvim_create_augroup('kickstart-lsp-attach', { clear = true }), callback = function(event) -- keybind mappings would go here -- removed for clarity local client = vim.lsp.get_client_by_id(event.data.client_id) if client and client.server_capabilities.documentHighlightProvider then local highlight_augroup = vim.api.nvim_create_augroup('kickstart-lsp-highlight', { clear = false }) vim.api.nvim_create_autocmd({ 'CursorHold', 'CursorHoldI' }, { buffer = event.buf, group = highlight_augroup, callback = vim.lsp.buf.document_highlight, }) vim.api.nvim_create_autocmd({ 'CursorMoved', 'CursorMovedI' }, { buffer = event.buf, group = highlight_augroup, callback = vim.lsp.buf.clear_references, }) vim.api.nvim_create_autocmd('LspDetach', { group = vim.api.nvim_create_augroup('kickstart-lsp-detach', { clear = true }), callback = function(event2) vim.lsp.buf.clear_references() vim.api.nvim_clear_autocmds { group = 'kickstart-lsp-highlight', buffer = event2.buf } end, }) end end, }) local capabilities = vim.lsp.protocol.make_client_capabilities() capabilities = vim.tbl_deep_extend('force', capabilities, require('cmp_nvim_lsp').default_capabilities()) local servers = { tsserver = { cmd = { 'typescript-language-server', '--stdio' }, }, -- python ruff_lsp = {}, jedi_language_server = {}, -- shell/bash scripting bashls = {}, -- lua lua_ls = { settings = { Lua = { completion = { callSnippet = 'Replace', }, }, }, }, -- regular text textlsp = {}, }, -- Ensure the servers and tools above are installed local ensure_installed = vim.tbl_keys(servers or {}) vim.list_extend(ensure_installed, { 'stylua', -- Used to format Lua code 'shellcheck', 'shfmt', }) require('mason-tool-installer').setup { ensure_installed = ensure_installed } require('mason-lspconfig').setup { handlers = { function(server_name) local server = servers[server_name] or {} -- This handles overriding only values explicitly passed -- by the server configuration above. Useful when disabling -- certain features of an LSP (for example, turning off formatting for tsserver) server.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {}) require('lspconfig')[server_name].setup(server) end, }, } end, }, }) ```

LspInfo when a buffer is open of file a.text

Mason

I have also tried the default config provided under readme as well as manual defaults from nvim-lspconfig and it also does not work.

[hangyav]

Based on a quick look at your config this should work. Do you get any error messages when opening a text file with nvim? It's odd that textlsp's icon in the mason list is gray. Is there any particular reason for that? Could you verify that it is actually installed under ~/.local/share/nvim/mason/packages?

[uwidev]

It's odd that textlsp's icon in the mason list is gray. Is there any particular reason for that?

It's my theme. Whatever my cursor is over colors the line grey.

Do you get any error messages when opening a text file with nvim?

I get no errors whatsoever when opening any .text files. I tried the .org and .tex and no responses at all.

Could you verify that it is actually installed under ~/.local/share/nvim/mason/packages?

~/.local/share/nvim/mason/packages
 ls
bash-language-server             ruff-lsp                   stylua
css-lsp                          rust-analyzer              tailwindcss-language-server
docker-compose-language-service  shellcheck                 textlsp
jedi-language-server             shfmt                      typescript-language-server
lua-language-server              some-sass-language-server  typos-lsp

 ls textlsp
mason-receipt.json  venv

 ls textlsp/venv
bin  include  lib  lib64  pyvenv.cfg  share

 ls textlsp/venv/bin
activate       convert-caffe2-to-onnx  httpx            numpy-config  pip3.12     textlsp
activate.csh   convert-onnx-to-caffe2  huggingface-cli  openai        python      torchrun
activate.fish  distro                  isympy           pip           python3     tqdm
Activate.ps1   f2py                    normalizer       pip3          python3.12  transformers-cli

I forgot to mention this, but I am using neovim v0.11.0-dev-283+gfe5d1279a4.

Just to confirm, I should have LanguageTool installed on my system just to test of the plugin can connect, right? I'm using Archlinux and I installed thorugh the AUR. Was that all that had to be done to test if the plugin works?

Addition: If I try to LspStart the LSP, it doesn't even show up.

I can try an extremely barebones config sometime later, this is really weird.

[uwidev]

Accidentally closed.

[uwidev]

It seems that manually having require('lspconfig').textlsp.setup({}) allows the LSP to be detected and work just fine, which is to perhaps say that something's is funky with how kickstart's lsp integration interacts with textlsp.

Here's a better import of what I used for lazy. The important stuff is at the bottom.

nvim-lspconfig to include in lazy

```lua return { -- LSP Configuration & Plugins 'neovim/nvim-lspconfig', dependencies = { -- Automatically install LSPs and related tools to stdpath for Neovim { 'williamboman/mason.nvim', config = true }, -- NOTE: Must be loaded before dependants 'williamboman/mason-lspconfig.nvim', 'WhoIsSethDaniel/mason-tool-installer.nvim', -- Useful status updates for LSP. -- NOTE: `opts = {}` is the same as calling `require('fidget').setup({})` { 'j-hui/fidget.nvim', opts = {} }, -- `neodev` configures Lua LSP for your Neovim config, runtime and plugins -- used for completion, annotations and signatures of Neovim apis { 'folke/neodev.nvim', opts = {} }, }, config = function() -- If you're wondering about lsp vs treesitter, you can check out the wonderfully -- and elegantly composed help section, `:help lsp-vs-treesitter` -- This function gets run when an LSP attaches to a particular buffer. -- That is to say, every time a new file is opened that is associated with -- an lsp (for example, opening `main.rs` is associated with `rust_analyzer`) this -- function will be executed to configure the current buffer vim.api.nvim_create_autocmd('LspAttach', { group = vim.api.nvim_create_augroup('kickstart-lsp-attach', { clear = true }), callback = function(event) -- Removed keybindings and only keybindings... -- The following two autocommands are used to highlight references of the -- word under your cursor when your cursor rests there for a little while. -- See `:help CursorHold` for information about when this is executed -- -- When you move your cursor, the highlights will be cleared (the second autocommand). local client = vim.lsp.get_client_by_id(event.data.client_id) if client and client.server_capabilities.documentHighlightProvider then local highlight_augroup = vim.api.nvim_create_augroup('kickstart-lsp-highlight', { clear = false }) vim.api.nvim_create_autocmd({ 'CursorHold', 'CursorHoldI' }, { buffer = event.buf, group = highlight_augroup, callback = vim.lsp.buf.document_highlight, }) vim.api.nvim_create_autocmd({ 'CursorMoved', 'CursorMovedI' }, { buffer = event.buf, group = highlight_augroup, callback = vim.lsp.buf.clear_references, }) vim.api.nvim_create_autocmd('LspDetach', { group = vim.api.nvim_create_augroup('kickstart-lsp-detach', { clear = true }), callback = function(event2) vim.lsp.buf.clear_references() vim.api.nvim_clear_autocmds { group = 'kickstart-lsp-highlight', buffer = event2.buf } end, }) end -- The following autocommand is used to enable inlay hints in your -- code, if the language server you are using supports them -- -- This may be unwanted, since they displace some of your code if client and client.server_capabilities.inlayHintProvider and vim.lsp.inlay_hint then map('th', function() vim.lsp.inlay_hint.enable(not vim.lsp.inlay_hint.is_enabled()) end, '[t]oggle Inlay [h]ints') end end, }) -- LSP servers and clients are able to communicate to each other what features they support. -- By default, Neovim doesn't support everything that is in the LSP specification. -- When you add nvim-cmp, luasnip, etc. Neovim now has *more* capabilities. -- So, we create new capabilities with nvim cmp, and then broadcast that to the servers. local capabilities = vim.lsp.protocol.make_client_capabilities() capabilities = vim.tbl_deep_extend('force', capabilities, require('cmp_nvim_lsp').default_capabilities()) -- Enable the following language servers -- Feel free to add/remove any LSPs that you want here. They will automatically be installed. -- -- Add any additional override configuration in the following tables. Available keys are: -- - cmd (table): Override the default command used to start the server -- - filetypes (table): Override the default list of associated filetypes for the server -- - capabilities (table): Override fields in capabilities. Can be used to disable certain LSP features. -- - settings (table): Override the default settings passed when initializing the server. -- For example, to see the options for `lua_ls`, you could go to: https://luals.github.io/wiki/settings/ local servers = { -- clangd = {}, -- gopls = {}, -- pyright = {}, rust_analyzer = {}, -- ... etc. See `:help lspconfig-all` for a list of all the pre-configured LSPs -- -- Some languages (like typescript) have entire language plugins that can be useful: -- https://github.com/pmizio/typescript-tools.nvim -- -- But for many setups, the LSP (`tsserver`) will work just fine tsserver = { cmd = { 'typescript-language-server', '--stdio' }, }, -- python ruff_lsp = {}, jedi_language_server = {}, -- shell/bash scripting bashls = {}, -- docker docker_compose_language_service = {}, -- lua lua_ls = { -- cmd = {...}, -- filetypes = { ...}, -- capabilities = {}, settings = { Lua = { completion = { callSnippet = 'Replace', }, -- You can toggle below to ignore Lua_LS's noisy `missing-fields` warnings -- diagnostics = { disable = { 'missing-fields' } }, }, }, }, -- regular text textlsp = {}, -- typos_lsp = { -- -- Logging level of the language server. Logs appear in :LspLog. Defaults to error. -- cmd_env = { RUST_LOG = 'error' }, -- init_options = { -- -- Custom config. Used together with any workspace config files, taking precedence for -- -- settings declared in both. Equivalent to the typos `--config` cli argument. -- config = '~/code/typos-lsp/crates/typos-lsp/tests/typos.toml', -- -- How typos are rendered in the editor, can be one of an Error, Warning, Info or Hint. -- -- Defaults to error. -- diagnosticSeverity = 'Error', -- }, -- }, }, -- Ensure the servers and tools above are installed -- To check the current status of installed tools and/or manually install -- other tools, you can run -- :Mason -- -- You can press `g?` for help in this menu. require('mason').setup() -- You can add other tools here that you want Mason to install -- for you, so that they are available from within Neovim. local ensure_installed = vim.tbl_keys(servers or {}) vim.list_extend(ensure_installed, { 'stylua', -- Used to format Lua code 'shellcheck', 'shfmt', }) require('mason-tool-installer').setup { ensure_installed = ensure_installed } require('mason-lspconfig').setup { handlers = { function(server_name) local server = servers[server_name] or {} -- This handles overriding only values explicitly passed -- by the server configuration above. Useful when disabling -- certain features of an LSP (for example, turning off formatting for tsserver) server.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {}) require('lspconfig')[server_name].setup(server) end, }, } -- require('lspconfig').textlsp.setup {} -- It works if we just initialize setup normally. end, } ```

Update: It seems that for some reason, the textlsp key-value is not being passed to mason-lspconfig handler function. A simple print(server_name) was used to check if textlsp was even being processed, which it isn't. I confirmed that it actually exists in the table by inspecting it.

[uwidev]

It seems that it's because textlsp is not registered in williamboman/mason-lspconfig repository. If you want I can go ahead and issue a pull request over there to implement textlsp. It doesn't look that hard since it seems like it's just 3 line additions across 3 files, but I'm also not sure if you need to do more.

Locally on my machine, I edited mason-lspconfig to add the mapping for textlsp and the plugin loaded. I have yet to test if the rest of the functionality works.

Update: languagetool seems to work, however, when trying to use Ollama, I get the following error message.

LSP[textlsp] Unsupported module: textLSP.analysers.ollama

Using this following setup

    require('lspconfig').textlsp.setup {
      settings = {
        textLSP = {
          analysers = {
            languagetool = {
              enabled = false,
            },
            ollama = {
              enabled = true,
              check_text = {
                on_open = false,
                on_save = true,
                on_change = false,
              },
              model = 'phi3:3.8b-instruct', -- smaller but faster model
              -- model = "phi3:14b-instruct",  -- more accurate
              max_token = 50,
            },
          },
        },
      },
    }

Update 2: Mason registry is on v0.3.0. Manually updating with pip to install the current up to date repo. And it works!

I guess the majority of the problem was not having the mapping integration in mason-registry and mason packages being out of date.

[hangyav]

Thanks for looking into this. I'm not familiar with how kickstart is configured, but I tested it with a clean LazyVim installation that uses mason-registry and a simple .config/nvim/lua/plugins/lspconfig.lua config:

return {
    "neovim/nvim-lspconfig",
    opts = {
        servers = {
            textlsp = {},
        },
    },
}

After installing textlsp with MasonInstall textlsp manually, it worked. So just for future reference to others running into similar issues since I'm not too familiar with the works of Mason either, what was the main issue? You need to make sure mason-registry is included in the config or we need to add textlsp to williamboman/mason-lspconfig?

Answering your other questions:

Just to confirm, I should have LanguageTool installed on my system just to test of the plugin can connect, right? I'm using Archlinux and I installed thorugh the AUR. Was that all that had to be done to test if the plugin works?

For the LanguageTool analyser you only need to make sure that Java is installed, the tool itself is installed automatically. Otherwise, it should be good to go (by default only the LanguageTool analyser is enabled).

It seems that it's because textlsp is not registered in williamboman/mason-lspconfig repository. If you want I can go ahead and issue a pull request over there to implement textlsp. It doesn't look that hard since it seems like it's just 3 line additions across 3 files, but I'm also not sure if you need to do more.

It would be nice if you could do that, thanks!

when trying to use Ollama, I get the following error message. LSP[textlsp] Unsupported module: textLSP.analysers.ollama

Yeah, for now Ollama is in the latest github version only. I'll release it to pypi hopefully soon.

[uwidev]

So just for future reference to others running into similar issues since I'm not too familiar with the works of Mason either, what was the main issue? You need to make sure mason-registry is included in the config or we need to add textlsp to williamboman/mason-lspconfig?

As far as I'm aware, mason-lspconfig is a wrapper of sorts for mason and nvim-lspconfig. More or less it automatically fetches the related mason package and sets it up for you via lspconfig; it just trivializes the process. That said, it only works if an lsp name passed to it is actually registered. This is because lspconfig and mason use slightly different naming conventions, so this mapping is required to map the mason package to the lspconfig setup.

If you take a look at some of the example pull requests, it's really quite simple. The pull request has been made.

For anyone using mason-lspconfig, their options at the moment are to manually apply the mason-lspconfig edits themselves (as seen above in the pull request) on their local install or manually call setup().