In memory LSP for filepath completion

[antonk52]

I made filepaths_ls which is a plain lua language server that provides completion for filepaths. I explored similar approach in the past with basics_ls which required nodejs.

The motivation was me never being able to use built in filepath completion reliably <C-x><C-f>. This was due to 2 reasons

1. It resolves relative filepaths from cwd instead of current buffer. This can be worked around by dynamically updating lcd which may break plugins. This default behavior was always unintuitive to me.
2. It expands environment variables without a way to opt out. So $HOME/<C-x><C-f> inserts /users/me/ and opens a completion menu if there are multiple items.

Mainstream neovim completion plugins like blink.cmp and nvim-cmp with cmp-path reuse the same completion menu for all completion sources like lsp, filepaths etc. The same applies to mainstream GUI text editors i.e. VS Code, Zed, Sublime Text.

This can be useful for those who rely on builtin completion or use plugins that enhance builtin completion like mini.completion. Opposed to standalone completion plugins like blink.cmp or nvim-cmp.

---

Aside: I used to think that built in filepath completion could be improved by introducing a setting to force buffer relative path resolution by default. But perhaps having a built in LSP is an easier way both for implementation and more discoverable from the novice user side. I wonder if there is any interest in upstreaming something similar one day?

[justinmk]

any interest in upstreaming something similar one day?

Probably. The main friction is deciding how to document it and present it. That includes "how to enable it" (and finding a "pattern" since we presumably will want other in-process LSes in the future), should it be an option or "opt-in plugin", explaining how it fits with <C-x><C-f> (is that still needed or should it be deemphasized?) etc.

If we see a compelling story there then that makes it really easy to say "yes" :)

[brianhuster]

What about vim.lsp.enable("nvim.something")?

Though I would prefer if file path completion server is enabled by default

[justinmk]

oh, treating it as a builtin "lsp config" seems quite reasonable ...

[antonk52]

I think there is a case for a few builtin LS'. There is already one for vim.pick buffer. There are multiple features that enhance vimdoc experience which too can be unified under a built in LS like go to definition for tags, code actions to execute code blocks, etc.

The filepath completion is more broad as it attaches to user buffers. Perhaps it can be built in and disabled by default and be enabled with vim.lsp.enable('nvim-filepath') like Brian suggested. This way it should not interfere with existing functionality. This way it should provide a good way to opt in for users to test this and if proven successful, it can be enabled by default in the future. the main reason I pick disabled by default since the LS completion is currently disabled out of the box.

Due to my experience I find it hard to id usecases for the <C-x><C-f> completion. But if the LS approach is proven succesful I can see a future where the old completion is superseded by the proposed LS and <C-x><C-f> becomes a key map to trigger the LS completion with filtering for filepath LS.