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: Make ghcup list --hide-old (-o) the default #1115

Closed
mpilgrem opened this issue Aug 11, 2024 · 4 comments
Closed

Feature request: Make ghcup list --hide-old (-o) the default #1115

mpilgrem opened this issue Aug 11, 2024 · 4 comments

Comments

@mpilgrem
Copy link
Contributor

mpilgrem commented Aug 11, 2024

For ghcup tui, not showing old versions is the default and key 'a' toggles between the default and showing old versions also.

Currently ghcup list shows old versions also, and --hide-old (-o, for short) is passed to filter out all old versions (not just GHC old versions, as stated by in-app help).

As ghcup list grows in length, I suggest that --hide-old is the sensible default, with a flag for --no-hide-old.

@hasufell
Copy link
Member

That would be a breaking change. People are using ghcup list in scripts (github runners even used to). So any changes to that could cause large breakage. Sure, we could have a different default when --raw-format is passed, but that would complicate the interface (and you can still sed/grep even without it).

@mpilgrem
Copy link
Contributor Author

It is a minor thing now ghcup tui supports Windows. In my case, 'muscle memory' means that I still command ghcup list in error (as what I need to avoid the 'noise' of old versions is ghcup list -o or ghcup tui).

Is there a reason why the output of ghcup list does not reveal the Old tag - it does not distinguish 'Old' from 'other non-Latest'?

@hasufell
Copy link
Member

hasufell commented Aug 11, 2024

Is there a reason why the output of ghcup list does not reveal the Old tag - it does not distinguish 'Old' from 'other non-Latest'?

Since it's kind of an arbitrary selection, I'm not sure having that information permanently visible is useful.


Regarding the output length: we could drop into the pager when the output exceeds terminal height (or is used as part of a pipe... it's possible to detect that programmatically... git does that too).

@hasufell
Copy link
Member

The other discussion about pager is here: #1118

@hasufell hasufell closed this as not planned Won't fix, can't repro, duplicate, stale Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants