fix(uri): don't use full path for custom schema

[sigmaSd]

deno lsp uses a custom schema deno:

uri_from_bufnr returns the full path of the buf file but this doesn't work with custom schema

This fixes the last remaining bug here neovim/nvim-lspconfig#2005 relative dependencies inside virtual text document is not resolved correctly

Notes:

• maybe if relative_name:match("deno:") should become if is_custom_schema(realtive_name) where is_custom_schema returns true for any schema that matches URI_SCHEME_PATTERN but is not equal to file:///
• this changes fixes all my issues with denols (with some minor modifications that I can pr later)

This is more to start a discussion I thought showing code is easier to discuss then raising an issue

[sigmaSd]

For example here is how coc-deno is currently working-around the issue https://github.com/fannheyward/coc-deno/blob/1b42c38a9d78baf14ac90de2347a4e240f020de5/src/extension.ts#L126

[sigmaSd]

Btw the full path in the buffer name is coming from vim.fn.bufadd it seems to add the full path to most things except the one that start with atleast double slash, as in:

• deno:// it will keep it the same
• deno:/ will become ${currrentPath}/deno:/

for example in deno lsp case:

deno:/https/deno.land/x/simple_shell%400.13.0/mod.ts becomes /home/user/dev/deno:/https/deno.land/x/simple_shell%400.13.0/mod.ts

[ii14]

I don't think handling every custom URI scheme globally is a good solution. In my opinion a better alternative would be to make URI translation configurable per LSP client. I'm not sure what are all the contexts where vim.uri is used from, so solving this issue could require some more fundamental changes.

[sigmaSd]

My personal opinion is

• The best solution is to fix vim recognition of url scheme which is not conformant to spec, and fixing it will make this just work
• I wasn't planning to keep it hard-coded like this if relative_name:match("deno:") now that I read some spec I think what I would replace it with is is_not_special_scheme https://url.spec.whatwg.org/#special-scheme

[sigmaSd]

• For the first option vim seems to 'recognize' scheme here

  neovim/src/nvim/path.c

  Line 1755 in 54a165d

  int path_is_url(const char *p)

  :// seems to be also used in other places in the code-base changing it maybe a breaking change
• I updated the pr with the second option

In my opinion a better alternative would be to make URI translation configurable per LSP client

I'm fine with any option that works but I'm not sure how to implement this

[mfussenegger]

I think the proper solution is to fix the URI recognition.
Where is the conversion happening? Is

neovim/runtime/lua/vim/uri.lua

Line 128 in 6264aa5

return vim.fn.bufadd(uri_to_fname(uri))

The problem, or bufadd itself?

I think bufname returns the path relative to the current directory, but with LSP the workspace root might be different than the current directory, so this approach here could break with that.

And there's also #19534 which kinda contradicts with this PR

[sigmaSd]

Yes the problem is in bufadd

[sigmaSd]

bufadd calls eventually path_is_url which has the problem

neovim/src/nvim/path.c

Line 1755 in 54a165d

int path_is_url(const char *p)

[sigmaSd]

Personally I want to just change if (strncmp(p, "://", 3) == 0) { to if (strncmp(p, ":/", 2) == 0) { (the spec only requires : but I think this is good enough) but no idea what other implications can this have.

It could be debated that any thing that relied on this bug is incorrect though.

[ii14]

The problem is that unlike Windows, Linux only reserves the / character in file paths. Changing it from :// to : would most likely break editing some files with : in the name, for example :edit foo:bar.txt. It's not something that should be that common, but still something you might occasionally encounter.

Maybe this could be disambiguated by :e ./foo:bar.txt

[lewis6991]

I haven't followed the thread, so sorry if this has been covered, but why can't relative_name be fname here?

[ii14]

nvim_buf_get_name always returns the full path. When you create a buffer with a name deno:some/file, the current directory will be prepended to it (/home/user/deno:some/file). With bufname() it prefers returning the short name (deno:some/file), but it's generally not 100% reliable.

[lewis6991]

Then this is all a nasty hack. nvim_buf_get_name is doing exactly the right thing. We shouldn't be relying on the cwd the parse the correct uri.

deno should be using something like deno://some/file?

[ii14]

deno:some/file is technically compliant with the spec, vim just treats it like a normal path.

Two potential solutions we have right now is to start complying with the URI spec, or translate paths to and from deno://

[lewis6991]

How feasible do we think it is to comply with the URI spec? I think that would be preferable if it doesn't break too much.

[ii14]

It should be straightforward, all checks for :// have to be replaced with :, I think it's just in few places. But yeah, the question is how much of the user stuff would it break.

[sigmaSd]

I opened #19797 to propose changing path_is_url

[justinmk]

Closing for #19797