ibhagwan / fzf-lua

Improved fzf.vim written in lua
GNU Affero General Public License v3.0
1.95k stars 133 forks source link

Bug: `gd` on css file results in error #1317

Closed skoch13 closed 1 day ago

skoch13 commented 4 days ago

RTFM Checklist

Operating system

MacOS 14.5

Shell

zsh

Neovim version (nvim --version)

NVIM v0.11.0-dev-328+g599fc7cee

Fzf version (fzf --version)

0.53.0 (brew)

Output of :lua print(os.getenv('FZF_DEFAULT_OPTS'))

--color=fg:#c8d3f5,bg:#222436,hl:#7aa2f7 --color=fg+:#c8d3f5,bg+:#2f334d,hl+:#7aa2f7 --color=info:#82aaff,prompt:#bb9af7,pointer r:#bb9af7 --color=marker:#c3e88d,spinner:#c3e88d,header:#c3e88d --bind ctrl-y:preview-up,ctrl-e:preview-down,ctrl-b:preview-page-up, ,ctrl-f:preview-page-down,ctrl-u:preview-half-page-up,ctrl-d:preview-half-page-down --layout=reverse

Is the problem reproducible with mini.sh?

Fzf-lua configuration

the default configuration which LazyVim provides

Describe the bug / steps to reproduce

Pressing gd on import * as styles from './style.css'; results in error

note: using gD - goToSourceDefinition via vtsls doesn't error

 Error  07:49:39 msg_show.lua_error Error executing Lua callback: ...htly/nvim-macos-arm64/share/nvim/runtime/lua/vim/uri.lua:103: URI must contain a scheme: /Users/user/.../style.css
stack traceback:
    [C]: in function 'assert'
    ...htly/nvim-macos-arm64/share/nvim/runtime/lua/vim/uri.lua:103: in function 'uri_to_fname'
    ...nvim-macos-arm64/share/nvim/runtime/lua/vim/lsp/util.lua:1782: in function 'locations_to_items'
    ...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:139: in function <...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:138>
    vim/shared.lua: in function 'tbl_filter'
    ...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:138: in function 'handler'
    ...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:470: in function 'fn_contents'
    ...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:623: in function 'fn'
    ...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:966: in function <...al/share/nvim/lazy/fzf-lua/lua/fzf-lua/providers/lsp.lua:955>
    ...och13/.local/share/nvim/lazy/fzf-lua/lua/fzf-lua/cmd.lua:35: in function 'run_command'
    ...koch13/.local/share/nvim/lazy/fzf-lua/plugin/fzf-lua.lua:12: in function <.../.local/share/nvim/lazy/fzf-lua/plugin/fzf-lua.lua:11>
ibhagwan commented 3 days ago

It seems that the file path (URI) is malformed /Users/user/.../style.css, it is then sent to locations_to_items which fzf-lua uses for various filters (cwd, etc).

I installed vtsls but couldn't reproduce this so I'm gonna need adittional information from you to be able to debug this, can you run the below while having the cursor at the exact location where this fails?

:= vim.lsp.buf_request_sync(0, "textDocument/definition", vim.lsp.util.make_position_params(0))

It should print an output of the LSP response into :messages, paste it below and I'll be able to understand what's going on.

skoch13 commented 3 days ago

@ibhagwan

It seems that the file path (URI) is malformed /Users/user/.../style.css

That is me removing private data from it, but in a reality it is absolute path:

{ 
 [2] = { 
 result = { 
 range = { 
 ["end"] = { 
 character = 0, 
 line = 0 
 }, 
 start = { 
 character = 0, 
 line = 0 
 } 
 }, 
 uri = "/Users/%USER%/%PATH%/style.css" 
 } 
 }, 
 [5] = { 
 result = { { 
 originSelectionRange = { 
 ["end"] = { 
 character = 49, 
 line = 17 
 }, 
 start = { 
 character = 24, 
 line = 17 
 } 
 }, 
 targetRange = { 
 ["end"] = { 
 character = 0, 
 line = 0 
 }, 
 start = { 
 character = 0, 
 line = 0 
 } 
 }, 
 targetSelectionRange = { 
 ["end"] = { 
 character = 0, 
 line = 0 
 }, 
 start = { 
 character = 0,
ibhagwan commented 2 days ago

Aside from the hidden private data does the uri start with file:// or it starts directly with /Users?

skoch13 commented 2 days ago

Aside from the hidden private data does the uri start with file:// or it starts directly with /Users?

it starts with /Users, so the error regarding lack of scheme indeed correct 🤷

ibhagwan commented 2 days ago

Technically this would be a bug in vtsls (or neovim, not sure?) but idk why this happens on your system, can you try with tsserver directly?

In any event I will “hack” it by making sure URIs fully qualified.

skoch13 commented 2 days ago

can you try with tsserver directly?

I'll give it a try.

Still, if I execute the command you provided on ts file the scheme is added as expected:

07:34:15 msg_show   := vim.lsp.buf_request_sync(0, "textDocument/definition", vim.lsp.util.make_position_params(0))         targetUri = "file:///Users/user/file.ts"
ibhagwan commented 1 day ago

@skoch13, can you try with the latest commit https://github.com/ibhagwan/fzf-lua/commit/72752f7d783b3a56f4e27c8592600646b991a928?

skoch13 commented 1 day ago

@ibhagwan

works perfectly! thank you

ibhagwan commented 1 day ago

@ibhagwan

works perfectly! thank you

Ty for the update @skoch13, it’s technically an ugly hack for what I consider an LSP or neovim bug (the API should accept non fully qualified URIs) but happy to know the workaround works :)