Behavior of add_filetype_source API

[MeanderingProgrammer]

From a somewhat recent documentation update: 9202b26

Equivalent to adding the source via sources.per_filetype.<filetype> = { <source_id>, inherit_defaults = true }
in the config, appending to the default list.
If the user already has a source defined for the filetype, inherit_defaults will default to false.

I don't believe this is the case right? It seems like the behavior is inherit_defaults = false unless the user config specifies otherwise for each filetype. At lease based on the current implementation of get_enabled_provider_ids: https://github.com/saghen/blink.cmp/blob/main/lua/blink/cmp/sources/lib/init.lua#L55-L101

Was this in preparation for a change to the API in a future release?

Or do the V2 changes make all of this irrelevant and in-process LSPs are the way to create completion sources going forward.

[saghen]

You're right, not sure when that bug slipped in but fixed it in 40380e7. Will make a release shortly

Or do the V2 changes make all of this irrelevant and in-process LSPs are the way to create completion sources going forward

They will but they're quite a ways out (waiting for 0.12 to stabilize and it's a lot of work). But in-process LSPs of course work well with V1 so it's still a good idea to migrate to them if you've got the time for it.

If it helps, here's an example of the path source using a slightly modified version of the vim.lsp.server PR in the neovim repo. It's untested but the general idea should be there.

[MeanderingProgrammer]

Thanks for the quick fix!

I did end up creating an in-process LSP for my plugin a little while back after seeing it in crates.nvim, thought it made sense to be more agnostic about what's actually doing the completions.

Naturally the completion engine integrations existed before and still have users. Maybe when v2 is released I can use it as a reason to remove them entirely :P For the time being will keep them around.

I took a look at your implementation and it's fairly similar but it looks like you're adding a vim.lsp.config layer, while I just call vim.lsp.start. I imagine that's to let users modify settings via vim.lsp.config rather than passing them through your plugin, which is an interesting approach. To get the settings in the request would you call vim.lsp.config.path directly or would you do something more like an LSP and use dispatchers.server_request('workspace/configuration', { ... })?