Allow handing of completion by an external command's shell completion
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by tracing usage's existing completion handling and the shell-framework entry points it already supports. Compare the requested external-command flow with the current complete and arg var=#true model, including how words belonging to the command argument are passed onward. Done means a defined approach for delegated completion, support for nested arguments such as terraform plan -o, and coverage for the supported shell frameworks.
Written by the indexing model from the issue text.
Description
We have a wrapper script around terraform and it would be nice to be able to profit from the completion available for the wrapped command.
What we currently do:
arg "<layer>" help="Layer to run"
arg "<command>" var=#true help="Terraform command to run"
complete "command" descriptions=#true run=#"terraform -help 2>&1 | awk '/^ [a-z]/ {cmd=$1; $1=""; sub(/^ +/,""); print cmd":"$0}'"#
It would be nice if the completion could not require awk and support further stuff like terraform plan -o completing to -out.
To demonstrate what would need to happen technically (with fish as an example):
arg "<layer>" help="Layer to run"
arg "<command>" var=#true help="Terraform command to run"
complete "command" descriptions=#true run=#"fish -c 'complete -C "terraform {{words[CURRENT]}"'"#
// The `words[CURRENT]` is not really correct, as we need all the words that belong to the `command` arg for this to work properly.
// (I don't know if that is currently possible)
As usage already must be aware of all the completion frameworks it supports, I feel like handing that over would be natural.
I am not sure that the arg var=#true style to model this situation is the best way to support this new functionality. I just chose this to bring the point across.
- Dominant language
- Rust
- Stars
- 1k
- Forks
- 59
- Avg merge
- 5h 58m
- Merged PRs (30d)
- 362
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from jdx/usage
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 70/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100