-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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 hinting of arg value types for zsh/fish completion #1793
Conversation
Is still missing some functionality and needs some polish, but I wanted to open a PR to get some feedback first. |
Is it possible to extract the type of data to do value hinting automatically in addition to this, like making use of rust types like |
Good idea, I will look into it. |
/// .value_hint(ValueHint::CommandWithArguments) | ||
/// # ; | ||
/// ``` | ||
pub fn value_hint(mut self, value_hint: ValueHint) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like by convention, I should also use self.setb(ArgSettings::TakesValue);
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, can there only be one value hint, can't it be a merged value hint or a list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, can you imagine any use cases for combining multiple hints for one argument?
Seems it would be quite an edge case. For situations like that, I think it would be better to provide some "escape hatch" to manually override parts of the generated completion file, rather than trying to accommodate such weirdness.
src/build/arg/value_hint.rs
Outdated
/// Command name looked up from PATH or full path to executable | ||
CommandName, | ||
/// A command and each argument as multiple strings | ||
CommandWithArguments, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The CommandWithArguments
is a very important use case for implementing command wrappers, but also very different from all the others. For it to work correctly, it assumes that the arg is a positional argument, has multiple(true)
and app has AppSettings::TrailingVarArg
.
Can/should I add these checks to some place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd go with setting multiple(true)
and AppSettings::TrailingVarArg
automatically and documenting this behavior.
Also, can we do something about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, just a little question.
Honestly, I'd prefer to keep the scope of this PR as small as possible. This is my first contribution to clap, I'm still learning Rust, that's already lots of new things. I haven't used bash for years, never even tried fish. |
@intgr agree, go on don't worry. we can discuss that in a separate issue/pr |
I doubt this is possible with raw clap since it's "stringy typed", no way to get type information. This might be possible with derive but it would be a very simple heuristic (is it path or not). This hint is not a big burden, anyway. |
I can try to improve |
I use fish here but I don't seemed to see something equivalent (maybe I don't have much experience with completions), IIRC fish could use custom command to do these kind of completion hinting and there is no limit on what could be hint, this is both good news (it is very flexible since we can just inject some code) and bad news (there is just too many things we can hint) for us. |
As is the usual way with fish, rather than create lots of specialized options fish simply uses the same tools as the end user to provide useful functionality. https://fishshell.com/docs/current/index.html#useful-functions-for-writing-completions |
Hey, sorry about this, but you should probably rebase on master since we touched clap_generate this week. |
@benjumanji Actually yeah, I looked into fish already on Thursday and whipped up some rudimentary support. It's surprisingly sane compared to bash and zsh completion definitions. |
288891b
to
278ba99
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that is why I use fish. I would have added support later on anyway, but it's not priority clap wise. Glad you could finish it.
Please write here once you consider the PR complete so that we can review. Thanks.
Yeah this is still WIP and not entirely ready for a review yet. Meanwhile, some points for bikeshedding:
|
|
Yeah it makes sense, I'm just thinking if I should stop calling it a "hint" now. |
Or, we could keep it as a hint, but add an assert that any arg hinted as |
I'd go for |
I know my opinion means nothing here, but @intgr I'm am so excited for this to land! I have a new cli project that I kicked off last night and was going to pause it to work on this but you have basically already implemented everything I need. EDIT: I also think ValueKind is a better name, and I am really for the embedding of a bit of shell to do fully dynamic completions. I don't think it will be reasonably possible to avoid this, and it isn't untrusted input or anything insane like that. At least I don't think it will be possible to avoid without clap itself basically reimplementing a ton of stuff, which seems like a really bad trade off. |
@benjumanji I definitely see the value in custom completion functions or some other "escape hatch" mechanism, but it seems more complicated, less portable between shells and not something I need myself right now. However, it's worth thinking ahead to what that API would look like, to make sure I'm not painting clap into a corner somehow with my current work. Personally I can't imagine any way they would interact, apart from completion generators which would prefer the custom completion over |
278ba99
to
5d2a6dc
Compare
By the way, do completion test snapshots (e.g. |
No easier way for now :( |
@intgr knock knock |
553292a
to
0df6c30
Compare
Hey people. I'm on vacation now and hopefully with enough motivation to move this forward. Sorry for the wait. :) One part of this MR that I have postponed is the YAML (de)serialization part, if anyone can give me some quick pointers -- where to start -- that would be great. |
Just implement |
ae206b7
to
e3b45ad
Compare
I ended up creating a new btw I also found it confusing that there are 2 different macros with the name |
I think the initial feature set is now complete, feel free to start reviewing. There are issues with the fish generator, which already existed before my changes:
I'm not very interested in fixing these issues in the fish generator. Does that seem OK? Should I keep my fish changes in or back them out from this PR? I believe my changes don't make anything worse, but it's easier to notice these problems now. |
d49374f
to
3827ac0
Compare
I also added a support matrix table to
Footnotes
|
0b3d8fb
to
89bda82
Compare
Ping? Rebased to latest master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay. I'm not the best person to review this kind of PR because I have very shallow experience with completions and stuff, but others doesn't seem to be very interested, so here we go.
I say the PR is ready. Everything that's supposed to work does work (except for that wasn't working before), documentation is in place, and I think the code is good. Great job!
Could you please fix the test (we changed extensions) and ensure cargo fmt & clippy
is applied? And the squash the commits.
There are some odd completion issues with examples/value_hints.rs, which disappear if I remove the -n __fish_use_subcommand. It seems the generator shouldn't add it if the App doesn't use subcommands at all?
That's right. It's not your problem until you say so.
dae4900
to
c5b4e89
Compare
Adds new method/attribute `Arg::value_hint`, taking a `ValueHint` enum as argument. The hint can denote accepted values, for example: paths, usernames, hostnames, commands, etc. This initial implementation supports hints for the zsh and fish completion generators, support for other shells can be added later.
Thanks for the feedback! Doh, I did not notice that the tests broke with my last rebase. Fixed! Are you happy with the naming of |
c5b4e89
to
64ee0f8
Compare
Can we add |
That was then, this is now. I now think that using "right" words in public API is more important than being 100% technically correct. What you did here, it was to allow hinting about the type first and foremost; stuff like assets and implications was brought after. It was a convince, not the intention. And the intention was to hint. I'm pretty happy with how this went along. bors r+ |
Build succeeded: |
Great, will be looking forward to the next (beta) release :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! I was unfortunately busy to review this immediately. But I don't see any issues at all.
Adds new method/attribute
Arg::value_hint
, taking aValueHint
enumas argument. The hint can denote accepted values, for example: paths,
usernames, hostnames, commands, etc.
This initial implementation supports hints for the zsh and fish
completion generators, support for other shells can be added later.