| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This removes all use of explicit unsafe in ripgrep proper except for
one: accessing the contents of a memory map. (Which may never go away.)
|
|
|
|
|
|
|
|
|
|
Currently, Rust's standard library will yield an error if one tries to
write invalid UTF-8 to a Windows console. This is problematic for
ripgrep when it tries to print matched lines that contain invalid UTF-8.
We work around this by modifying the `termcolor` library to lossily
decode UTF-8 before sending it to `std::io::Stdout`. This may result in
some Unicode replacement chars being shown in the output, but this is
strictly better than erroring or not showing anything at all.
Fixes #318.
|
|
|
|
In Emacs, its terminal apparently doesn't support "extended" sets of
foreground/background colors. Unless we need to set an "intense" color,
we should instead use one of the eight basic color codes.
Also, remove the "intense" setting from the default set of colors. It
doesn't do much anyway and enables the default color settings to work
in Emacs out of the box.
Fixes #182 (again)
|
|
Closes #243
|
|
|
|
Fixes #313
|
|
This flag permits setting the path separator used for all file paths
printed by ripgrep in normal operation.
Fixes #275
|
|
Fixes #308
|
|
|
|
|
|
|
|
When running ripgrep like this:
rg foo > output
we must be careful not to search `output` since ripgrep is actively writing
to it. Searching it can cause massive blowups where the file grows without
bound.
While this is conceptually easy to fix (check the inode of the redirection
and the inode of the file you're about to search), there are a few problems
with it.
First, inodes are a Unix thing, so we need a Windows specific solution to
this as well. To resolve this concern, I created a new crate, `same-file`,
which provides a cross platform abstraction.
Second, stat'ing every file is costly. This is not avoidable on Windows,
but on Unix, we can get the inode number directly from directory traversal.
However, this information wasn't exposed, but now it is (through both the
ignore and walkdir crates).
Fixes #286
|
|
https://en.wikipedia.org/wiki/Kotlin_(programming_language)
https://github.com/udalov/kotlin-vim/blob/master/ftdetect/kotlin.vim
|
|
https://github.com/vim-ruby/vim-ruby/blob/master/ftdetect/ruby.vim
|
|
https://github.com/petdance/ack2/blob/2.15_02/ConfigDefault.pm#L155
|
|
https://en.wikipedia.org/wiki/Crystal_(programming_language)
https://github.com/rhysd/vim-crystal/blob/master/ftdetect/crystal.vim
|
|
|
|
|
|
|
|
This extends the syntax of the --type-add flag to allow including the globs of
other already defined types.
Fixes #83.
|
|
Add small howtos for installing shell completion files to the README and
the man page.
They are still incomplete. We're missing Zsh and PowerShell.
Fixes #262
|
|
|
|
When used, parallelism is disabled but the results are sorted by file
path.
Closes #263
|
|
This commit fixes two issues.
First, the iterator was executing the callback for every child of a
directory in a single thread. Therefore, if the walker was run over a
single directory, then no parallelism is used. We tweak the iterator
slightly so that we don't fall into this trap.
The second issue is a bit more subtle. In particular, we don't use the
blocking semantics of MsQueue because we *don't know when iteration
finishes*. This means that if there are a bunch of idle workers because
there is no work available to them, then they will spin and burn the
CPU. One case where this crops up is if you pipe the output of ripgrep
into `less` *and* the total number of files to search is fewer than the
number of threads ripgrep uses. We "fix" this with a very stupid
heuristic: when the queue yields no work, we sleep the thread for 1ms.
This still pegs the CPU, but not nearly as much as before.
If one really want to avoid this behavior when using ripgrep, then `-j1`
can be used to disable parallelism.
Fixes #258
|
|
Previously, ripgrep would only emit the 'bold' ANSI escape sequence if
no foreground or background color was set. Instead, it would convert colors
to their "intense" versions if bold was set. The intent was to do the same
thing on Windows and Unix. However, this had a few negative side effects:
1. Omitting the 'bold' ANSI escape when 'bold' was set is surprising.
2. Intense colors can look quite bad and be hard to read.
To fix this, we introduce a new setting called 'intense' in the --colors
flag, and thread that down through to the public API of the `termcolor`
crate. The 'intense' setting has environment specific behavior:
1. In ANSI mode, it will convert the selected color to its "intense"
variant.
2. In the Windows console, it will make the text "intense."
There is no longer any "smart" handling of the 'bold' style. The 'bold'
ANSI escape is always emitted when it is selected. In the Windows
console, the 'bold' setting now has no effect. Note that this is a
breaking change.
Fixes #266, #293
|
|
|
|
|
|
Only build darwin on nightly for deployment. (Darwin builders are quite
slow on Travis.)
Also, add MUSL to Rust 1.12.0 builder.
|
|
|
|
|
|
SWIG from http://swig.org/
Fixes #296
|
|
Fixes #295.
|
|
This means that ripgrep will no longer try to reset your colors in your
terminal if you kill it while searching. This could result in messing up
the colors in your terminal, and the fix is to simply run some other
command that resets them for you. For example:
$ echo -ne "\033[0m"
The reason why the ^C handling was removed is because it is irrevocably
broken on Windows and is impossible to do correctly and efficiently in
ANSI terminals.
Fixes #281
|
|
|
|
|
|
The point of the ~ dependency was to avoid implicitly increasing the
minimum Rust version required to compile ripgrep. However, clap's policy
is to support at least two prior releases of Rust (which roughly
corresponds to the convention that others use too), and that is probably
good enough.
The problem with using a ~ dependency is that it can make packaging
ripgrep in Linux distros difficult, because it means the packager may be
forced to package multiple compatible versions of the same library.
Fixes #271
|
|
2016-12-24-archlinux-cheetah uses the same setup/compile config as
2016-09-22-archlinux-cheetah. The improvements are nice.
The other 2016-12-24-archlinux-cheetah-* benchmarks try to suss out
a difference between MUSL, glibc, jemalloc and the system allocator.
|
|
|
|
This allows one to selectively choose which commands aren't
benchmarked.
|
|
|
|
|
|
|
|
Update docs to explain use of -g and --files to search for paths.
Fixes #284
|
|
Fixes #268.
|
