williamboman / nvim-lsp-installer

Further development has moved to https://github.com/williamboman/mason.nvim!
https://github.com/williamboman/mason.nvim
Apache License 2.0
2k stars 123 forks source link

Add Grammarly language server #348

Closed mawkler closed 2 years ago

mawkler commented 2 years ago

Which server would you like to request to be added?

Which languages does this server target?

How is this server distributed?

williamboman commented 2 years ago

Hello! Cool! Could you give the branch add-grammarly (#349) a try? It seems fine to me, but the server seems pretty prone to spitting out errors - not sure if that's an issue with my local config or with the installation itself.

I decided to go with the unofficial npm package because this plugin is very much anchored to lspconfig (and the server config in lspconfig was based on that distribution).

mawkler commented 2 years ago

Thanks for looking into this so quickly! I get this huge error message when the server starts:

Click to expand ````text Error executing luv callback: /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:556: /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:74: invalid header line "content below.-->\\n' +\ '\\n' +\ '## Describe the bug\\n' +\ '\\n' +\ 'The following error message is printed whenever I jump to a `*.tex` window:\\n' +\ '\\n' +\ '```\\n' +\ '[coc.nvim] error: UnhandledRejection: request error nvim_eval - Vim:E117: Unknown function: coc#util#valid_state\\n' +\ '```\\n' +\ '\\n' +\ '## Reproduce the bug\\n' +\ '\\n' +\ '- Create file `mini.vim` with:\\n' +\ '\\n' +\ '```\\n' +\ 'set rtp+=~/.vim/bundle/Vundle.vim\\n' +\ 'call vundle#begin()\\n' +\ \"Plugin 'VundleVim/Vundle.vim'\\n\" +\ \"Plugin 'neoclide/coc.nvim'\\n\" +\ 'call vundle#end()\\n' +\ \"let g:coc_global_extensions = ['coc-texlab']\\n\" +\ '```\\n' +\ '\\n' +\ '- Start (neo)vim with command: `nvim -u mini.vim`\\n' +\ '- Create a window split\\n' +\ '- Open a `*.tex`-file that has been compiled and has a `.log`-file\\n' +\ \"- Leave and enter the file's window with the cursor\\n\" +\ '- Previously mentioned error should appear\\n' +\ '\\n' +\ \"The error seems to be related to the file's corresponding `.log`-file, because after removing it the error doesn't appear. After restoring the log file the error re-appears.\\n\" +\ '\\n' +\ '---\\n' +\ '\\n' +\ \"# `*` doesn't trigger completion window\\n\" +\ '\\n' +\ '## Result from CocInfo\\n' +\ '\\n' +\ '```\\n' +\ '\\n' +\ '## versions\\n' +\ '\\n' +\ 'vim version: NVIM v0.4.3\\n' +\ 'node version: v14.2.0\\n' +\ 'coc.nvim version: 0.0.78-e8e583c8e0\\n' +\ 'term: xterm-256color\\n' +\ 'platform: linux\\n' +\ '\\n' +\ '## Messages\\n' +\ '\\n' +\ '## Output channel: snippets\\n' +\ '\\n' +\ '[Info 20:35:17] Using ultisnips directories: UltiSnips /home/melker/.config/coc/ultisnips\\n' +\ '[Info 20:35:17] Using ultisnips python command: pyx\\n' +\ '\\n' +\ '## Output channel: prettier\\n' +\ '\\n' +\ '\\n' +\ '## Output channel: explorer\\n' +\ '\\n' +\ '```\\n' +\ '\\n' +\ '## Describe the bug\\n' +\ '\\n' +\ \"Completion window doesn't show up after I type `*`, which is bound to a snippet in Markdown files. However, if I trigger `coc#refresh()` the co mpletion window shows and displays the available snippet up as expected.\\n\" +\ '\\n' +\ 'It does for instance work with the charater `_`, i.e. the completion window shows up after pressing it.\\n' +\ '\\n' +\ 'My `:CocConfig` file is empty.\\n' +\ '\\n' +\ '## Reproduce the bug\\n' +\ '\\n' +\ '- Create file `mini.vim` with\\n' +\ '\\n' +\ ' ```\\n' +\ ' set rtp+=~/.vim/bundle/Vundle.vim\\n' +\ ' call vundle#begin()\\n' +\ \" Plugin 'VundleVim/Vundle.vim'\\n\" +\ \" Plugin 'neoclide/coc.nvim'\\n\" +\ \" Plugin 'honza/vim-snippets'\\n\" +\ ' call vundle#end()\\n' +\ ' inoremap coc#refresh()\\n' +\ ' ```\\n' +\ '\\n' +\ '- Start (neo)vim with command: `vim -u mini.vim testfile.md`\\n' +\ '\\n' +\ '- Enter insert mode\\n' +\ '\\n' +\ '- Type `*`\\n' +\ '\\n' +\ '- No completion window pops up (which it should)\\n' +\ '\\n' +\ '- Press ``\\n' +\ '\\n' +\ '- The completion window should show up and show the `*` snippet\\n' +\ '\\n' +\ '---\\n' +\ '\\n' +\ \"I'm having the same issue.\\n\" +\ '\\n' +\ 'This is my minimal `init.vim`:\\n' +\ '\\n' +\ '```\\n' +\ 'set rtp+=~/.vim/bundle/Vundle.vim\\n' +\ 'call vundle#begin()\\n' +\ \"Plugin 'VundleVim/Vundle.vim'\\n\" +\ \"Plugin 'Yggdroot/indentLine'\\n\" +\ \"Plugin 'lukas-reineke/indent-blankline.nvim'\\n\" +\ 'call vundle#end()\\n' +\ 'set conceallevel=2\\n' +\ '```\\n' +\ '\\n' +\ 'This is the output of `:version`:\\n' +\ '\\n' +\ '```\\n' +\ 'NVIM v0.5.0-540-g60c581b35\\n' +\ 'Build type: RelWithDebInfo\\n' +\ 'LuaJIT 2.1.0-beta3\\n' +\ 'Compilation: /usr/bin/gcc-5 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -\\n' +\ 'Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fno-common -fdiagnosti\\n' +\ 'cs-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEV\\n' +\ 'EL=3 -I/home/travis/build/neovim/bot-ci/build/neovim/build/config -I/home/travis/build/neovim/bot-ci/build/neovim/src -I/home/t\\n' +\ 'ravis/build/neovim/bot-ci/build/neovim/.deps/usr/include -I/usr/include -I/home/travis/build/neovim/bot-ci/build/neovim/build/s\\n' +\ 'rc/nvim/auto -I/home/travis/build/neovim/bot-ci/build/neovim/build/include\\n' +\ 'Compiled by travis@travis-job-495222b7-1d16-4b36-9b3a-9e6dacb42070\\n' +\ '\\n' +\ 'Features: +acl +iconv +tui\\n' +\ 'See \":help feature-compile\"\\n' +\ '\\n' +\ ' system vimrc file: \"$VIM/sysinit.vim\"\\n' +\ ' fall-back for $VIM: \"/share/nvim\"\\n' +\ '```\\n' +\ '\\n' +\ '---\\n' +\ '\\n' +\ \"I think I figured it out. The blank line indentation bars only appear after I save the file, which I didn't try until now.\\n\" +\ '\\n' +\ \"That seems to apply to any new b ````

And after closing that error message I get the following error message repeatadly whenever I try to do anything in Neovim:

Error executing luv callback:
/usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:556: cannot resume dead coroutine
stack traceback:
        [C]: in function 'request_parser'
        /usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:556: in function </usr/share/nvim/runtime/lua/vim/lsp/rpc.lua:545>

It also filled my ~/.cache/nvim/dap.log with multiple gigabytes lol.

This is the minimal config that I'm using:


call plug#begin('~/.config/nvim/packages/')
  Plug 'neovim/nvim-lspconfig'
  Plug 'williamboman/nvim-lsp-installer', {'branch': 'add-grammarly'} " Adds LspInstall command
call plug#end()

lua << EOF
local function make_config()
  local capabilities = vim.lsp.protocol.make_client_capabilities()
  capabilities.textDocument.completion.completionItem.snippetSupport = true
  return {
    capabilities = capabilities,
  }
end

require('nvim-lsp-installer').on_server_ready(function(server)
  local config = make_config()
  server:setup(config)
end)
EOF
mtoohey31 commented 2 years ago

Hello! I'm the author of the PR for server on the lspconfig repo, and I happened to run into the same issue an hour or two ago, though I hadn't run into it before while working on the PR. From what I can tell, this is happening because the server itself is sending an invalid header in one of its responses. Are you able to share the raw file this happens with? For me it only occurs with a single file out of the dozens I've tested, and haven't figured out what makes it unique yet.

As for the huge logs, the server does print quite a few debug messages by default, I'm not sure if there's a way to change the verbosity of those logs, but I'll look into it.

williamboman commented 2 years ago

This seemed to happen in all markdown files, take this repo's README for example.

mtoohey31 commented 2 years ago

Ok, I was able to reproduce that too, just to verify that we are both dealing with the exact same issue (if you have time), can you see what happens if you open this version of the README: README.md which has all of its HTML tags removed?

seblj commented 2 years ago

Just stopping by to say that I also got some errors with grammarly. I tried to open the README you specified, and it worked fine for me! I got my error when trying to open a README from a plugin I wrote. https://github.com/seblj/nvim-tabline/blob/master/README.md

image

In my example it has something to do with line number 5 (the line with the gif). If I remove that line, I don't get an error

@mtoohey31

mtoohey31 commented 2 years ago

Thank you for sharing @seblj, I thought it had something to do with HTML tags, but after playing around, it seems like the offending text is anything containing the word: content. The section of text that originally triggered it for me was: Web Content Accessibility Guidelines 2.0. I'm pretty sure this is a bug in the way the server is sending one of its requests on startup, because if you remove the word content, attach the server, then add the word back, there are no errors.

I'll open an issue on the upstream repo instead of the emacs fork, since I tested with the upstream version and it has the bug too. I might try taking a look into the server code too, I probably won't be able to figure anything out though.

mtoohey31 commented 2 years ago

Actually, on second thought, I'm not going to open an issue quite yet, I'd like to dig around and confirm that the issue is actually the server's request/response and not the way Neovim is handling things.

seblj commented 2 years ago

Glad I could be of help! Thanks for your work!

williamboman commented 2 years ago

can you see what happens if you open this version of the README: README.md which has all of its HTML tags removed?

That version of the README is not crashing it! Diagnostics are working, but I'm getting method workspace/executeCommand is not supported by any of the servers registered for the current buffer when trying to execute code actions (it does seem to apply the code action though, at least 60%1 of the time)

1 - very unscientific number

williamboman commented 2 years ago

Somewhat OT, but: I get the feeling like the server relies on quite a lot of non-spec functionalities? The in-spec LSP functionalities seem quite.. basic? The diagnostics are pretty exhaustive, but they provide no detailed explanations or useful code actions - is this provided through other non-spec commands?

mtoohey31 commented 2 years ago

Yes, that's an accurate assessment. The configs on the nvim-lspconfig repo are supposed to be kept pretty minimal, but there are additional features that could be supported through proper implementation of off-spec handlers in a plugin. I left a few notes about those features at the end of the PR conversation on the nvim-lspconfig repo.

f-squirrel commented 2 years ago

Hey @melkster and @williamboman , I have installed gramamrly how do I see the results of linting? According to LspInfo the module is loaded.

williamboman commented 2 years ago

I believe diagnostics should generally work out of the box, I can't recall if you actually have to configure something. As for code actions, you can bind <cmd>lua vim.lsp.buf.code_action()<CR> to a key (or run it manually). I'd personally recommend https://github.com/stevearc/dressing.nvim + telescope for getting a nicer UI for the code action picker

f-squirrel commented 2 years ago

@williamboman , I will take a look at the mentioned plugging but running lua vim.lsp.buf.code_action() returns No code actions available. Also, there are some configurations available, is there a way to set them via neovim?

williamboman commented 2 years ago

I'd recommend checking out the Neovim from scratch series, especially this video about LSP: https://www.youtube.com/watch?v=NXysez2vS4Q. Btw when you run vim.lsp.buf.code_action(), it will only return something if the cursor position is at a location where there is a code action (see :h vim.lsp.buf.code_action for more info on how it works).

f-squirrel commented 2 years ago

@williamboman , I believe I do have a general intuition of how Neovim and LSP work. I took the example from the original repository and code_action()ed on each word in the following sentence I got grammarly work in code., there are no code actions available, note that Grammarly shows warnings and suggestions for this sentence.

williamboman commented 2 years ago

Hm weird. It works fine for me:

https://user-images.githubusercontent.com/6705160/148376664-bd70cf4c-1087-4962-b016-070ad147eb4f.mov

There are some extra, non-standard, functionalities that is not covered (see https://github.com/neovim/nvim-lspconfig/pull/1562#issuecomment-997485554). But diagnostics and code actions should be good to go!

f-squirrel commented 2 years ago

For you, it works out of the box, this is super strange! I have copied the config from the README but maybe I miss something... If you have energy for this, I'd be very grateful if you could take a look at it: https://github.com/f-squirrel/scripts/blob/vim_lsp/dotfiles/vim/init.vim#L440

Version info:

NVIM v0.6.0
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/gcc-11 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az65-618

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "
/home/runner/work/neovim/neovim/build/nvim.AppDir/usr/share/nvim"

Run :checkhealth for more info
tiagovla commented 2 years ago

Thank you for sharing @seblj, I thought it had something to do with HTML tags, but after playing around, it seems like the offending text is anything containing the word: content. The section of text that originally triggered it for me was: Web Content Accessibility Guidelines 2.0. I'm pretty sure this is a bug in the way the server is sending one of its requests on startup, because if you remove the word content, attach the server, then add the word back, there are no errors.

I'll open an issue on the upstream repo instead of the emacs fork, since I tested with the upstream version and it has the bug too. I might try taking a look into the server code too, I probably won't be able to figure anything out though.

I can confirm this, I only get errors if the word content is present.

y9c commented 2 years ago

Yes. This error is trigger by the content word.