-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
feat(complete)!: Allow alternative shells for dynamic completions #5018
Conversation
Moving them to environment args looks like a good idea. I'm not sure about the generic For implementing fish I'd need to differentiate between flags and values starting with This is why I proposed the completion context, to allow moving this logic into the shell specific code: |
I think we can re-evaluate and evolve this as we go. We don't have to support every case for every shell up front. For example I will say that we will not be having per-shell parsers; that would go counter to what this is trying to accomplish. If there is a policy we want, like not showing flags for new completions, then we should consider applying that universally. If we really need some level of customization for the current field, we can try to decouple that from parsing but that is adding complexity I'd like to avoid. |
yeah, the It was more about what is the interface between the two, my Idea was to decouple parsing and the actual strings outputted by the completion more, i.e. the parser wouldn't directly return strings with possible completions but something with more detail, something that can differentiate what kind of completion item something is, i.e. flag, value, etc. But I also see that we could just try to have the most capable completions regardless of shell, i.e. pick for everything the shell providing the best1 features and implement that for all shells. Footnotes
|
This covers the API changes from #4177.
This switches the communication from the registration script to the completion code from flags to env variables. This is less helpful for hand-experimenting which is a minority case. This does mean we don't have to try to abstract every single shell and allows easier evolution since we don't have to spend time bike shedding what the contract should be.