Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cwd option not work for custom lsp #5149

Closed
ZSaberLv0 opened this issue Oct 10, 2024 · 6 comments
Closed

cwd option not work for custom lsp #5149

ZSaberLv0 opened this issue Oct 10, 2024 · 6 comments

Comments

@ZSaberLv0
Copy link
Contributor

Result from CocInfo

## versions

vim version: NVIM v0.10.1
node version: v22.8.0
coc.nvim version: 0.0.82-9c25f2f7 2024-08-31 14:53:59 +0800
coc.nvim directory: /Users/mac/.vim/bundle/coc.nvim
term: xterm-256color
platform: darwin

## Log of coc.nvim

2024-10-10T21:56:53.077 INFO (pid:70775) [plugin] - coc.nvim initialized with node: v22.8.0 after 151
2024-10-10T21:56:57.816 INFO (pid:70775) [services] - LanguageClient lua state change: stopped => starting
2024-10-10T21:56:57.820 INFO (pid:70775) [language-client-index] - Language server "languageserver.lua" started with 70777
2024-10-10T21:56:57.999 INFO (pid:70775) [services] - LanguageClient lua state change: starting => running
2024-10-10T21:56:58.005 INFO (pid:70775) [services] - service languageserver.lua started

Describe the bug

the document says "cwd": Working directory used to start languageserver, vim's cwd is used by default
but not work, process still started on getcwd()

Reproduce the bug

  • install lua-language-server

  • Create file mini.vim with:

    filetype plugin indent on
    syntax on
    set nocompatible
    let g:plug_home = $HOME . '/.vim/bundle'
    let g:plug_url_format = 'https://github.com/%s'
    execute 'source ' . g:plug_home . '/vim-plug/plug.vim'
    silent! call plug#begin()
    Plug 'junegunn/vim-plug'
    Plug 'neoclide/coc.nvim', {'branch': 'release'}
    call plug#end()
    
    call coc#config('languageserver.lua', {
                \   'command': &shell,
                \   'args': [&shellcmdflag, 'lua-language-server --logpath="/path/to/logs"'],
                \   'filetypes': ['lua'],
                \   'cwd': '/path/to/test',
                \   'initializationOptions': {},
                \   'settings': {},
                \ })
  • cd to any dir except /path/to/test, Start (neo)vim with command: vim -u mini.vim

  • edit any lua file, input something to make lsp run

  • open the log file of lua-language-server in /path/to/logs, search rootUri

    • the rootUri would be getcwd(), which should be the value configured by cwd
    • this would cause lua-language-server index all files under getcwd(), see also
@fannheyward
Copy link
Member

I'm using https://github.com/xiyaowong/coc-sumneko-lua extension to run the lua-language-server, will test the language server way.

From your test, what you want is: the configured /path/to/test is your project dir, you want to coc.nvim start the Lua-language-server in that dir wherever you start vim, right?

@ZSaberLv0
Copy link
Contributor Author

right, make cwd works as expected

ps:

  • not sure this could actually solves the issue, may be it's related to rootPattern or workspaceFolder or else
  • luals works as expected with vim-lsp if root_uri specified correctly

@fannheyward
Copy link
Member

The cwd configuration doesn't match your expectation, it's used to fork/spawn the server from, but not the project root.

After vim opens any Lua file, coc.nvim will detect the workspace root by rootPattern, from the file location. https://github.com/neoclide/coc.nvim/wiki/Using-workspaceFolders#resolve-workspace-folder

For your use case, the workpaceFolder or rootUri or rootPath will match your need, but you can't set it from languageserver options, try :h g:WorkspaceFolders.

@fannheyward
Copy link
Member

@ZSaberLv0 I don't understand your case for now. For example we have two projects:

  • ~/src/p1
  • ~/src/p2

Do want to language server runs on p1 even you launch vim in p2? Why?

In my workflow:

  • cd into p1, launch vim to :e foo or use file explorer to open foo file or vim foo directly, coc.nvim will detect and use p1 as the workspace root send to server
  • or launch vim outside p1, for example in p2, vim ~/src/p1/foo, coc.nvim still can detect and use p1

Can you describe your workflow case?

@ZSaberLv0
Copy link
Contributor Author

ZSaberLv0 commented Oct 11, 2024

  1. g:WorkspaceFolders may not be the best solution, there may be many LSPs running at same time, global options may have side effect
  2. as for my workflow:
    • I have a root project dir that contains many projects, with different languages, and it's my startup dir
    • sometimes, just want to quickly test or run some temp lua code, then a certain lua file would be opened, while getcwd() is still in my root project dir, that would cause luals got started, and then a huge indexing
      • or, sometimes during switching projects, or copying files between projects, the getcwd() left in root project dir
    • I have a custom config, that restart coc and all lsp when getcwd() changed, it works well for most LSPs
    • so I was thinking setting luals's rootUri depending on custom detect logic (which cause rootPattern not suit my case), after some search, the cwd option of coc seems the best and simplest way to suit my case, or, maybe a new option to specifiy workspaceFolder when starting LSP

@fannheyward
Copy link
Member

Yes, the global g:WorkspaceFolders is not a good solution.

quickly test or run some temp lua code

I'm interested in this case. If you open the certain Lua file in root project, your startup dir, the lua-LS indeed to perform huge indexing because the current dir is used as rootUri/rootPath for the server. I don't think there's anyway to stop the server to index, unless you put the Lua file in a sub folder with rootPattern, in coc.nvim's current detecting logic.

Setting a custom rootUri/rootPath/workspaceFolder is the way. The cwd option couldn't suit this because it's not used for workspace root.

Same issue #4938

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants