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

use ALL instead of ANY for fallback_for #328

Closed
MeanderingProgrammer opened this issue Nov 13, 2024 · 0 comments · Fixed by #465
Closed

use ALL instead of ANY for fallback_for #328

MeanderingProgrammer opened this issue Nov 13, 2024 · 0 comments · Fixed by #465
Labels
feature New feature or request sources Specific source provider or the system as a whole
Milestone

Comments

@MeanderingProgrammer
Copy link

MeanderingProgrammer commented Nov 13, 2024

Feature Description

The definition of fallback_for is if any of these providers return 0 items, it will fallback to this provider.

I think rather than checking if any provider returns 0 items it might be more convenient to check that all providers return 0 items when setting up multiple completion providers.

As an example completion provider lets take crates.nvim which provides version completions in Cargo.toml files. When I use this provider ideally what happens is I do not get buffer items, only the ones returned from crates. Currently the way I would set this up is something like:

sources = {
  providers = {
    crates = { ... },
    buffer = {
      fallback_for = { 'lsp', 'crates' },
    },
  },
}

However this does not quite work since in Cargo.toml files the lsp provider returns 0 items so the buffer provider will run. Worse though is that in code files with an active LSP the crates provider returns 0 items so the buffer provider will run there as well now.

Ideally there would be a way to specify "only run this provider if non of the others have items". I think this is similar in concept to how nvim-cmp groups work. My idea to make this possible is to simply change the existing fallback_for to an all instead of an any. If this isn't possible than a new mechanism to make this possible would be great, maybe something like ignore_for, where meeting the fallback conditions makes the provider able to run but if any provider in ignore_for has items than it does not get run.

@MeanderingProgrammer MeanderingProgrammer added the feature New feature or request label Nov 13, 2024
@Saghen Saghen changed the title feature: use ALL instead of ANY for fallback_for use ALL instead of ANY for fallback_for Nov 28, 2024
@Saghen Saghen added this to the Sources v2 milestone Nov 28, 2024
@Saghen Saghen added the sources Specific source provider or the system as a whole label Nov 28, 2024
@Saghen Saghen mentioned this issue Dec 6, 2024
9 tasks
@Saghen Saghen closed this as completed in 7ff28da Dec 10, 2024
Saghen added a commit that referenced this issue Dec 10, 2024
Large rewrite of how sources are handled, adding support for async providers/timeouts, tree based fallbacks, dynamically adding sources and some other goodies

Closes #386
Closes #219
Closes #328
Closes #331
Closes #312
Closes #454
Closes #444
Closes #372
Closes #475
Saghen added a commit that referenced this issue Dec 11, 2024
Large rewrite of how sources are handled, adding support for async providers/timeouts, tree based fallbacks, dynamically adding sources and some other goodies

Closes #386
Closes #219
Closes #328
Closes #331
Closes #312
Closes #454
Closes #444
Closes #372
Closes #475
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request sources Specific source provider or the system as a whole
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants