Skip to content
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

Feature Request: Allow for hiding individual aliases #1859

Open
Keboo opened this issue Sep 22, 2022 · 5 comments
Open

Feature Request: Allow for hiding individual aliases #1859

Keboo opened this issue Sep 22, 2022 · 5 comments
Labels
Area-API enhancement New feature or request
Milestone

Comments

@Keboo
Copy link
Member

Keboo commented Sep 22, 2022

My current process for renaming aliases looks like the following:

  1. Create a new symbol (lets take an Option for example) with the new aliases I want
  2. Mark the previous symbol IsHidden=true
  3. When executing a command, I am not forced to pull both values and determine which gets precedence despite this really only being a single thing. This also makes doing things like validation more difficult.

Alternatively, I could always modify the help build to hide to aliases that I don't want displayed. However, at present, this would require more code, than the above solution.

What I would like is the ability to mark individual aliases as hidden so that I only have a single symbol to manage.

@KalleOlaviNiemitalo
Copy link

An IdentifierSymbol.AddHiddenAlias(string) method would be discoverable enough for this. No need to complicate the constructors.

Should the hidden aliases be entirely hidden from completions, typo corrections, and help; or should they be available from completions if the user has already typed part of the hidden alias and there is no other completion? I think I'd prefer hiding them entirely.

The implementation might then have public IReadOnlyCollection<string> HiddenAliases { get; } and this would be used only in:

  • CommandLineConfiguration.ThrowIfInvalid()
  • Option.HasAliasIgnoringPrefix(string alias)
  • StringExtensions.ValidTokens(this Command command)

but not in:

  • ArgumentConversionResult.FormatErrorMessage(Argument argument, Type expectedType, string value, LocalizationResources localizationResources)
  • Command.GetCompletions(CompletionContext context)
  • CommandResultExtensions.TryGetValueForOption(this CommandResult commandResult, IValueDescriptor valueDescriptor, out object? value) -- i.e. do not match the hidden aliases to IValueDescriptor.ValueName
  • HelpBuilder.Default.GetIdentifierSymbolUsageLabel(IdentifierSymbol symbol, HelpContext context)
  • Option.GetLongestAlias()
  • ParseResult.GetCompletions(int? position)
  • TypoCorrection.GetPossibleTokens(Command targetSymbol, string token)

@jonsequitur jonsequitur added Area-API enhancement New feature or request labels Sep 23, 2022
@jonsequitur
Copy link
Contributor

Should the hidden aliases be entirely hidden from completions, typo corrections, and help; or should they be available from completions if the user has already typed part of the hidden alias and there is no other completion? I think I'd prefer hiding them entirely.

Agreed. So far, IsHidden means it is hidden everywhere.

@Keboo
Copy link
Member Author

Keboo commented Sep 23, 2022

Yes I would expect them to be hidden everywhere.

@mitchcapper
Copy link

Yes given #133 and the seemingly lack of support for considering any case insensitivity say --Start vs --start we add aliases but this clutters up help and tab completion significantly. If we can hide those options that would be great.

@KalleOlaviNiemitalo
Copy link

As dotnet/runtime#68578 is labelled "api-approved", it seems the API is about to be frozen. If hiding individual aliases is not supported in 2.0 GA, can it be implemented later? It will no longer be possible to remove public ICollection<string> Aliases { get; } from CliOption, but perhaps public ICollection<CliAlias> CliAliases { get; } could be added on the side as a more detailed view to the same collection. I just worry that the two properties could be deemed too confusing in API review and then we'd never get the feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-API enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants