Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmp.add_filetype_source() call for an unset filetype should inherit default sources #1217

Open
austinliuigi opened this issue Feb 14, 2025 · 0 comments
Labels
feature New feature or request

Comments

@austinliuigi
Copy link

Feature Description

I think it would be more intuitive if a call to cmp.add_filetype_source(<ft>, <source>), for a filetype that you haven't configured, would inherit the default sources instead of setting <source> as the only one for that filetype. Since it's usually plugins that call cmp.add_filetype_source(), a user may find it confusing that their default sources don't work on some filetypes.

For example, the codecompanion.nvim plugin adds its own source for its chat buffers.

With the current implementation, a user would need to duplicate their default sources to a per_filetype entry, e.g. sources.per_filetype.codecompanion in order to use them in codecompanion chat buffers.

Instead, I propose that this should be inverted: default sources should be inherited by default, and the user could choose to not have them for specific filetypes by setting an empty table for the respective per_filetype entries. This would be consistent in the sense that any non-configured per-filetype filetypes would use the default sources.


if config.sources.per_filetype[filetype] == nil then config.sources.per_filetype[filetype] = {} end
local sources = config.sources.per_filetype[filetype]
--- @cast sources string[]
table.insert(sources, source)

I think initializing config.sources.per_filetype to a copy of the default sources rather than an empty table would be sufficient. The current implementation doesn't seem to check for duplicates, so I don't know if that should be added or not.

Please let me know any thoughts on this. Thank you!

@austinliuigi austinliuigi added the feature New feature or request label Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant