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.

Sign up for GitHub

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

Jump to bottom

Consider showing less output for rg -h #189

Closed
djc opened this issue Oct 19, 2016 · 10 comments
Closed

Consider showing less output for rg -h #189

djc opened this issue Oct 19, 2016 · 10 comments
Labels
question An issue that is lacking clarity on one or more points.

Comments

@djc
Copy link

djc commented Oct 19, 2016

This might be a bit subjective, but for me the result of rg -h was somewhat suboptimal in giving me much more output than expected, thus quickly scrolling the most useful stuff off the screen.

I think I would like it better if rg -h did not show the Less common options and File management options by default, instead showing a line at the bottom that refers to some extra switch to make -h/--help more verbose.
@BurntSushi
Copy link
Owner

FWIW, rg --help | less should help, and it's what I normally do when the output of --help is large.

I'm not opposed to doing this, but I'm not 100% sure we should because I'm not a fan of making flags harder to discover.

@BurntSushi BurntSushi added the question An issue that is lacking clarity on one or more points. label Oct 19, 2016
@BurntSushi BurntSushi mentioned this issue Oct 24, 2016
Closed
@lilyball
Copy link

ag --help shows a one-line (or sometimes two-line) description of all flags. Maybe rg --help should do the same, and then something like rg --help-options to show the more verbose output? That would make it easier to skim the options to find what you want.

@djc
Copy link
Author

djc commented Oct 25, 2016

Yeah, that's another option that would maybe help discovery without making flags harder to discover.

@BurntSushi
Copy link
Owner

I do like that idea better.

On Oct 24, 2016 18:29, "Kevin Ballard" notifications@github.com wrote:

ag --help shows a one-line (or sometimes two-line) description of all
flags. Maybe rg --help should do the same, and then something like rg
--help-options to show the more verbose output? That would make it easier
to skim the options to find what you want.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#189 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAb34sXeJ6zOhiqgotAM55IPJy_rcWJiks5q3TFZgaJpZM4Ka3MS
.

@BurntSushi BurntSushi mentioned this issue Nov 13, 2016
Merged
BurntSushi added a commit that referenced this issue Nov 13, 2016
@BurntSushi
Switch from Docopt to Clap.
d9bd654 
There were two important reasons for the switch:

1. Performance. Docopt does poorly when the argv becomes large, which is
   a reasonable common use case for search tools. (e.g., use with xargs)
2. Better failure modes. Clap knows a lot more about how a particular
   argv might be invalid, and can therefore provide much clearer error
   messages.

While both were important, (1) made it urgent.

Note that since Clap requires at least Rust 1.11, this will in turn
increase the minimum Rust version supported by ripgrep from Rust 1.9 to
Rust 1.11. It is therefore a breaking change, so the soonest release of
ripgrep with Clap will have to be 0.3.

There is also at least one subtle breaking change in real usage.
Previous to this commit, this used to work:

    rg -e -foo

Where this would cause ripgrep to search for the string `-foo`. Clap
currently has problems supporting this use case
(see: clap-rs/clap#742),
but it can be worked around by using this instead:

    rg -e [-]foo

or even

    rg [-]foo

and this still works:

    rg -- -foo

This commit also adds Bash, Fish and PowerShell completion files to the
release, fixes a bug that prevented ripgrep from working on file
paths containing invalid UTF-8 and shows short descriptions in the
output of `-h` but longer descriptions in the output of `--help`.

Fixes #136, #189, #210, #230
@devsnek
Copy link

devsnek commented May 3, 2020 •
edited
Loading

I'm not sure if something has happened since this, but the help output is once again enormous, and I usually end up doing rg --help | rg "thing i'm looking for".

@BurntSushi
Copy link
Owner

rg --help has been basically "the man page" for years. Nothing has changed recently. If you want a denser view, then use rg -h.

@devsnek
Copy link

devsnek commented May 3, 2020

Oh interesting. I'm not used to -h and --help doing different things. Perhaps they should be merged and manpages can be generated separately?

@BurntSushi
Copy link
Owner

No. man pages aren't available everywhere. The behavior is staying as is.

@lilyball
Copy link

lilyball commented May 4, 2020

rg -h still has a large header block that looks identical to the one from rg --help. Perhaps we could slim down the rg -h header block for just a couple of lines? It seems odd that even the USAGE section isn't immediately visible in rg -h | less on a 80x24 terminal.

@BurntSushi
Copy link
Owner

Indeed, I'd be open to that. The initial header block has indeed slowly grown larger over the years.

BurntSushi added a commit that referenced this issue May 8, 2020
@BurntSushi
doc: shorten -h/--help prelude
be4e2bc 
It has grown quite long. It would be nice if we could shorten this only
when -h is used and keep it long for --help, but it seems clap doesn't
let this happen. (It does have `about` and `long_about` options, but
they don't work, even when I disable the use of the template.)

The longer prelude is now only available in the man page.

This addresses #189.
BurntSushi added a commit that referenced this issue May 9, 2020
@BurntSushi
doc: shorten -h/--help prelude
28f2a93 
It has grown quite long. It would be nice if we could shorten this only
when -h is used and keep it long for --help, but it seems clap doesn't
let this happen. (It does have `about` and `long_about` options, but
they don't work, even when I disable the use of the template.)

The longer prelude is now only available in the man page.

This addresses #189.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question An issue that is lacking clarity on one or more points.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@lilyball @djc @BurntSushi @devsnek