rustup and cargo completions

[ycardon]

The rustup and cargo completions are generated by a script (in the same manner of kubectl and helm).

❯ rustup completions --help
rustup-completions 
Generate tab-completion scripts for your shell

USAGE:
    rustup completions [ARGS]

FLAGS:
    -h, --help    Prints help information

ARGS:
    <shell>       [possible values: zsh, bash, fish, powershell, elvish]
    <command>     [possible values: rustup, cargo]

If the sourcing is done "naively" by the user, he can choose between 1/ executing the rustup completions zsh rustup inside .zshrc and delay zsh start or 2/ cache the command result in a file that could not be up to date when updating rust.

NB: There could be other tools working the same way, I'm wondering if it would be interesting that z4h offer to the user a "generic" way of caching/auto-updating for these use cases, instead of having you to update z4h each time there is a new tool.

edit: maybe this could also increase the modularity of your code (for z4h v4)

[romkatv]

Thanks for the feature request. Useful as always.

I've added completion wrappers for rustup and cargo. I'm surprised that rustup doesn't generate completions for rustc. Do you know how one is supposed to enable them?

Completions for rustup seem broken. rustup <TAB> lists local files in addition to subcommands even though rustup --help doesn't show any usage that would require a file as the first argument. rustup completions <TAB> lists subcommands once again when it should be listing zsh, bash, fish, etc.

There could be other tools working the same way

I hope not. What rustup does looks pretty bad. It's also unclear how to generalize completion wrappers that I've already written. Even thought it looks like different tools have similar ways of describing their completions, the wrappers for them must be different.

Currently I've implemented the same kind of wrapper both for rustup and cargo but this isn't the right thing to do. While it's OK to require that the user restarts zsh when rustup command gets updated in order to pick up new completions, requiring the same for cargo is inappropriate. The reason being that it's normal to have multiple rust toolchains installed on the same machine and to use them simultaneously. There is even support for per-project overrides via rustup override set .... Ideally, cargo should be completed by the completer function from the same toolchain. Doing this with reasonable performance is possible but quite tricky. Powerlevel10k has code that performs very fast detection of rust toolchain changes, and z4h could do the same. Maybe I'll do this later. Having non-generic completion wrappers gives me freedom here. If need be, I can make completions for cargo better.

If you think about it, requiring that users put anything in their ~/.zshrc to enable completions for a certain command is bad UX. There is no downside to having completions, so it should just work. ~/.zshrc is for things that aren't universally desired by all users. For example, some users might want Ctrl+Backspace to delete one character while others would prefer it to delete one word. Thus bindkey '^H' ... is a good candidate for inclusion in ~/.zshrc.

[ycardon]

I'm surprised that rustup doesn't generate completions for rustc. Do you know how one is supposed to enable them?

There is a brew formula for it but I don't know what it worth. I just sometime compile rust projects but I'm not developing with it.

Completions for rustup seem broken

There is an open issue that has the same title... not the problem you are mentioning but it seems there is room for improvement.

If you think about it, requiring that users put anything in their ~/.zshrc to enable completions for a certain command is bad UX.

I understand this -along with un-compromized speed- is your one of your design goal for z4h (it must work out of the box with most of the current tools) and as a newcomer to zsh I really won't complain about it.. My proposal was a hard-wired professional reflex and your current reactivity proves it's completely unnecessary.

Speaking of development stacks: what about node (which is my daily bread) ? Do you have a recommendation for it ? I'm using https://github.com/lukechilds/zsh-nvm and I'm quite happy with it.

[romkatv]

There is a brew formula for it but I don't know what it worth.

It's packaging https://github.com/roshan/rust-bash-completion: 3 stars, last commit 5 years ago. For zsh there is https://github.com/rust-lang/zsh-config: 39 stars, last commit 6 years ago, archived repo (cannot submit issues, send PRs, etc.) Basically, no completions for rustc except for something people wrote for themselves a long time ago. That's fine with me. I was worried that I'm missing some way to generate rustc completions similar to how cargo completions are generated, but this isn't the case.

I understand this -along with un-compromized speed- is your one of your design goal for z4h (it must work out of the box with most of the current tools) and as a newcomer to zsh I really won't complain about it.. My proposal was a hard-wired professional reflex and your current reactivity proves it's completely unnecessary.

Right. I want user configs to be reserved for options that require judgement. If I don't provide a way to fix zsh4humans inadequacies via user configs, then users will complain and I'll fix the issue so that it just works for everyone. In the short term it may be inconvenient when you bump into issues but over the long term it should pay off because 1) I often can provide better integration than what users could do by themselves and 2) what I'll do in zsh4humans will benefit all existing and future users.

Speaking of development stacks: what about node (which is my daily bread) ? Do you have a recommendation for it ? I'm using https://github.com/lukechilds/zsh-nvm and I'm quite happy with it.

It's slow and somewhat buggy but not worse than an average zsh script you would find on the internet.