Allow the completed command to be an alias #1764
Labels
A-completion
Area: completion generator
C-enhancement
Category: Raise on the bar on expectations
E-medium
Call for participation: Experience needed to fix: Medium / intermediate
Comments
|
We are always open to PRs. I am not exactly good at the completion scripts. I couldn't even get zsh running locally 😞 |
|
My bash completion days are also behind me (and I happily flushed 90% I knew from memory). That being said, this patch seems to be doing the trick: --- src/completions/bash.rs
+++ src/completions/bash.rs
@@ -33,8 +33,8 @@ impl<'a, 'b> BashGen<'a, 'b> {
for i in ${{COMP_WORDS[@]}}
do
case "${{i}}" in
- {name})
- cmd="{name}"
+ "${{1}}")
+ cmd="${{1}}"
;;
{subcmds}
*)
@@ -43,7 +43,7 @@ impl<'a, 'b> BashGen<'a, 'b> {
done
case "${{cmd}}" in
- {name})
+ "${{1}}")
opts="{name_opts}"
if [[ ${{cur}} == -* || ${{COMP_CWORD}} -eq 1 ]] ; then
COMPREPLY=( $(compgen -W "${{opts}}" -- "${{cur}}") )I'll probably open a PR unless I find an issue... |
|
I believe this is fixed. |
Mind sharing details as to why you believe that to be the case? |
|
@pickfire How is this fixed? |
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 5, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user-unfriendly environment variable based approach to making the process conditional. But also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In so doing we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 5, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
|
Because there was a pull request for it? Ah, I didn't notice it was closed instead of merged. |
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 5, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
|
And it was closed without merging because it didn't actually fix the issue. |
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 7, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 10, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 11, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
d-e-s-o
added a commit
to d-e-s-o/nitrocli
that referenced
this issue
Apr 11, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time, by separately generating the clap parsers out-of-band, or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or using some user-unfriendly environment variable based approach for making the process conditional. But there is also the fact that specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). In our version we provide a utility program that emits the completion script to standard output, accepting regular command line options itself. In doing so we allow for installation time generation of the completion script or installation of the utility itself, the output of which could be sourced on demand -- depending on the user's preference.
d-e-s-o
added a commit
to d-e-s-o/apcacli
that referenced
this issue
May 16, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
d-e-s-o
added a commit
to d-e-s-o/apcacli
that referenced
this issue
May 16, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
d-e-s-o
added a commit
to d-e-s-o/apcacli
that referenced
this issue
Jun 12, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
d-e-s-o
added a commit
to d-e-s-o/apcacli
that referenced
this issue
Jun 21, 2020
This change adds support for generating a bash completion script. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
This was referenced Nov 14, 2021
This was referenced Dec 6, 2021
epage
changed the title
epage
added
the
E-medium
22 tasks
d-e-s-o
added a commit
to d-e-s-o/btrfs-backup
that referenced
this issue
Feb 20, 2023
This change adds support for generating shell completion scripts for the program. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
d-e-s-o
added a commit
to d-e-s-o/btrfs-backup
that referenced
this issue
Feb 20, 2023
This change adds support for generating shell completion scripts for the program. If sourced, the shell will provide tab completions for the program's arguments. There are two possible approaches provided by clap for going about generating shell completion functionality: either at build time by separately generating the clap parsers out-of-band or at run time, as an option to the main program itself. We are generally not too much in favor of a run time approach, as it means less inspectability at installation time and more overhead in the form of code crammed into the main binary. Hence, with this change we take the "build time" approach. Clap recommends hooking the generation up in build.rs, but this seems like an inflexible choice. For one, that is because it would mean unconditionally generating this file or some user unfriendly environment variable based approach to making the process conditional, but also because specifying the command for which to generate the script should likely be configurable. That is a limitation of the completion script that clap generates (see clap-rs/clap#1764). Instead, we provide a utility program that emits the completion script to standard output, accepting regular command line options itself.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be great if the shell completion was more flexible in what commands it applies to. Let's say I have a program
fooand a completion scriptfoo.bashas generated byclap. If I sourcefoo.bashI now have completion forfoo's arguments. Fine.However, what if I have aliased
ftofoo? Naturally, I'd want to have completion forfas well. Usually that's not a problem. The completion script just registers the completion functionality for a certain command. E.g.,complete -F _foo -o bashdefault -o default foocan be found in
foo.bash.Unfortunately, though, just changing that to
complete -F _foo -o bashdefault -o default fdoesn't work, because, well, the script itself has the command/name coded into its logic.
That doesn't have to be the case, however, as
gitfor example shows. Here all I have to do is register my alias as follows:and bam,
ghas completion.Would be great to have such a more flexible completion script.
The text was updated successfully, but these errors were encountered: