`expand('%')` returns absolute path in file having LSP diagnostics about neovim

[zeertzjq]

Cannot reproduce. Maybe it only happens in WSL?

[hexium310]

I tried it on Mac and reproduced it. Did you wait a few seconds for the LSP to launch after opening empty.lua?

on WSL

on Mac

[zeertzjq]

Oops, I misspelled .editorconfig. It's strange that this bug only happens when there is a .editorconfig file present.

[hexium310]

Actually, it does not occur when there is a .editorconfig file, but when I am under the directory existing root marker files (or directories) for LSP. It occurs when there is a .git directory or editing root_marker such as local root_markers = { 'minimal.lua' } in minimal.lua.

[mfussenegger]

I think this is kinda expected. The behavior of expand('%') depends on how the buffer was added.
When neovim receives diagnostics from the language server it calls bufadd for the file uris/filenames

E.g. compare:

• Open nvim without file
• :call bufadd("/absolute/path/to/file")
• :e to/file
• :echo expand("%")

With

• Open nvim without file
• :call bufadd("relative/path")
• :e relative/path
• :echo expand("%")

Regarding .git/.editorconfig: .git is a folder and .editorconfig is a file so you get a different root_dir. Compare vim.fn.fnamemodify(".git/", ":p:h") with vim.fn.fnamemodify(".editorconfig", ":p:h") in a folder where both exists. I use something like this because of that difference:

function M.find_root(markers, path)
  path = path or api.nvim_buf_get_name(0)
  local match = vim.fs.find(markers, { path = path, upward = true })[1]
  if match then
    local stat = vim.loop.fs_stat(match)
    if stat and stat.type == "directory" then
      return vim.fn.fnamemodify(match, ':p:h:h')
    end
    return vim.fn.fnamemodify(match, ':p:h')
  end
  return nil
end