Support completion for command alias arguments (i.e. flags, options, option values, positional arguments, and/or subcommands) #847

Activity

1. rgoldberg

   changed the title [-]Support completion for command alias flags, options, option values, arguments, and/or subcommands[/-] [+]Support completion for command alias argumemts (i.e. flags, options, option values, positional arguments, and/or subcommands)[/+] on Jan 12, 2026
2. rgoldberg

   changed the title [-]Support completion for command alias argumemts (i.e. flags, options, option values, positional arguments, and/or subcommands)[/-] [+]Support completion for command alias arguments (i.e. flags, options, option values, positional arguments, and/or subcommands)[/+] on Jan 12, 2026
3. rauhul

   added a parent issue on Jan 12, 2026

   • ☂️ Command Aliases Support #849
4. Dave861 commented on Jul 4, 2026

   

   Dave861

   on Jul 4, 2026

   More actions

   Hi @rgoldberg — I looked into this and reproduced it. With a subcommand configured as commandName: "build", aliases: ["b"], running mytool b —release works, but in the generated completion scripts the alias never appears.

   The zsh script's subcommand dispatch is:

   case "${words[1]}" in
   build|help)
       "_mytool_${words[1]}" && ret=0
   

   so mytool b -- then tab matches nothing and offers no completions, while mytool build -- followed by tab works. I noticed alias data is already carried through ToolInfoV0 (populated in DumpHelpGenerator), but the zsh/bash/fish generators only consult each subcommand's commandName at the dispatch site, not its aliases.

   My proposed approach is as follows (like the issue's default behavior): when dispatching completion for a subcommand's arguments, match the subcommand's aliases in addition to its commandName, while continuing to not emit alias names in the suggestion list.

   I'd include tests covering both halves: the alias completes its flags/options/subcommands, and the alias name isn't offered as a suggestion.

   I noticed you're active in this area and mentioned you might pick this up yourself. I'm planning to take this on unless you're already working on it. Happy to defer if so, would love to contribute if possible!
5. rgoldberg commented on Jul 4, 2026

   

   rgoldberg

   on Jul 4, 2026

   CollaboratorAuthor

   More actions

   @Dave861 I haven't had time to implement this myself, and wasn't planning on getting to it anytime soon.

   I don't know what behavior the project leads want, so you might want to solicit their opinion before implementing anything, as they might prefer different behavior (given that aliases aren't supported yet, but should be in some way, any PR should be easily pivotable to the leads' desired behavior).

   Feel free to submit a PR. I'll be happy to provide feedback and/or help, but I can't dictate what the behavior should be, only offer my opinions.

   Just to check: is there any difference between your proposed behavior & my proposed behavior? (I didn't notice one, but I haven't had time to do more than skim everything here)

   FYI: I don't see much point in a b alias for build when completion exists.

   Short options & flags make sense, though, because:

   • there's more likely to be more of them than subcommands in a command line, occupying more space
   • individually, they're likelier to be longer than subcommands, occupying more space
   • there's more likely to be more flags & options than subcommands available to be used, likely requiring more characters and/or tabs to choose each completion
   • subcommands provide a scope for everything that follows compared to only the next 0 (flags) or 1 (options) shell terms, so keeping subcommands longer helps indicate the larger structure of to a command line
6. Dave861 commented on Jul 4, 2026

   

   Dave861

   on Jul 4, 2026

   More actions

   Thanks @rgoldberg, appreciate the fast, thorough response.

   On your question: no, I don't think there's any meaningful difference between our proposed behaviors. We're both describing the issue's default, don't offer alias names among subcommand-name completions, but once an alias has been typed, complete its flags/options/values/positional args/subcommands.

   Good point on b/build, I agree, subcommand aliases buy less than short flags/options once completion exists, for the reasons you list. That doesn't change this issue's scope, but I'll keep the change small and flexible so it's easy to pivot.

   @natecook1000 @rauhul, since aliases aren't yet reflected in completions and this is user-facing, I'd like to confirm the desired default before implementing. My proposal (matching the issue):

   1. A subcommand invoked by an alias completes exactly as it does under its canonical name (flags/options/args/subcommands).
   2. Alias names are not offered as subcommand-name suggestions by default.
   3. I'd defer the optional "also suggest alias names" setting to a follow-up, keeping this PR to the default above.

   Does that match what you'd want, or would you prefer different behavior? I'll include tests for both halves (alias completes its args; alias name isn't suggested) and cover zsh/bash/fish.
7. rgoldberg commented on Jul 4, 2026

   

   rgoldberg

   on Jul 4, 2026

   CollaboratorAuthor

   More actions

   @Dave861 Thanks for the confirmation.

   If & when support is added for a configuration option to selectively complete aliases themselves (instead of their children), it could be handled many ways:

   • only globally for all aliases
   • a CommandConfiguration.shouldCompleteAliases instance property with enum AliasCompletion with cases none & some([HierarchyOption]), with HierarchyOption: OptionSet, with self & descendants static constants (obviously, many of these should be renamed; I just wanted to get the gist across); the setting would apply unless overridden in a subcommand
   • if you want to allow a parent command to override the alias completion setting of a subcommand, an alternate subcommands: [(ParsableCommand.Type, AliasCompletion)]
8. Dave861 commented on Jul 5, 2026

   

   Dave861

   on Jul 5, 2026

   More actions

   @Dave861 Thanks for the confirmation.

   If & when support is added for a configuration option to selectively complete aliases themselves (instead of their children), it could be handled many ways:

   • only globally for all aliases
   • a CommandConfiguration.shouldCompleteAliases instance property with enum AliasCompletion with cases none & some([HierarchyOption]), with HierarchyOption: OptionSet, with self & descendants static constants (obviously, many of these should be renamed; I just wanted to get the gist across); the setting would apply unless overridden in a subcommand
   • if you want to allow a parent command to override the alias completion setting of a subcommand, an alternate subcommands: [(ParsableCommand.Type, AliasCompletion)]

   Appreciate it, noted for the follow-up. I'll structure it so v1 stays flexible
9. rgoldberg commented on Jul 5, 2026

   

   rgoldberg

   on Jul 5, 2026

   CollaboratorAuthor

   More actions

   I forgot to mention that nil would mean do whatever the ancestor commands configured (equivalent to .none if the root command), with CommandConfiguration.init(…, shouldCompleteAliases: AliasCompletion? = nil, …).

   👍React with 👍1Reacted by David Retegan