- 01 4月, 2017 3 次提交
-
-
由 Andrew Gallant 提交于
-
由 Roman Proskuryakov 提交于
Fixes #426 , #418
-
由 Roman Proskuryakov 提交于
-
- 31 3月, 2017 1 次提交
-
-
由 Andrew Gallant 提交于
-
- 29 3月, 2017 2 次提交
-
-
由 Roman Proskuryakov 提交于
Fixes #419
-
由 Andrew Gallant 提交于
-
- 21 3月, 2017 1 次提交
-
-
由 Andrew Gallant 提交于
It's the same as the vimscript type, but shorter and more obvious. Fixes #415
-
- 15 3月, 2017 5 次提交
-
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
Fixes #381
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
-
- 14 3月, 2017 2 次提交
-
-
由 Leaf Garland 提交于
Use a `ps:` (powershell) command to copy the completions file so that we can use directory globbing to find the file.
-
由 Andrew Gallant 提交于
Fixes #1
-
- 13 3月, 2017 21 次提交
-
-
由 Andrew Gallant 提交于
Fixes #407
-
由 Andrew Gallant 提交于
This reverts commit d570f781. This was reverted because it's blocking a 0.5.0 release. Windows is foreign to me, and apparently globs are not allowed. See: https://ci.appveyor.com/project/BurntSushi/ripgrep/build/1.0.341/job/7o1jqicmtwm7oa00
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
Previously, `get_matches` would return even if --help or --version was given, and we could check for them manually. That behavior seems to have changed. Instead, we must use get_matches_safe to inspect the error to determine what happened. We can't use the same process for -V/--version since clap will unconditionally print its own version info. Instead, we rename (internally) the version flag so that clap doesn't interfere.
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
-
由 Ralf Jung 提交于
This permits setting the maximum line width with respect to the number of bytes in a line. Omitted lines (whether part of a match, replacement or context) are replaced with a message stating that the line was elided. Fixes #129
-
由 Andrew Gallant 提交于
-
由 Andrew Gallant 提交于
Fixes #345.
-
由 Andrew Gallant 提交于
Fixes #340
-
由 Andrew Gallant 提交于
This changes the default behavior of ripgrep to *not* show line numbers when it is printing to a tty and is only searching stdin. Fixes #380 [breaking-change]
-
由 Andrew Gallant 提交于
It's not clear what exactly is happening here, but the Read implementation for text decoding appears a bit sensitive. Small pertubations in the code appear to have a nearly 100% impact on the overall speed of ripgrep when searching UTF-16 files. I haven't had the time to examine the generated code in detail, but `perf stat` seems to think that the instruction cache is performing a lot worse when the code slows down. This might mean that excessive inlining causes a different code structure that leads to less-than-optimal icache usage, but it's at best a guess. Explicitly disabling the inline for the cold path seems to help the optimizer figure out the right thing.
-
由 Andrew Gallant 提交于
This includes, but is not limited to, UTF-16, latin-1, GBK, EUC-JP and Shift_JIS. (Courtesy of the `encoding_rs` crate.) Specifically, this feature enables ripgrep to search files that are encoded in an encoding other than UTF-8. The list of available encodings is tied directly to what the `encoding_rs` crate supports, which is in turn tied to the Encoding Standard. The full list of available encodings can be found here: https://encoding.spec.whatwg.org/#concept-encoding-get This pull request also introduces the notion that text encodings can be automatically detected on a best effort basis. Currently, the only support for this is checking for a UTF-16 bom. In all other cases, a text encoding of `auto` (the default) implies a UTF-8 or ASCII compatible source encoding. When a text encoding is otherwise specified, it is unconditionally used for all files searched. Since ripgrep's regex engine is fundamentally built on top of UTF-8, this feature works by transcoding the files to be searched from their source encoding to UTF-8. This transcoding only happens when: 1. `auto` is specified and a non-UTF-8 encoding is detected. 2. A specific encoding is given by end users (including UTF-8). When transcoding occurs, errors are handled by automatically inserting the Unicode replacement character. In this case, ripgrep's output is guaranteed to be valid UTF-8 (excluding non-UTF-8 file paths, if they are printed). In all other cases, the source text is searched directly, which implies an assumption that it is at least ASCII compatible, but where UTF-8 is most useful. In this scenario, encoding errors are not detected. In this case, ripgrep's output will match the input exactly, byte-for-byte. This design may not be optimal in all cases, but it has some advantages: 1. In the happy path ("UTF-8 everywhere") remains happy. I have not been able to witness any performance regressions. 2. In the non-UTF-8 path, implementation complexity is kept relatively low. The cost here is transcoding itself. A potentially superior implementation might build decoding of any encoding into the regex engine itself. In particular, the fundamental problem with transcoding everything first is that literal optimizations are nearly negated. Future work should entail improving the user experience. For example, we might want to auto-detect more text encodings. A more elaborate UX experience might permit end users to specify multiple text encodings, although this seems hard to pull off in an ergonomic way. Fixes #1
-
由 Joshua Horwitz 提交于
-
由 Andrew Gallant 提交于
Fixes #381
-
由 Andrew Gallant 提交于
We add scss to the existing `css` file type and `ejs` to the existing `html` file type. Fixes #393
-
由 Andrew Gallant 提交于
(This is what I get for directly pushing to master.)
-
由 Andrew Gallant 提交于
When writing paths like `!/foo` in gitignore files (or when using the -g/--glob flag), the presence of `!` would prevent the gitignore builder from noticing the leading slash, which causes absolute path matching to fail. Fixes #405
-
- 09 3月, 2017 2 次提交
-
-
由 Daniel Santa Cruz 提交于
Tested with local cargo build paths.
-
由 Andrew Gallant 提交于
-
- 08 3月, 2017 3 次提交
-
-
由 Jean-Marie Comets 提交于
Also document that ctrl-c doesn't restore the termcolor. Fixes #347.
-
由 Marc Tiehuis 提交于
-
由 Marc Tiehuis 提交于
-