swiper VS ripgrep

This is a good improvement. Personally though I left isearch behind. For further search convenience / functionality I highly recommend swiper.

Next you "only" have to remember (elisp) function names. "Completion UIs" like ivy/counsel, icomplete, helm or vertico/consult, give you a nice auto completion list on M-x (choose the one of them, you like the most). Some of those Completion UIs will display existing keybindings and a short documentation for commands, near the auto complete candidates. So you will start to remember more keybindings without "learning sessions", just because invoking functions via keybindings is much faster (more convenient).

Proposal 4 (group-function). This one is an actual addition, which allows candidate gouping in the style of Helm. Note that it is a pure addition. Completion UIs and completion packages work perfectly fine without it. It wouldn't be difficult to add support to Ivy. I wrote the patch.

For the unfamiliar, Swiper is a part of Ivy which lets you search through your buffer with a preview of match candidates: you type some text you're looking for, and up pops a list of matching lines in the minibuffer that you can then use the arrow keys, C-n C-p etc. to scroll through and select the one you want.

When I started using Emacs I was following the setup outlined by System Crafters, which I still think is a really good introduction. But, over the last few months I've started to replace packages with more "minimalist" or "stripped down" packages. I've switched from Ivy and Counsel to Vertico and Consult, and recently I switched from company to corfu for auto-completion.

Ah, neat. I hadn't considered appending comments for searchability. I'm currently getting searchabiity from M-x dwim-... and ivy completion.

Great question. I have one big file with a few hundreds book and quotations from them. Problem is with newlines. When I copy text from kindle it doesn't have newlines because it's depends on font size. So every quotation from book is on one line - could be few thousands chars. I use visual-line-mode and there is a big problem with that. Like swiper would just freeze your emacs if you try to search. https://github.com/abo-abo/swiper/issues/925 Anyone have same problem?

ripgrep GitHub Fast alternative to grep

I didn't call ripgrep a replacement. Other people do. Because it does actually replace their usage of grep.

https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#can...

> The maintainer also has been pretty rude to me about this on HN.

This is AFAIK the only other interaction we've had: https://news.ycombinator.com/item?id=41051587

> but it's still crazy to think people won't be caught off guard by this behavior

Straw-manning is also crazy. :-) People have and will absolutely be caught off guard by the behavior. On the flip side, as I said 9 months ago, ripgrep's default behavior is easily one of the most cited positive features of ripgrep aside from its performance.

The other crazy thing here is... you don't have to use ripgrep! It is very specifically intended as a departure from traditional grep behavior. Because if you want traditional grep behavior, then you can just use grep. Hence why ripgrep's binary name is not `grep`, unlike many other implementations of POSIX grep.

> Its name is literally indicating it's a grep replacement.

I also tried to correct this 9 months ago too. See also: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

For anyone else following along at home, if you want ripgrep to search the same files that GNU grep searches, then do `rg -uuu`. Or, if you don't want ripgrep to respect your gitignores but ignore hidden and binary files, then do `rg -u`.

When you think ripgrep (rg), you probably think "fast regex search tool."

I'm sure you can get creative. :-) You can set an environment variable to control the encoding, expose a flag or any one of a number of other things to control the encoding.

You've also continued to ignore my most substantive rebuttal: that a specific example where ripgrep is not compatible with grep or doesn't behave the same doesn't mean it can't be used in shell pipelines. Literally nothing you've said has invalidated anything I've said. All you're doing is finding things that some implementations of grep can do that ripgrep (intentionally) cannot do in exactly the same way. But that's fine, because ripgrep was never, isn't and will never be compatible with grep: https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#pos...

So if you need grep compatibility get a fucking clue and just use grep.

> Rust applications are sometimes (often?) slower than comparable C applications

Could you cite some examples? There are plenty of counter-examples

- ripgrep is 5-10x faster than grep (https://github.com/BurntSushi/ripgrep/blob/962d47e6a1208cf21...)

- Memory-safe implementations of PNG (png, zune-png, wuffs) now dramatically outperform memory-unsafe ones (libpng, spng, stb_image) when decoding images. (https://www.reddit.com/r/rust/comments/1ha7uyi/memorysafe_pn...)

- I don't consider the benchmarks game a worthwhile comparison because they're only writing assembly, but Rust and C are comparable in speed (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...)

- Advent of Code - I came across Rust codebases which solved all of AoC 2024 in under 1 millisecond (almost fully assembly), and also ordinary, idiomatic code in under 100 milliseconds. I don't recall anyone ever posting a C codebase with perf measurements, but I could have missed this.

I'm surprised by the "often", but I'd be interested in any cases where C outperforms Rust. Please share if you've found any.

ripgrep

The original comment said nothing about modifying servers or AWS engineers installing random shit. That was you. I responded to "moving binaries around," and you started yapping about change management. Two totally different things. Like obviously if you have a locked down environment, then only install what you need. But this is not what the original poster was referring to specifically.

ripgrep even specifically calls out this exact use case right in its README: https://github.com/BurntSushi/ripgrep/?tab=readme-ov-file#wh...

> You need a portable and ubiquitous tool. While ripgrep works on Windows, macOS and Linux, it is not ubiquitous and it does not conform to any standard such as POSIX. The best tool for this job is good old grep.

So, you presume too much friendo. Now, go away.