2017-05-29 13:02:09 -07:00
|
|
|
#compdef rg
|
2017-07-06 19:04:14 -05:00
|
|
|
|
|
|
|
|
##
|
|
|
|
|
# zsh completion function for ripgrep
|
|
|
|
|
#
|
2020-03-15 20:43:13 -04:00
|
|
|
# Run ci/test-complete after building to ensure that the options supported by
|
2017-07-06 19:04:14 -05:00
|
|
|
# this function stay in synch with the `rg` binary.
|
|
|
|
|
#
|
2018-08-20 08:57:54 -05:00
|
|
|
# For convenience, a completion reference guide is included at the bottom of
|
|
|
|
|
# this file.
|
2017-07-06 19:04:14 -05:00
|
|
|
#
|
2018-06-25 20:09:24 -05:00
|
|
|
# Originally based on code from the zsh-users project — see copyright notice
|
|
|
|
|
# below.
|
2017-07-06 19:04:14 -05:00
|
|
|
|
|
|
|
|
_rg() {
|
2018-06-25 20:09:24 -05:00
|
|
|
local curcontext=$curcontext no='!' descr ret=1
|
|
|
|
|
local -a context line state state_descr args tmp suf
|
|
|
|
|
local -A opt_args
|
|
|
|
|
|
|
|
|
|
# ripgrep has many options which negate the effect of a more common one — for
|
|
|
|
|
# example, `--no-column` to negate `--column`, and `--messages` to negate
|
|
|
|
|
# `--no-messages`. There are so many of these, and they're so infrequently
|
|
|
|
|
# used, that some users will probably find it irritating if they're completed
|
|
|
|
|
# indiscriminately, so let's not do that unless either the current prefix
|
|
|
|
|
# matches one of those negation options or the user has the `complete-all`
|
|
|
|
|
# style set. Note that this prefix check has to be updated manually to account
|
|
|
|
|
# for all of the potential negation options listed below!
|
|
|
|
|
if
|
2018-08-19 12:11:41 -05:00
|
|
|
# We also want to list all of these options during testing
|
|
|
|
|
[[ $_RG_COMPLETE_LIST_ARGS == (1|t*|y*) ]] ||
|
|
|
|
|
# (--[imnp]* => --ignore*, --messages, --no-*, --pcre2-unicode)
|
|
|
|
|
[[ $PREFIX$SUFFIX == --[imnp]* ]] ||
|
2022-04-26 21:19:09 -05:00
|
|
|
zstyle -t ":completion:${curcontext}:" complete-all
|
2018-06-25 20:09:24 -05:00
|
|
|
then
|
|
|
|
|
no=
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# We make heavy use of argument groups here to prevent the option specs from
|
|
|
|
|
# growing unwieldy. These aren't supported in zsh <5.4, though, so we'll strip
|
|
|
|
|
# them out below if necessary. This makes the exclusions inaccurate on those
|
|
|
|
|
# older versions, but oh well — it's not that big a deal
|
|
|
|
|
args=(
|
|
|
|
|
+ '(exclusive)' # Misc. fully exclusive options
|
|
|
|
|
'(: * -)'{-h,--help}'[display help information]'
|
|
|
|
|
'(: * -)'{-V,--version}'[display version information]'
|
2019-04-14 16:46:02 -04:00
|
|
|
'(: * -)'--pcre2-version'[print the version of PCRE2 used by ripgrep, if available]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2018-09-04 21:39:05 -04:00
|
|
|
+ '(buffered)' # buffering options
|
|
|
|
|
'--line-buffered[force line buffering]'
|
|
|
|
|
$no"--no-line-buffered[don't force line buffering]"
|
|
|
|
|
'--block-buffered[force block buffering]'
|
|
|
|
|
$no"--no-block-buffered[don't force block buffering]"
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(case)' # Case-sensitivity options
|
|
|
|
|
{-i,--ignore-case}'[search case-insensitively]'
|
|
|
|
|
{-s,--case-sensitive}'[search case-sensitively]'
|
|
|
|
|
{-S,--smart-case}'[search case-insensitively if pattern is all lowercase]'
|
|
|
|
|
|
|
|
|
|
+ '(context-a)' # Context (after) options
|
|
|
|
|
'(context-c)'{-A+,--after-context=}'[specify lines to show after each match]:number of lines'
|
|
|
|
|
|
|
|
|
|
+ '(context-b)' # Context (before) options
|
|
|
|
|
'(context-c)'{-B+,--before-context=}'[specify lines to show before each match]:number of lines'
|
|
|
|
|
|
|
|
|
|
+ '(context-c)' # Context (combined) options
|
|
|
|
|
'(context-a context-b)'{-C+,--context=}'[specify lines to show before and after each match]:number of lines'
|
|
|
|
|
|
|
|
|
|
+ '(column)' # Column options
|
|
|
|
|
'--column[show column numbers for matches]'
|
|
|
|
|
$no"--no-column[don't show column numbers for matches]"
|
|
|
|
|
|
|
|
|
|
+ '(count)' # Counting options
|
2018-08-19 12:11:41 -05:00
|
|
|
{-c,--count}'[only show count of matching lines for each file]'
|
|
|
|
|
'--count-matches[only show count of individual matches for each file]'
|
2019-10-16 19:03:00 -07:00
|
|
|
'--include-zero[include files with zero matches in summary]'
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
$no"--no-include-zero[don't include files with zero matches in summary]"
|
2018-08-19 12:11:41 -05:00
|
|
|
|
|
|
|
|
+ '(encoding)' # Encoding options
|
|
|
|
|
{-E+,--encoding=}'[specify text encoding of files to search]: :_rg_encodings'
|
|
|
|
|
$no'--no-encoding[use default text encoding]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2020-02-28 00:58:56 +09:00
|
|
|
+ '(engine)' # Engine choice options
|
|
|
|
|
'--engine=[select which regex engine to use]:when:((
|
|
|
|
|
default\:"use default engine"
|
|
|
|
|
pcre2\:"identical to --pcre2"
|
|
|
|
|
auto\:"identical to --auto-hybrid-regex"
|
|
|
|
|
))'
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ file # File-input options
|
2018-08-26 23:58:58 -05:00
|
|
|
'(1)*'{-f+,--file=}'[specify file containing patterns to search for]: :_files'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ '(file-match)' # Files with/without match options
|
|
|
|
|
'(stats)'{-l,--files-with-matches}'[only show names of files with matches]'
|
|
|
|
|
'(stats)--files-without-match[only show names of files without matches]'
|
|
|
|
|
|
|
|
|
|
+ '(file-name)' # File-name options
|
|
|
|
|
{-H,--with-filename}'[show file name for matches]'
|
2019-04-14 13:15:19 -04:00
|
|
|
{-I,--no-filename}"[don't show file name for matches]"
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2018-08-25 21:08:42 -04:00
|
|
|
+ '(file-system)' # File system options
|
|
|
|
|
"--one-file-system[don't descend into directories on other file systems]"
|
|
|
|
|
$no'--no-one-file-system[descend into directories on other file systems]'
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(fixed)' # Fixed-string options
|
|
|
|
|
{-F,--fixed-strings}'[treat pattern as literal string instead of regular expression]'
|
|
|
|
|
$no"--no-fixed-strings[don't treat pattern as literal string]"
|
|
|
|
|
|
|
|
|
|
+ '(follow)' # Symlink-following options
|
|
|
|
|
{-L,--follow}'[follow symlinks]'
|
|
|
|
|
$no"--no-follow[don't follow symlinks]"
|
|
|
|
|
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
+ '(generate)' # Options for generating ancillary data
|
|
|
|
|
'--generate=[generate man page or completion scripts]:when:((
|
|
|
|
|
man\:"man page"
|
|
|
|
|
complete-bash\:"shell completions for bash"
|
|
|
|
|
complete-zsh\:"shell completions for zsh"
|
|
|
|
|
complete-fish\:"shell completions for fish"
|
|
|
|
|
complete-powershell\:"shell completions for PowerShell"
|
|
|
|
|
))'
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ glob # File-glob options
|
|
|
|
|
'*'{-g+,--glob=}'[include/exclude files matching specified glob]:glob'
|
|
|
|
|
'*--iglob=[include/exclude files matching specified case-insensitive glob]:glob'
|
|
|
|
|
|
2019-08-01 16:08:58 -05:00
|
|
|
+ '(glob-case-insensitive)' # File-glob case sensitivity options
|
|
|
|
|
'--glob-case-insensitive[treat -g/--glob patterns case insensitively]'
|
|
|
|
|
$no'--no-glob-case-insensitive[treat -g/--glob patterns case sensitively]'
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(heading)' # Heading options
|
|
|
|
|
'(pretty-vimgrep)--heading[show matches grouped by file name]'
|
|
|
|
|
"(pretty-vimgrep)--no-heading[don't show matches grouped by file name]"
|
|
|
|
|
|
|
|
|
|
+ '(hidden)' # Hidden-file options
|
2020-09-10 20:32:54 -03:00
|
|
|
{-.,--hidden}'[search hidden files and directories]'
|
2018-06-25 20:09:24 -05:00
|
|
|
$no"--no-hidden[don't search hidden files and directories]"
|
|
|
|
|
|
2019-04-14 17:39:37 -04:00
|
|
|
+ '(hybrid)' # hybrid regex options
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
'--auto-hybrid-regex[DEPRECATED: dynamically use PCRE2 if necessary]'
|
|
|
|
|
$no"--no-auto-hybrid-regex[DEPRECATED: don't dynamically use PCRE2 if necessary]"
|
2019-04-14 17:39:37 -04:00
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(ignore)' # Ignore-file options
|
2019-01-26 13:40:12 -05:00
|
|
|
"(--no-ignore-global --no-ignore-parent --no-ignore-vcs --no-ignore-dot)--no-ignore[don't respect ignore files]"
|
|
|
|
|
$no'(--ignore-global --ignore-parent --ignore-vcs --ignore-dot)--ignore[respect ignore files]'
|
2018-07-22 10:42:32 -04:00
|
|
|
|
2019-01-20 17:32:34 -08:00
|
|
|
+ '(ignore-file-case-insensitive)' # Ignore-file case sensitivity options
|
|
|
|
|
'--ignore-file-case-insensitive[process ignore files case insensitively]'
|
|
|
|
|
$no'--no-ignore-file-case-insensitive[process ignore files case sensitively]'
|
|
|
|
|
|
2019-11-07 11:23:57 +11:00
|
|
|
+ '(ignore-exclude)' # Local exclude (ignore)-file options
|
|
|
|
|
"--no-ignore-exclude[don't respect local exclude (ignore) files]"
|
|
|
|
|
$no'--ignore-exclude[respect local exclude (ignore) files]'
|
|
|
|
|
|
2018-07-22 10:42:32 -04:00
|
|
|
+ '(ignore-global)' # Global ignore-file options
|
|
|
|
|
"--no-ignore-global[don't respect global ignore files]"
|
|
|
|
|
$no'--ignore-global[respect global ignore files]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ '(ignore-parent)' # Parent ignore-file options
|
|
|
|
|
"--no-ignore-parent[don't respect ignore files in parent directories]"
|
|
|
|
|
$no'--ignore-parent[respect ignore files in parent directories]'
|
|
|
|
|
|
|
|
|
|
+ '(ignore-vcs)' # VCS ignore-file options
|
|
|
|
|
"--no-ignore-vcs[don't respect version control ignore files]"
|
|
|
|
|
$no'--ignore-vcs[respect version control ignore files]'
|
2020-02-17 15:34:59 -05:00
|
|
|
|
|
|
|
|
+ '(require-git)' # git specific settings
|
2020-02-17 14:43:22 -05:00
|
|
|
"--no-require-git[don't require git repository to respect gitignore rules]"
|
|
|
|
|
$no'--require-git[require git repository to respect gitignore rules]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2020-03-15 11:04:47 -04:00
|
|
|
+ '(ignore-dot)' # .ignore options
|
2019-01-26 13:40:12 -05:00
|
|
|
"--no-ignore-dot[don't respect .ignore files]"
|
|
|
|
|
$no'--ignore-dot[respect .ignore files]'
|
|
|
|
|
|
2020-03-15 11:04:47 -04:00
|
|
|
+ '(ignore-files)' # custom global ignore file options
|
|
|
|
|
"--no-ignore-files[don't respect --ignore-file flags]"
|
|
|
|
|
$no'--ignore-files[respect --ignore-file files]'
|
|
|
|
|
|
2018-08-19 12:11:41 -05:00
|
|
|
+ '(json)' # JSON options
|
|
|
|
|
'--json[output results in JSON Lines format]'
|
|
|
|
|
$no"--no-json[don't output results in JSON Lines format]"
|
2018-08-03 17:26:22 -04:00
|
|
|
|
2018-08-19 12:11:41 -05:00
|
|
|
+ '(line-number)' # Line-number options
|
2018-06-25 20:09:24 -05:00
|
|
|
{-n,--line-number}'[show line numbers for matches]'
|
|
|
|
|
{-N,--no-line-number}"[don't show line numbers for matches]"
|
|
|
|
|
|
2018-08-19 12:11:41 -05:00
|
|
|
+ '(line-terminator)' # Line-terminator options
|
|
|
|
|
'--crlf[use CRLF as line terminator]'
|
|
|
|
|
$no"--no-crlf[don't use CRLF as line terminator]"
|
|
|
|
|
'(text)--null-data[use NUL as line terminator]'
|
2018-08-03 17:26:22 -04:00
|
|
|
|
2019-04-15 06:51:51 -04:00
|
|
|
+ '(max-columns-preview)' # max column preview options
|
2019-04-15 07:04:57 -04:00
|
|
|
'--max-columns-preview[show preview for long lines (with -M)]'
|
2019-04-15 06:51:51 -04:00
|
|
|
$no"--no-max-columns-preview[don't show preview for long lines (with -M)]"
|
2019-04-13 18:35:24 -04:00
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(max-depth)' # Directory-depth options
|
2023-11-21 18:07:18 -05:00
|
|
|
{-d,--max-depth}'[specify max number of directories to descend]:number of directories'
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
'--maxdepth=[alias for --max-depth]:number of directories'
|
2018-06-25 20:09:24 -05:00
|
|
|
'!--maxdepth=:number of directories'
|
|
|
|
|
|
|
|
|
|
+ '(messages)' # Error-message options
|
|
|
|
|
'(--no-ignore-messages)--no-messages[suppress some error messages]'
|
|
|
|
|
$no"--messages[don't suppress error messages affected by --no-messages]"
|
|
|
|
|
|
|
|
|
|
+ '(messages-ignore)' # Ignore-error message options
|
|
|
|
|
"--no-ignore-messages[don't show ignore-file parse error messages]"
|
|
|
|
|
$no'--ignore-messages[show ignore-file parse error messages]'
|
|
|
|
|
|
|
|
|
|
+ '(mmap)' # mmap options
|
|
|
|
|
'--mmap[search using memory maps when possible]'
|
|
|
|
|
"--no-mmap[don't search using memory maps]"
|
|
|
|
|
|
2018-08-19 12:11:41 -05:00
|
|
|
+ '(multiline)' # Multiline options
|
2018-08-03 17:26:22 -04:00
|
|
|
{-U,--multiline}'[permit matching across multiple lines]'
|
2018-08-19 12:11:41 -05:00
|
|
|
$no'(multiline-dotall)--no-multiline[restrict matches to at most one line each]'
|
|
|
|
|
|
|
|
|
|
+ '(multiline-dotall)' # Multiline DOTALL options
|
|
|
|
|
'(--no-multiline)--multiline-dotall[allow "." to match newline (with -U)]'
|
2018-08-19 13:12:06 -05:00
|
|
|
$no"(--no-multiline)--no-multiline-dotall[don't allow \".\" to match newline (with -U)]"
|
2018-08-03 17:26:22 -04:00
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(only)' # Only-match options
|
2018-08-19 12:11:41 -05:00
|
|
|
{-o,--only-matching}'[show only matching part of each line]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ '(passthru)' # Pass-through options
|
2018-08-19 12:11:41 -05:00
|
|
|
'(--vimgrep)--passthru[show both matching and non-matching lines]'
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
'(--vimgrep)--passthrough[alias for --passthru]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2018-08-03 17:26:22 -04:00
|
|
|
+ '(pcre2)' # PCRE2 options
|
2018-08-19 12:11:41 -05:00
|
|
|
{-P,--pcre2}'[enable matching with PCRE2]'
|
|
|
|
|
$no'(pcre2-unicode)--no-pcre2[disable matching with PCRE2]'
|
|
|
|
|
|
|
|
|
|
+ '(pcre2-unicode)' # PCRE2 Unicode options
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
$no'(--no-pcre2 --no-pcre2-unicode)--pcre2-unicode[DEPRECATED: enable PCRE2 Unicode mode (with -P)]'
|
|
|
|
|
'(--no-pcre2 --pcre2-unicode)--no-pcre2-unicode[DEPRECATED: disable PCRE2 Unicode mode (with -P)]'
|
2018-08-03 17:26:22 -04:00
|
|
|
|
2018-07-23 19:19:22 -05:00
|
|
|
+ '(pre)' # Preprocessing options
|
|
|
|
|
'(-z --search-zip)--pre=[specify preprocessor utility]:preprocessor utility:_command_names -e'
|
|
|
|
|
$no'--no-pre[disable preprocessor utility]'
|
|
|
|
|
|
2018-09-04 22:45:24 -04:00
|
|
|
+ pre-glob # Preprocessing glob options
|
|
|
|
|
'*--pre-glob[include/exclude files for preprocessing with --pre]'
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ '(pretty-vimgrep)' # Pretty/vimgrep display options
|
|
|
|
|
'(heading)'{-p,--pretty}'[alias for --color=always --heading -n]'
|
|
|
|
|
'(heading passthru)--vimgrep[show results in vim-compatible format]'
|
|
|
|
|
|
|
|
|
|
+ regexp # Explicit pattern options
|
|
|
|
|
'(1 file)*'{-e+,--regexp=}'[specify pattern]:pattern'
|
|
|
|
|
|
|
|
|
|
+ '(replace)' # Replacement options
|
2018-08-19 12:11:41 -05:00
|
|
|
{-r+,--replace=}'[specify string used to replace matches]:replace string'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ '(sort)' # File-sorting options
|
2018-08-25 22:53:27 -04:00
|
|
|
'(threads)--sort=[sort results in ascending order (disables parallelism)]:sort method:((
|
|
|
|
|
none\:"no sorting"
|
|
|
|
|
path\:"sort by file path"
|
|
|
|
|
modified\:"sort by last modified time"
|
|
|
|
|
accessed\:"sort by last accessed time"
|
|
|
|
|
created\:"sort by creation time"
|
|
|
|
|
))'
|
|
|
|
|
'(threads)--sortr=[sort results in descending order (disables parallelism)]:sort method:((
|
|
|
|
|
none\:"no sorting"
|
|
|
|
|
path\:"sort by file path"
|
|
|
|
|
modified\:"sort by last modified time"
|
|
|
|
|
accessed\:"sort by last accessed time"
|
|
|
|
|
created\:"sort by creation time"
|
|
|
|
|
))'
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
'(threads)--sort-files[DEPRECATED: sort results by file path (disables parallelism)]'
|
|
|
|
|
$no"--no-sort-files[DEPRECATED: do not sort results]"
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2018-08-19 12:11:41 -05:00
|
|
|
+ '(stats)' # Statistics options
|
2018-06-25 20:09:24 -05:00
|
|
|
'(--files file-match)--stats[show search statistics]'
|
2018-08-03 17:26:22 -04:00
|
|
|
$no"--no-stats[don't show search statistics]"
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ '(text)' # Binary-search options
|
|
|
|
|
{-a,--text}'[search binary files as if they were text]'
|
binary: rejigger ripgrep's handling of binary files
This commit attempts to surface binary filtering in a slightly more
user friendly way. Namely, before, ripgrep would silently stop
searching a file if it detected a NUL byte, even if it had previously
printed a match. This can lead to the user quite reasonably assuming
that there are no more matches, since a partial search is fairly
unintuitive. (ripgrep has this behavior by default because it really
wants to NOT search binary files at all, just like it doesn't search
gitignored or hidden files.)
With this commit, if a match has already been printed and ripgrep detects
a NUL byte, then it will print a warning message indicating that the search
stopped prematurely.
Moreover, this commit adds a new flag, --binary, which causes ripgrep to
stop filtering binary files, but in a way that still avoids dumping
binary data into terminals. That is, the --binary flag makes ripgrep
behave more like grep's default behavior.
For files explicitly specified in a search, e.g., `rg foo some-file`,
then no binary filtering is applied (just like no gitignore and no
hidden file filtering is applied). Instead, ripgrep behaves as if you
gave the --binary flag for all explicitly given files.
This was a fairly invasive change, and potentially increases the UX
complexity of ripgrep around binary files. (Before, there were two
binary modes, where as now there are three.) However, ripgrep is now a
bit louder with warning messages when binary file detection might
otherwise be hiding potential matches, so hopefully this is a net
improvement.
Finally, the `-uuu` convenience now maps to `--no-ignore --hidden
--binary`, since this is closer to the actualy intent of the
`--unrestricted` flag, i.e., to reduce ripgrep's smart filtering. As a
consequence, `rg -uuu foo` should now search roughly the same number of
bytes as `grep -r foo`, and `rg -uuua foo` should search roughly the
same number of bytes as `grep -ra foo`. (The "roughly" weasel word is
used because grep's and ripgrep's binary file detection might differ
somewhat---perhaps based on buffer sizes---which can impact exactly what
is and isn't searched.)
See the numerous tests in tests/binary.rs for intended behavior.
Fixes #306, Fixes #855
2019-04-08 19:28:38 -04:00
|
|
|
"--binary[search binary files, don't print binary data]"
|
|
|
|
|
$no"--no-binary[don't search binary files]"
|
2018-08-19 12:11:41 -05:00
|
|
|
$no"(--null-data)--no-text[don't search binary files as if they were text]"
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ '(threads)' # Thread-count options
|
2018-08-25 22:53:27 -04:00
|
|
|
'(sort)'{-j+,--threads=}'[specify approximate number of threads to use]:number of threads'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
2018-08-19 12:11:41 -05:00
|
|
|
+ '(trim)' # Trim options
|
2018-08-03 17:26:22 -04:00
|
|
|
'--trim[trim any ASCII whitespace prefix from each line]'
|
|
|
|
|
$no"--no-trim[don't trim ASCII whitespace prefix from each line]"
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
+ type # Type options
|
|
|
|
|
'*'{-t+,--type=}'[only search files matching specified type]: :_rg_types'
|
|
|
|
|
'*--type-add=[add new glob for specified file type]: :->typespec'
|
|
|
|
|
'*--type-clear=[clear globs previously defined for specified file type]: :_rg_types'
|
|
|
|
|
# This should actually be exclusive with everything but other type options
|
|
|
|
|
'(: *)--type-list[show all supported file types and their associated globs]'
|
|
|
|
|
'*'{-T+,--type-not=}"[don't search files matching specified file type]: :_rg_types"
|
|
|
|
|
|
|
|
|
|
+ '(word-line)' # Whole-word/line match options
|
|
|
|
|
{-w,--word-regexp}'[only show matches surrounded by word boundaries]'
|
|
|
|
|
{-x,--line-regexp}'[only show matches surrounded by line boundaries]'
|
|
|
|
|
|
2020-02-17 15:34:59 -05:00
|
|
|
+ '(unicode)' # Unicode options
|
|
|
|
|
$no'--unicode[enable Unicode mode]'
|
|
|
|
|
'--no-unicode[disable Unicode mode]'
|
|
|
|
|
|
2018-07-23 19:19:22 -05:00
|
|
|
+ '(zip)' # Compression options
|
|
|
|
|
'(--pre)'{-z,--search-zip}'[search in compressed files]'
|
2018-06-25 20:09:24 -05:00
|
|
|
$no"--no-search-zip[don't search in compressed files]"
|
|
|
|
|
|
|
|
|
|
+ misc # Other options — no need to separate these at the moment
|
|
|
|
|
'(-b --byte-offset)'{-b,--byte-offset}'[show 0-based byte offset for each matching line]'
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
$no"--no-byte-offset[don't show byte offsets for each matching line]"
|
2018-06-25 20:09:24 -05:00
|
|
|
'--color=[specify when to use colors in output]:when:((
|
|
|
|
|
never\:"never use colors"
|
|
|
|
|
auto\:"use colors or not based on stdout, TERM, etc."
|
|
|
|
|
always\:"always use colors"
|
|
|
|
|
ansi\:"always use ANSI colors (even on Windows)"
|
|
|
|
|
))'
|
|
|
|
|
'*--colors=[specify color and style settings]: :->colorspec'
|
2017-07-06 19:04:14 -05:00
|
|
|
'--context-separator=[specify string used to separate non-continuous context lines in output]:separator'
|
2019-09-26 14:50:40 +03:00
|
|
|
$no"--no-context-separator[don't print context separators]"
|
2017-07-06 19:04:14 -05:00
|
|
|
'--debug[show debug messages]'
|
2021-05-25 21:41:11 -04:00
|
|
|
'--field-context-separator[set string to delimit fields in context lines]'
|
|
|
|
|
'--field-match-separator[set string to delimit fields in matching lines]'
|
2023-09-22 14:57:44 -04:00
|
|
|
'--hostname-bin=[executable for getting system hostname]:hostname executable:_command_names -e'
|
2023-07-08 00:56:50 +02:00
|
|
|
'--hyperlink-format=[specify pattern for hyperlinks]:pattern'
|
2020-02-17 14:43:22 -05:00
|
|
|
'--trace[show more verbose debug messages]'
|
2018-06-25 20:09:24 -05:00
|
|
|
'--dfa-size-limit=[specify upper size limit of generated DFA]:DFA size (bytes)'
|
|
|
|
|
"(1 stats)--files[show each file that would be searched (but don't search)]"
|
|
|
|
|
'*--ignore-file=[specify additional ignore file]:ignore file:_files'
|
2017-07-06 19:04:14 -05:00
|
|
|
'(-v --invert-match)'{-v,--invert-match}'[invert matching]'
|
cli: replace clap with lexopt and supporting code
ripgrep began it's life with docopt for argument parsing. Then it moved
to Clap and stayed there for a number of years. Clap has served ripgrep
well, and it probably could continue to serve ripgrep well, but I ended
up deciding to move off of it.
Why?
The first time I had the thought of moving off of Clap was during the
2->3->4 transition. I thought the 3.x and 4.x releases were great, but
for me, it ended up moving a little too quickly. Since the release of
4.x was telegraphed around when 3.x came out, I decided to just hold off
and wait to migrate to 4.x instead of doing a 3.x migration followed
shortly by another 4.x migration. Of course, I just never ended up doing
the migration at all. I never got around to it and there just wasn't a
compelling reason for me to upgrade. While I never investigated it, I
saw an upgrade as a non-trivial amount of work in part because I didn't
encapsulate the usage of Clap enough.
The above is just what got me started thinking about it. It wasn't
enough to get me to move off of it on its own. What ended up pushing me
over the edge was a combination of factors:
* As mentioned above, I didn't want to run on the migration treadmill.
This has proven to not be much of an issue, but at the time of the
2->3->4 releases, I didn't know how long Clap 4.x would be out before a
5.x would come out.
* The release of lexopt[1] caught my eye. IMO, that crate demonstrates
exactly how something new can arrive on the scene and just thoroughly
solve a problem minimalistically. It has the docs, the reasoning, the
simple API, the tests and good judgment. It gets all the weird corner
cases right that Clap also gets right (and is part of why I was
originally attracted to Clap).
* I have an overall desire to reduce the size of my dependency tree. In
part because a smaller dependency tree tends to correlate with better
compile times, but also in part because it reduces my reliance and trust
on others. It lets me be the "master" of ripgrep's destiny by reducing
the amount of behavior that is the result of someone else's decision
(whether good or bad).
* I perceived that Clap solves a more general problem than what I
actually need solved. Despite the vast number of flags that ripgrep has,
its requirements are actually pretty simple. We just need simple
switches and flags that support one value. No multi-value flags. No
sub-commands. And probably a lot of other functionality that Clap has
that makes it so flexible for so many different use cases. (I'm being
hand wavy on the last point.)
With all that said, perhaps most importantly, the future of ripgrep
possibly demands a more flexible CLI argument parser. In today's world,
I would really like, for example, flags like `--type` and `--type-not`
to be able to accumulate their repeated values into a single sequence
while respecting the order they appear on the CLI. For example, prior
to this migration, `rg regex-automata -Tlock -ttoml` would not return
results in `Cargo.lock` in this repository because the `-Tlock` always
took priority even though `-ttoml` appeared after it. But with this
migration, `-ttoml` now correctly overrides `-Tlock`. We would like to
do similar things for `-g/--glob` and `--iglob` and potentially even
now introduce a `-G/--glob-not` flag instead of requiring users to use
`!` to negate a glob. (Which I had done originally to work-around this
problem.) And some day, I'd like to add some kind of boolean matching to
ripgrep perhaps similar to how `git grep` does it. (Although I haven't
thought too carefully on a design yet.) In order to do that, I perceive
it would be difficult to implement correctly in Clap.
I believe that this last point is possible to implement correctly in
Clap 2.x, although it is awkward to do so. I have not looked closely
enough at the Clap 4.x API to know whether it's still possible there. In
any case, these were enough reasons to move off of Clap and own more of
the argument parsing process myself.
This did require a few things:
* I had to write my own logic for how arguments are combined into one
single state object. Of course, I wanted this. This was part of the
upside. But it's still code I didn't have to write for Clap.
* I had to write my own shell completion generator.
* I had to write my own `-h/--help` output generator.
* I also had to write my own man page generator. Well, I had to do this
with Clap 2.x too, although my understanding is that Clap 4.x supports
this. With that said, without having tried it, my guess is that I
probably wouldn't have liked the output it generated because I
ultimately had to write most of the roff by hand myself to get the man
page I wanted. (This also had the benefit of dropping the build
dependency on asciidoc/asciidoctor.)
While this is definitely a fair bit of extra work, it overall only cost
me a couple days. IMO, that's a good trade off given that this code is
unlikely to change again in any substantial way. And it should also
allow for more flexible semantics going forward.
Fixes #884, Fixes #1648, Fixes #1701, Fixes #1814, Fixes #1966
[1]: https://docs.rs/lexopt/0.3.0/lexopt/index.html
2023-10-16 18:05:39 -04:00
|
|
|
$no"--no-invert-match[do not invert matching]"
|
2017-07-25 21:00:54 -05:00
|
|
|
'(-M --max-columns)'{-M+,--max-columns=}'[specify max length of lines to print]:number of bytes'
|
|
|
|
|
'(-m --max-count)'{-m+,--max-count=}'[specify max number of matches per file]:number of matches'
|
2018-06-25 20:09:24 -05:00
|
|
|
'--max-filesize=[specify size above which files should be ignored]:file size (bytes)'
|
2018-02-03 20:33:52 -05:00
|
|
|
"--no-config[don't load configuration files]"
|
2017-07-06 19:04:14 -05:00
|
|
|
'(-0 --null)'{-0,--null}'[print NUL byte after file names]'
|
|
|
|
|
'--path-separator=[specify path separator to use when printing file names]:separator'
|
|
|
|
|
'(-q --quiet)'{-q,--quiet}'[suppress normal output]'
|
2018-06-25 20:09:24 -05:00
|
|
|
'--regex-size-limit=[specify upper size limit of compiled regex]:regex size (bytes)'
|
2017-07-06 19:04:14 -05:00
|
|
|
'*'{-u,--unrestricted}'[reduce level of "smart" searching]'
|
2021-07-07 17:50:23 +01:00
|
|
|
'--stop-on-nonmatch[stop on first non-matching line after a matching one]'
|
2018-06-25 20:09:24 -05:00
|
|
|
|
|
|
|
|
+ operand # Operands
|
|
|
|
|
'(--files --type-list file regexp)1: :_guard "^-*" pattern'
|
|
|
|
|
'(--type-list)*: :_files'
|
2017-07-06 19:04:14 -05:00
|
|
|
)
|
|
|
|
|
|
2020-03-15 20:43:13 -04:00
|
|
|
# This is used with test-complete to verify that there are no options
|
2018-06-25 20:09:24 -05:00
|
|
|
# listed in the help output that aren't also defined here
|
|
|
|
|
[[ $_RG_COMPLETE_LIST_ARGS == (1|t*|y*) ]] && {
|
|
|
|
|
print -rl - $args
|
2017-07-25 21:00:54 -05:00
|
|
|
return 0
|
|
|
|
|
}
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
# Strip out argument groups where unsupported (see above)
|
|
|
|
|
[[ $ZSH_VERSION == (4|5.<0-3>)(.*)# ]] &&
|
|
|
|
|
args=( ${(@)args:#(#i)(+|[a-z0-9][a-z0-9_-]#|\([a-z0-9][a-z0-9_-]#\))} )
|
2017-07-06 19:04:14 -05:00
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
_arguments -C -s -S : $args && ret=0
|
|
|
|
|
|
|
|
|
|
case $state in
|
|
|
|
|
colorspec)
|
|
|
|
|
if [[ ${IPREFIX#--*=}$PREFIX == [^:]# ]]; then
|
|
|
|
|
suf=( -qS: )
|
|
|
|
|
tmp=(
|
|
|
|
|
'column:specify coloring for column numbers'
|
|
|
|
|
'line:specify coloring for line numbers'
|
|
|
|
|
'match:specify coloring for match text'
|
|
|
|
|
'path:specify coloring for file names'
|
|
|
|
|
)
|
|
|
|
|
descr='color/style type'
|
|
|
|
|
elif [[ ${IPREFIX#--*=}$PREFIX == (column|line|match|path):[^:]# ]]; then
|
|
|
|
|
suf=( -qS: )
|
|
|
|
|
tmp=(
|
|
|
|
|
'none:clear color/style for type'
|
|
|
|
|
'bg:specify background color'
|
|
|
|
|
'fg:specify foreground color'
|
|
|
|
|
'style:specify text style'
|
|
|
|
|
)
|
|
|
|
|
descr='color/style attribute'
|
|
|
|
|
elif [[ ${IPREFIX#--*=}$PREFIX == [^:]##:(bg|fg):[^:]# ]]; then
|
|
|
|
|
tmp=( black blue green red cyan magenta yellow white )
|
|
|
|
|
descr='color name or r,g,b'
|
|
|
|
|
elif [[ ${IPREFIX#--*=}$PREFIX == [^:]##:style:[^:]# ]]; then
|
|
|
|
|
tmp=( {,no}bold {,no}intense {,no}underline )
|
|
|
|
|
descr='style name'
|
|
|
|
|
else
|
|
|
|
|
_message -e colorspec 'no more arguments'
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
(( $#tmp )) && {
|
|
|
|
|
compset -P '*:'
|
|
|
|
|
_describe -t colorspec $descr tmp $suf && ret=0
|
|
|
|
|
}
|
|
|
|
|
;;
|
|
|
|
|
|
|
|
|
|
typespec)
|
|
|
|
|
if compset -P '[^:]##:include:'; then
|
|
|
|
|
_sequence -s , _rg_types && ret=0
|
|
|
|
|
# @todo This bit in particular could be better, but it's a little
|
|
|
|
|
# complex, and attempting to solve it seems to run us up against a crash
|
|
|
|
|
# bug — zsh # 40362
|
|
|
|
|
elif compset -P '[^:]##:'; then
|
|
|
|
|
_message 'glob or include directive' && ret=1
|
|
|
|
|
elif [[ ! -prefix *:* ]]; then
|
|
|
|
|
_rg_types -qS : && ret=0
|
|
|
|
|
fi
|
|
|
|
|
;;
|
|
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
return ret
|
2017-07-06 19:04:14 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Complete encodings
|
|
|
|
|
_rg_encodings() {
|
|
|
|
|
local -a expl
|
|
|
|
|
local -aU _encodings
|
|
|
|
|
|
|
|
|
|
_encodings=(
|
complete/fish: improve shell completions for fish
- Stop using `-n __fish_use_subcommand`. This had the effect of
ignoring options if a positional argument has already been given, but
that's not how ripgrep works.
- Only suggest negation options if the option they're negating is
passed (e.g., only complete `--no-pcre2` if `--pcre2` is present). The
zsh completions already do this.
- Take into account whether an option takes an argument. If an option
is not a switch then it won't suggest further options until the
argument is given, e.g. `-C<tab>` won't suggest options but `-i<tab>`
will.
- Suggest correct arguments for options. We already completed a fixed
set of choices where available, but now we go further:
- Filenames are only suggested for options that take filenames.
- `--pre` and `--hostname-bin` suggest binaries from `$PATH`.
- `-t`/`--type`/&c use `--type-list` for suggestions, like in zsh,
with a preview of the glob patterns.
- `--encoding` uses a hardcoded list extracted from the zsh
completions. This has been refactored into a separate file, and the
range globs (`{1..5}`) replaced by comma globs (`{1,2,3,4,5}`) since
those work in both shells. I verified that this produces the same
list as before in zsh, and the same list in fish (albeit in a
different order).
PR #2684
2023-12-11 07:03:49 +01:00
|
|
|
!ENCODINGS!
|
2017-07-06 19:04:14 -05:00
|
|
|
)
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
_wanted encodings expl encoding compadd -a "$@" - _encodings
|
2017-07-06 19:04:14 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# Complete file types
|
|
|
|
|
_rg_types() {
|
|
|
|
|
local -a expl
|
|
|
|
|
local -aU _types
|
|
|
|
|
|
2022-04-26 21:19:09 -05:00
|
|
|
_types=( ${(@)${(f)"$( _call_program types $words[1] --type-list )"}//:[[:space:]]##/:} )
|
2017-07-06 19:04:14 -05:00
|
|
|
|
2022-04-26 21:19:09 -05:00
|
|
|
if zstyle -t ":completion:${curcontext}:types" extra-verbose; then
|
|
|
|
|
_describe -t types 'file type' _types
|
|
|
|
|
else
|
|
|
|
|
_wanted types expl 'file type' compadd "$@" - ${(@)_types%%:*}
|
|
|
|
|
fi
|
2017-07-06 19:04:14 -05:00
|
|
|
}
|
|
|
|
|
|
2018-06-25 20:09:24 -05:00
|
|
|
_rg "$@"
|
2017-07-06 19:04:14 -05:00
|
|
|
|
2018-08-20 08:57:54 -05:00
|
|
|
################################################################################
|
|
|
|
|
# ZSH COMPLETION REFERENCE
|
|
|
|
|
#
|
|
|
|
|
# For the convenience of developers who aren't especially familiar with zsh
|
|
|
|
|
# completion functions, a brief reference guide follows. This is in no way
|
|
|
|
|
# comprehensive; it covers just enough of the basic structure, syntax, and
|
|
|
|
|
# conventions to help someone make simple changes like adding new options. For
|
|
|
|
|
# more complete documentation regarding zsh completion functions, please see the
|
|
|
|
|
# following:
|
|
|
|
|
#
|
|
|
|
|
# * http://zsh.sourceforge.net/Doc/Release/Completion-System.html
|
|
|
|
|
# * https://github.com/zsh-users/zsh/blob/master/Etc/completion-style-guide
|
|
|
|
|
#
|
|
|
|
|
# OVERVIEW
|
|
|
|
|
#
|
|
|
|
|
# Most zsh completion functions are defined in terms of `_arguments`, which is a
|
|
|
|
|
# shell function that takes a series of argument specifications. The specs for
|
|
|
|
|
# `rg` are stored in an array, which is common for more complex functions; the
|
|
|
|
|
# elements of the array are passed to `_arguments` on invocation.
|
|
|
|
|
#
|
|
|
|
|
# ARGUMENT-SPECIFICATION SYNTAX
|
|
|
|
|
#
|
|
|
|
|
# The following is a contrived example of the argument specs for a simple tool:
|
|
|
|
|
#
|
|
|
|
|
# '(: * -)'{-h,--help}'[display help information]'
|
|
|
|
|
# '(-q -v --quiet --verbose)'{-q,--quiet}'[decrease output verbosity]'
|
|
|
|
|
# '!(-q -v --quiet --verbose)--silent'
|
|
|
|
|
# '(-q -v --quiet --verbose)'{-v,--verbose}'[increase output verbosity]'
|
|
|
|
|
# '--color=[specify when to use colors]:when:(always never auto)'
|
|
|
|
|
# '*:example file:_files'
|
|
|
|
|
#
|
|
|
|
|
# Although there may appear to be six specs here, there are actually nine; we
|
|
|
|
|
# use brace expansion to combine specs for options that go by multiple names,
|
|
|
|
|
# like `-q` and `--quiet`. This is customary, and ties in with the fact that zsh
|
|
|
|
|
# merges completion possibilities together when they have the same description.
|
|
|
|
|
#
|
|
|
|
|
# The first line defines the option `-h`/`--help`. With most tools, it isn't
|
|
|
|
|
# useful to complete anything after `--help` because it effectively overrides
|
|
|
|
|
# all others; the `(: * -)` at the beginning of the spec tells zsh not to
|
|
|
|
|
# complete any other operands (`:` and `*`) or options (`-`) after this one has
|
|
|
|
|
# been used. The `[...]` at the end associates a description with `-h`/`--help`;
|
|
|
|
|
# as mentioned, zsh will see the identical descriptions and merge these options
|
|
|
|
|
# together when offering completion possibilities.
|
|
|
|
|
#
|
|
|
|
|
# The next line defines `-q`/`--quiet`. Here we don't want to suppress further
|
|
|
|
|
# completions entirely, but we don't want to offer `-q` if `--quiet` has been
|
|
|
|
|
# given (since they do the same thing), nor do we want to offer `-v` (since it
|
|
|
|
|
# doesn't make sense to be quiet and verbose at the same time). We don't need to
|
|
|
|
|
# tell zsh not to offer `--quiet` a second time, since that's the default
|
|
|
|
|
# behaviour, but since this line expands to two specs describing `-q` *and*
|
|
|
|
|
# `--quiet` we do need to explicitly list all of them here.
|
|
|
|
|
#
|
|
|
|
|
# The next line defines a hidden option `--silent` — maybe it's a deprecated
|
|
|
|
|
# synonym for `--quiet`. The leading `!` indicates that zsh shouldn't offer this
|
|
|
|
|
# option during completion. The benefit of providing a spec for an option that
|
|
|
|
|
# shouldn't be completed is that, if someone *does* use it, we can correctly
|
|
|
|
|
# suppress completion of other options afterwards.
|
|
|
|
|
#
|
|
|
|
|
# The next line defines `-v`/`--verbose`; this works just like `-q`/`--quiet`.
|
|
|
|
|
#
|
|
|
|
|
# The next line defines `--color`. In this example, `--color` doesn't have a
|
|
|
|
|
# corresponding short option, so we don't need to use brace expansion. Further,
|
|
|
|
|
# there are no other options it's exclusive with (just itself), so we don't need
|
|
|
|
|
# to define those at the beginning. However, it does take a mandatory argument.
|
|
|
|
|
# The `=` at the end of `--color=` indicates that the argument may appear either
|
|
|
|
|
# like `--color always` or like `--color=always`; this is how most GNU-style
|
|
|
|
|
# command-line tools work. The corresponding short option would normally use `+`
|
|
|
|
|
# — for example, `-c+` would allow either `-c always` or `-calways`. For this
|
|
|
|
|
# option, the arguments are known ahead of time, so we can simply list them in
|
|
|
|
|
# parentheses at the end (`when` is used as the description for the argument).
|
|
|
|
|
#
|
|
|
|
|
# The last line defines an operand (a non-option argument). In this example, the
|
|
|
|
|
# operand can be used any number of times (the leading `*`), and it should be a
|
|
|
|
|
# file path, so we tell zsh to call the `_files` function to complete it. The
|
|
|
|
|
# `example file` in the middle is the description to use for this operand; we
|
|
|
|
|
# could use a space instead to accept the default provided by `_files`.
|
|
|
|
|
#
|
|
|
|
|
# GROUPING ARGUMENT SPECIFICATIONS
|
|
|
|
|
#
|
|
|
|
|
# Newer versions of zsh support grouping argument specs together. All specs
|
|
|
|
|
# following a `+` and then a group name are considered to be members of the
|
|
|
|
|
# named group. Grouping is useful mostly for organisational purposes; it makes
|
|
|
|
|
# the relationship between different options more obvious, and makes it easier
|
|
|
|
|
# to specify exclusions.
|
|
|
|
|
#
|
|
|
|
|
# We could rewrite our example above using grouping as follows:
|
|
|
|
|
#
|
|
|
|
|
# '(: * -)'{-h,--help}'[display help information]'
|
|
|
|
|
# '--color=[specify when to use colors]:when:(always never auto)'
|
|
|
|
|
# '*:example file:_files'
|
|
|
|
|
# + '(verbosity)'
|
|
|
|
|
# {-q,--quiet}'[decrease output verbosity]'
|
|
|
|
|
# '!--silent'
|
|
|
|
|
# {-v,--verbose}'[increase output verbosity]'
|
|
|
|
|
#
|
|
|
|
|
# Here we take advantage of a useful feature of spec grouping — when the group
|
|
|
|
|
# name is surrounded by parentheses, as in `(verbosity)`, it tells zsh that all
|
|
|
|
|
# of the options in that group are exclusive with each other. As a result, we
|
|
|
|
|
# don't need to manually list out the exclusions at the beginning of each
|
|
|
|
|
# option.
|
|
|
|
|
#
|
|
|
|
|
# Groups can also be referred to by name in other argument specs; for example:
|
|
|
|
|
#
|
|
|
|
|
# '(xyz)--aaa' '*: :_files'
|
|
|
|
|
# + xyz --xxx --yyy --zzz
|
|
|
|
|
#
|
|
|
|
|
# Here we use the group name `xyz` to tell zsh that `--xxx`, `--yyy`, and
|
|
|
|
|
# `--zzz` are not to be completed after `--aaa`. This makes the exclusion list
|
|
|
|
|
# much more compact and reusable.
|
|
|
|
|
#
|
|
|
|
|
# CONVENTIONS
|
|
|
|
|
#
|
|
|
|
|
# zsh completion functions generally adhere to the following conventions:
|
|
|
|
|
#
|
|
|
|
|
# * Use two spaces for indentation
|
|
|
|
|
# * Combine specs for options with different names using brace expansion
|
|
|
|
|
# * In combined specs, list the short option first (as in `{-a,--text}`)
|
|
|
|
|
# * Use `+` or `=` as described above for options that take arguments
|
|
|
|
|
# * Provide a description for all options, option-arguments, and operands
|
|
|
|
|
# * Capitalise/punctuate argument descriptions as phrases, not complete
|
|
|
|
|
# sentences — 'display help information', never 'Display help information.'
|
|
|
|
|
# (but still capitalise acronyms and proper names)
|
|
|
|
|
# * Write argument descriptions as verb phrases — 'display x', 'enable y',
|
|
|
|
|
# 'use z'
|
|
|
|
|
# * Word descriptions to make it clear when an option expects an argument;
|
|
|
|
|
# usually this is done with the word 'specify', as in 'specify x' or
|
|
|
|
|
# 'use specified x')
|
|
|
|
|
# * Write argument descriptions as tersely as possible — for example, articles
|
|
|
|
|
# like 'a' and 'the' should be omitted unless it would be confusing
|
|
|
|
|
#
|
|
|
|
|
# Other conventions currently used by this function:
|
|
|
|
|
#
|
|
|
|
|
# * Order argument specs alphabetically by group name, then option name
|
|
|
|
|
# * Group options that are directly related, mutually exclusive, or frequently
|
|
|
|
|
# referenced by other argument specs
|
|
|
|
|
# * Use only characters in the set [a-z0-9_-] in group names
|
|
|
|
|
# * Order exclusion lists as follows: short options, long options, groups
|
|
|
|
|
# * Use American English in descriptions
|
|
|
|
|
# * Use 'don't' in descriptions instead of 'do not'
|
|
|
|
|
# * Word descriptions for related options as similarly as possible. For example,
|
|
|
|
|
# `--foo[enable foo]` and `--no-foo[disable foo]`, or `--foo[use foo]` and
|
|
|
|
|
# `--no-foo[don't use foo]`
|
|
|
|
|
# * Word descriptions to make it clear when an option only makes sense with
|
|
|
|
|
# another option, usually by adding '(with -x)' to the end
|
|
|
|
|
# * Don't quote strings or variables unnecessarily. When quotes are required,
|
|
|
|
|
# prefer single-quotes to double-quotes
|
|
|
|
|
# * Prefix option specs with `$no` when the option serves only to negate the
|
|
|
|
|
# behaviour of another option that must be provided explicitly by the user.
|
|
|
|
|
# This prevents rarely used options from cluttering up the completion menu
|
|
|
|
|
################################################################################
|
|
|
|
|
|
2017-05-29 13:02:09 -07:00
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
# Copyright (c) 2011 Github zsh-users - http://github.com/zsh-users
|
|
|
|
|
# All rights reserved.
|
|
|
|
|
#
|
|
|
|
|
# Redistribution and use in source and binary forms, with or without
|
|
|
|
|
# modification, are permitted provided that the following conditions are met:
|
|
|
|
|
# * Redistributions of source code must retain the above copyright
|
|
|
|
|
# notice, this list of conditions and the following disclaimer.
|
|
|
|
|
# * Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
# notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
# documentation and/or other materials provided with the distribution.
|
|
|
|
|
# * Neither the name of the zsh-users nor the
|
|
|
|
|
# names of its contributors may be used to endorse or promote products
|
|
|
|
|
# derived from this software without specific prior written permission.
|
|
|
|
|
#
|
|
|
|
|
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
|
|
|
|
|
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
|
|
|
|
# WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
|
|
|
# DISCLAIMED. IN NO EVENT SHALL ZSH-USERS BE LIABLE FOR ANY
|
|
|
|
|
# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
|
|
|
|
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
|
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
|
|
|
|
|
# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
|
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
|
|
|
|
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
# Description
|
|
|
|
|
# -----------
|
|
|
|
|
#
|
|
|
|
|
# Completion script for ripgrep
|
|
|
|
|
#
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
# Authors
|
|
|
|
|
# -------
|
|
|
|
|
#
|
|
|
|
|
# * arcizan <ghostrevery@gmail.com>
|
|
|
|
|
# * MaskRay <i@maskray.me>
|
|
|
|
|
#
|
|
|
|
|
# ------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
# Local Variables:
|
|
|
|
|
# mode: shell-script
|
|
|
|
|
# coding: utf-8-unix
|
|
|
|
|
# indent-tabs-mode: nil
|
|
|
|
|
# sh-indentation: 2
|
|
|
|
|
# sh-basic-offset: 2
|
|
|
|
|
# End:
|
|
|
|
|
# vim: ft=zsh sw=2 ts=2 et
|
