Feature implementation from commits 5a138f1..680936a #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Small change to fix a couple of broken links in active_help.md Signed-off-by: Vui Lam <[email protected]>
Since cpuguy83/go-md2man 2.0.5 no paraTag is written after "SEE ALSO". With go-md2man 2.0.4: .SH SEE ALSO .PP \fBroot-bbb(1)\fP, \fBroot-ccc(1)\fP With go-md2man 2.0.5: .SH SEE ALSO \fBroot-bbb(1)\fP, \fBroot-ccc(1)\fP See: cpuguy83/go-md2man#122 Signed-off-by: Mikel Olasagasti Uranga <[email protected]>
spf13#2206) fix compatibility with go versions before go1.17 diff: cpuguy83/go-md2man@v2.0.5...v2.0.6 Signed-off-by: Sebastiaan van Stijn <[email protected]>
When running tests in verbose mode (or other options), tests involving Cobra may fail if the test does not explicitly set Command.args to an empty slice; in this case, Cobra defaults to using `os.Args`, which will contain arguments passed to the test (such as `-v` (verbose)). Commits e576205 and 1ef0913 implemented a workaround for this when running (unit) tests for Cobra itself, but this check is specifig to Cobra (checking for `cobra.test`), and don't work on Windows (which will have a `.exe` extension), This patch implements a more universal check, so that users of Cobra as a module also benefit from this workaround. go1.21 and up provides a `testing.Testing()` utility ([1]); as the Cobra module still supports Go1.16 and up, an alternative implementation was added for older versions, based on golang.org/x/mod/lazyregexp [2]. Before this patch: go test -c -o foo.test ./foo.test -test.run TestNoArgs --- FAIL: TestNoArgs (0.00s) args_test.go:37: Unexpected output: Error: unknown command "TestNoArgs" for "c" Usage: c [flags] Flags: -h, --help help for c args_test.go:40: Unexpected error: unknown command "TestNoArgs" for "c" FAIL After this patch: go test -c -o foo.test ./foo.test -test.run TestNoArgs PASS [1]: https://pkg.go.dev/testing#Testing [2]: https://cs.opensource.google/go/x/mod/+/refs/tags/v0.19.0:internal/lazyregexp/lazyre.go;l=66-78 Signed-off-by: Sebastiaan van Stijn <[email protected]> Signed-off-by: Marc Khouzam <[email protected]> Co-authored-by: Marc Khouzam <[email protected]>
…pf13#2210) The completion code attempts to detect whether a flag can be specified more than once, and therefore should provide completion even if already set. Currently, this code depends on conventions used in the pflag package, which uses an "Array" or "Slice" suffix or for some types a "stringTo" prefix. Cobra allows custom value types to be used, which may not use the same convention for naming, and therefore currently aren't detected to allow multiple values. The pflag module defines a [SliceValue] interface, which is implemented by the Slice and Array value types it provides (unfortunately, it's not currently implemented by the "stringTo" values). This patch adds a reduced interface based on the [SliceValue] interface mentioned above to allow detecting Value-types that accept multiple values. Custom types can implement this interface to make completion work for those values. I deliberately used a reduced interface to keep the requirements for this detection as low as possible, without enforcing the other methods defined in the interface (Append, Replace) which may not apply to all custom types. Future improvements can likely still be made, considering either implementing the SliceValue interface for the "stringTo" values or defining a separate "MapValue" interface for those types. Possibly providing the reduced interface as part of the pflag module and to export it. [SliceValue]: https://github.com/spf13/pflag/blob/d5e0c0615acee7028e1e2740a11102313be88de1/flag.go#L193-L203 Signed-off-by: Sebastiaan van Stijn <[email protected]> Signed-off-by: Marc Khouzam <[email protected]> Co-authored-by: Marc Khouzam <[email protected]>
Signed-off-by: zhuhaicity <[email protected]>
Also document that NoFilesCompletion and FixedCompletion can be used with RegisterFlagCompletionFunc.
…her completions (spf13#1743) Signed-off-by: Toni Kangas <[email protected]> Signed-off-by: Marc Khouzam <[email protected]> Co-authored-by: Marc Khouzam <[email protected]> Co-authored-by: Jeffrey Faer <[email protected]>
…pf13#1956) * Restructure code to let linker perform deadcode elimination step Cobra, in its default configuration, will execute a template to generate help, usage and version outputs. Text/template execution calls MethodByName and MethodByName disables dead code elimination in the Go linker, therefore all programs that make use of cobra will be linked with dead code elimination disabled, even if they end up replacing the default usage, help and version formatters with a custom function and no actual text/template evaluations are ever made at runtime. Dead code elimination in the linker helps reduce disk space and memory utilization of programs. For example, for the simple example program used by TestDeadcodeElimination 40% of the final executable size is dead code. For a more realistic example, 12% of the size of Delve's executable is deadcode. This PR changes Cobra so that, in its default configuration, it does not automatically inhibit deadcode elimination by: 1. changing Cobra's default behavior to emit output for usage and help using simple Go functions instead of template execution 2. quarantining all calls to template execution into SetUsageTemplate, SetHelpTemplate and SetVersionTemplate so that the linker can statically determine if they are reachable Co-authored-by: Marc Khouzam <[email protected]>
In the bash shell we used to print ActiveHelp messages on every tab-press. In the example below, notice the "Command help" line which is ActiveHelp: bash-5.1$ tanzu context u[tab] Command help: Configure and manage contexts for the Tanzu CLI bash-5.1$ tanzu context u[tab] Command help: Configure and manage contexts for the Tanzu CLI bash-5.1$ tanzu context u unset (Unset the active context so that it is not used by default.) use (Set the context to be used by default) bash-5.1$ tanzu context u Above, on the first [tab] press, only the ActiveHelp is printed. On the second [tab] press, the ActiveHelp is printed again, followed by a re-print of the command-line, followed by the completions choices. The separation between ActiveHelp and completion choices makes the ActiveHelp harder to see. Furthermore, I find the double printing of the ActiveHelp string to look bad. Note that for zsh, the UX is different and that ActiveHelp messages are printed at the same time as the completion choices. This commit aligns the UX for ActiveHelp in bash with the one for zsh: if there are other completions to be shown, the ActiveHelp messages are printed at the same time. New behaviour: 1- ActiveHelp is no longer printed on the first [tab] press. This is better aligned with bash's standard approach. 2- ActiveHelp is printed on the second [tab] press, above the completion choices, with a `--` delimiter. 3- If there are no completion choices, the `--` delimiter is omitted. This behaviour is the same as what is done for zsh (except that for zsh the first [tab] press immediately shows completion choices). Below is the above example, but using this commit. Notice the more concise and easier to read completion output: bash-5.1$ tanzu context u[tab][tab] Command help: Configure and manage contexts for the Tanzu CLI -- unset (Unset the active context so that it is not used by default.) use (Set the context to be used by default) bash-5.1$ tanzu context u Signed-off-by: Marc Khouzam <[email protected]>
…pf13#2228) Happens at least if a flag is marked as filename, with "" given as extensions.
Follow-up to spf13#1956. This commit allows a program to reset any of the tree templates to their default behaviour, as it was possible to do before the change of spf13#1956. Signed-off-by: Marc Khouzam <[email protected]>
We recently added a CLI to a our Conduit project, and we use Cobra to power it. Here's a blog post mentioning it https://meroxa.com/blog/introducing-the-new-conduit-cli:-a-powerful-tool-for-managing-your-pipelines/
The code has also been refactored to use a type alias for completion and a completion helper Using a type alias is a non-breaking change and it makes the code more readable and easier to understand. Signed-off-by: ccoVeille <[email protected]> Co-authored-by: Marc Khouzam <[email protected]>
![codeowlai[bot]](https://avatars.githubusercontent.com/in/1259765?s=60&v=4){kind=small}
| GetSlice() []string | ||
| } | ||
|
|
||
| func (c *Command) getCompletions(args []string) (*Command, []Completion, ShellCompDirective, error) { |
There was a problem hiding this comment.
🐛 Correctness Issue
Breaking API Change: Return Type Modified.
The return type of getCompletions() was changed from []string to []Completion which will break all existing callers of this function.
Current Code (Diff):
- func (c *Command) getCompletions(args []string) (*Command, []string, ShellCompDirective, error) {
+ func (c *Command) getCompletions(args []string) (*Command, []Completion, ShellCompDirective, error) {📝 Committable suggestion
‼️ IMPORTANT
Trust, but verify! 🕵️ Please review this suggestion with the care of a code archaeologist - check that it perfectly replaces the highlighted code, preserves all lines, maintains proper indentation, and won't break anything in production. Your future self will thank you! 🚀
Suggested change
| func (c *Command) getCompletions(args []string) (*Command, []Completion, ShellCompDirective, error) { | |
| func (c *Command) getCompletions(args []string) (*Command, []Completion, ShellCompDirective, error) { |
🔄 Dependencies Affected
completions.go
Function: Command.getCompletions
Issue: All callers of getCompletions() will break as they expect []string return type but will now receive []Completion
Suggestion: Update all callers of getCompletions() to handle the new []Completion return type instead of []string
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains changes from a range of commits from the original repository.
Commit Range:
5a138f1..680936aFiles Changed: 18 (11 programming files)
Programming Ratio: 61.1%
Commits included:
... and 5 more commits