Sorry, accidentally deleted the branch while pruning stale branches on my fork

I'm not too happy about the implementation, but it's the least intrusive way I could think of to do it. I added a fallback field to CustomCompletions that's checked after calling its fetch() method. If fallback is true, then we use file completions afterwards.

I'm thinking about another solution, what about making CustomCompletions directly depends on FileCompletions as a fallback completion. Like this:

pub struct CustomCompletion<T: Completer> {
    stack: Stack,
    decl_id: DeclId,
    line: String,
    fallback: T
}

Then if it evals Value::Nothing, we can run fallback.fetch directly. In this way, we don't need to expose a boolean fallback field.

@WindSoilder Great idea! That also means CustomCompletions can continue implementing the Completer trait

Sorry if this is off-topic, but there should be a way to configure the external completer so that it overrides internal completion. That way, completion becomes entirely customizable by the user (instead of trying to guess what the user wants in these kind of situations).

TLDR

• Add the config option to override internal
• Add/define builtin command to retrieve internal completions based on its pipeline input. The result could also include extra metadata, like what the parser is expecting next and the partial string it's basing its suggestions on, etc.
• External completer can do whatever it wants: fallback however it wants, merge its own suggestions, only use it's suggestions, only use internal suggestions, sort however it wants, complete env variables, complete snippets even, etc. It could even choose not to parse the input at all. etc. etc. etc.

This would be very nice.

@tmillr That seems like it could be useful, but could you open a separate issue asking for that feature? I see you added this to #14822, but that's a huge issue and this feature request could get lost there.

@WindSoilder Implemented your solution, it works well.