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

add 'gohack list' or shell completion support #61

Open
josharian opened this issue Sep 30, 2019 · 4 comments
Open

add 'gohack list' or shell completion support #61

josharian opened this issue Sep 30, 2019 · 4 comments

Comments

@josharian
Copy link
Contributor

Many package paths are long. To ease typing, I suggest either/both of:

  • add gohack list, which will emit all package paths in the module, for easy copy/paste
  • add shell completion, so that the tab key can do the work for me

Opinions?

@myitcv
Copy link
Collaborator

myitcv commented Oct 1, 2019

Would go list (with suitable flags) not suffice here, for both? I say that assuming shell completion can be made to work given the line-based output of a command

@josharian
Copy link
Contributor Author

go list -m all is a decent approximation. But gohack can do a bit better, by also indicating which modules are currently being hacked on (and what directory they are in). For the modules that are also being hacked on, it could also print whether the hacked version is dirty. Also, go list -m all emits version numbers, which aren't as relevant for gohack.

Maybe the command should be gohack status.

@josharian
Copy link
Contributor Author

Erm. There is already a gohack status.

I was about to start working on a PR, but I think I'll wait for more feedback.

@myitcv
Copy link
Collaborator

myitcv commented Oct 2, 2019

go list -f can probably give us whatever we need from a completions perspective, but the status showing "dirty" for -vcs hacks would definitely be useful.

josharian added a commit to josharian/gohack that referenced this issue Dec 14, 2019
Subcommands have been introduced.
They don't perfectly match this structure,
but it is reasonably close.
The TODO comment contains a few as-yet unimplemented
ideas for other features and subcommands:

* get -u already has a todo in the get flags
* rm isn't implemented, but it is also not likely to be forgotten if/when it is needed
* dir has lots of overlap with rogpeppe#61, and the issue tracker is a better place to discuss

Given that, the outdated comment no longer pulls its weight. Cull it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants