What is Reddit's opinion of
The Silver Searcher?
From 3.5 billion Reddit comments
80 reviews of this app found across Reddit:
I don't have time to do a real review, but I did read the online version of the book and I have some things to say about it.
I've been writing C off-and-on for almost 20 years now. I'm also the author of The Silver Searcher (aka ag), a popular search tool written in C. One might agree that I have some experience in this field. So please believe me when I say that Zed Shaw's LCTHW is a waste of time regardless of your skill level. It contains many inaccuracies. Worse, it doesn't contain information on important aspects of the C language and its ecosystem of tooling. The best criticism of the book is probably this post by Tim Hentenaar. The post also shows Zed's unprofessional behavior in response to criticism.
I cannot stress it enough: Avoid this book.
If you like this you will love ag, the silver searcher. There is also a vim plugin. I bind <leader>t to :Ag \(todo\|TODO\)
EDIT : the correct config in vimrc is nnoremap <leader>t :Ag '(todo\|TODO)'<CR>, the line above is misleading.
One small side note that might be of interest for people reading this article. I used the silver searcher for awhile, but I recently discovered another tool called ripgrep which is much better. It's faster and it doesn't have the issues with gitignore behavior that have plagued silver searcher.
grep is more sysadmin tool, since it's guaranteed to be installed pretty much anywhere. For code searching, I would suggest <code>ripgrep</code>, <code>ag (The Silver Searcher)</code>, or <code>ack</code>. They're focused on code searching and once you get used to one, you won't ever touch grep ever again.
I use ripgrep. It's essentially a happy middleground between grep and the silver searcher (`ag'). It's (arguably) faster than both with many of the usability benefits of ag. I like that I can just do rg "pattern" and it'll recursively search through my current directory, skipping anything that appears in a .gitignore file (I'm sure other similar files are supported as well).
I actually don't use awk much, except maybe to print stuff by column because tr is too inconvenient to use and too limited. Most of the time, I'm searching for something, not manipulating text as much, because if I'm going to do that, chances are it's probably easier to just do it in Python.
So in short, I don't use awk enough to make learning how to reduce usage of grep worthwhile.
今回はソースコードからthumbnail（サムネイルに関する処理なんだからthumbnailって単語が使われているだろうっていう発想）を検索し、関数の定義箇所を探したらあっさり見つかった。例えばこんな感じ：
$ git clone https://github.com/reddit/reddit/ $ cd reddit $ ag thumbnail | less
agはSilver Searcherっていうソースコード用の検索プログラムで、動作が速いのでかなり便利
You don't need the Ag plugin.
In your vimrc, set this option let &grepprg = 'ag --nogroup --nocolor'
to use https://github.com/ggreer/the_silver_searcher#installing for grepping. Then you can do :grep 'your string' and then :copen to see the results list.
It certainly affects some languages more than others. I have a repo that is the 8th most popular C project on GitHub. Not once have I gotten an issue or pull request related to social stuff. The same can't be said for Ruby or JavaScript projects of similar notoriety.
Came here to post The Silver Searcher (ag), thinking that the author must have not been aware of it. But was very surprised to see benchmarks that show that this tool is somehow faster?? That's extremely impressive, and very hard to believe. He even mentions that explicitly:
> The benchmarks in which sift is much faster than ag (the silver searcher) received the most criticism, so here are the steps to reproduce those test results.
Does anyone know how this is so much faster? It's sometimes 2x to 8x faster than silver searcher, and silver searcher is really no joke. I remember being very inspired by the silver searcher blog posts, but I guess he must have still missed a lot of optimizations.
Of this list I use vim, rsync, tmux, xargs, nethack (however, dwarf fortress is the most complex game on the planet), task warrior, curl, rtorrent, ttytter for announcing new posts from my jekyll blog, and cloc.
Some good ones he missed:
Tools I hadn't heard of from this list include slurm, tpp (cute!), ledger, calcurse, earthquake, powertop, and qalc.
Ah, Ag is significantly faster, that's probably why I'm not experiencing it.. I don't even have caching enabled when using it:
https://github.com/ggreer/the_silver_searcher
and then:
let g:ctrlp_user_command = 'ag %s -l --nocolor -g ""'
If you're using git or mercurial it will automatically exclude items included in your ignore lists.
The Silver Searcher is even faster than ack. I've been loving it so far.
Edit: according to the author, the only thing that is faster is something like ctags, which produces an actual index
>that's not the case for Windows. I'm not Windows user myself, but I still find it kinda weird thing that there is no builtin solution for this task.
While it is true that Windows does not ship with either grep or find, there are myriad of grep and find ports and versions available on Windows, so I don't see how is that a practical problem. Implementing efficient and fast search is not a trivial task, so I personally believe it is better to leave that to external utility such as ag (silversearcher), ripgrep or maybe latest kid on the block, hyperscan.
I like ag better, myself. In any event, both ack and ag (and grep for that matter) have emacs integrations available, so you can do, say, M-x ag, enter the search string, enter the starting directory, and then it will open up a buffer with the search results. Then you can click on the search result that you want, and it will open the file, at that line. No need to use the command line.
Linux doesn't typically have indexing search systems for the local machine because Linux I/O and filesystems are faster, and a simple search is just as fast. I like The Silver Searcher (<code>ag</code>), a command-line tool. I'm sure there are GUI equivalents, but I can't recommend anything.
Thanks for describing what the app does and how you use it. The majority of the time when people ask for an equivalent to an application, they don't describe the functionality or their use-case. A Linux users might have good answers but might have to research the app in the question first, if they aren't already familiar with it.
I’m actually surprised to see that <code>ag</code> uses a fairly naïve BM implementation by comparison. That isn’t to say that it doesn’t work well. That said, raw matching performance has always been (much) better with grep than with ack, and I wouldn’t be surprised if it were faster than ag as well (in fact, I’m almost certain).
I’m also somewhat surprised that there doesn’t seem to be a highly efficient, fine-tuned general string matching library for C; I mean, there’s PCRE for pattern matching. Why isn’t there a similar thing for strstr? For C++, there are highly specialised string finding libraries that find application in bioinformatics.
Also, if you use Silver Searcher tool, you can disable caching all together. Tool is fast enough to go through thousands of files really fast. Here's the example on how to configure CtrlP and grepprg.
:grep foo * | cw lists all the occurrences of foo in all the files in the current directory.
:grep foo **/*.php | cw lists all the occurrences of foo in all the PHP files in the current directory and every subdirectory.
Ack and The Silver Searcher are very worthy alternatives to grep that can be integrated very easily in Vim.
But nothing beats an actual code indexer like GNU GLOBAL, cscope or even ctags.
Just to provide an alternative to grep, the silver searcher is designed for this problem and supports swift. So you would just do something like,
ag -l --swift MapKit
TundraWolf_ was referring to programs and <code>ag</code> is similar to one of the ones he mentioned. You were unknowningly caught up in a flurry of nerd comments ;)
grep is a fine tool, but if you often need to search for strings in text files, you should check out ag a.k.a. The Silver Searcher.
I highly recommend ag (The Silver Searcher), it's extremely fast and ignores source control directories by default. Here's a quick example on one of our legacy products.
grep -R 'float: none' ./ --exclude-dir=.svn 0.47s user 0.05s system 98% cpu 0.527 total ag 'float: none' 0.10s user 0.12s system 276% cpu 0.079 total
Faster, simpler syntax (including ack-like options such as --perl --python --markdown) and more generic than git's grep.
When I run into a confusing situation like this I search my gems for the method definition.
In my .bashrc file I have alias bundle-search="bundle show --paths | xargs ag" which relies on https://github.com/ggreer/the_silver_searcher/
I just type bundle-search "def respond_to" and see what files appear.
You could just type bundle show --paths | xargs ag "def respond_to"
There's a new kid in town for file searching too, so if you don't have ag you might want to consider rg instead: https://blog.burntsushi.net/ripgrep/#pitch
That doesn't directly answer your question but it should give you a way to investigate
more details:
fzf + The Silver Searcher + ack.vim = better shell and better vim fuzzy search.
Consider checking out (https://github.com/ggreer/the_silver_searcher)[ag] instead. It's like Ack but quicker, it just hasn't been around as long. Little reason to use Ack when Ag is the same but faster, and neither are installed by default in most distros (which is why you should still learn how to use grep, since it's available everywhere).
If we were optimizing this totally joke bad idea answer, grep might still actually save time, as it means we don't have to run sed over files that don't contain 'float' in the first place.
sed feels like the right tool, but I don't know if running it via ls | xargs or grep | xargs would actually be faster.
However it is dangerous to bet against grep...unless perhaps you're silver
https://blog.kowalczyk.info/software/the-silver-searcher-for-windows.html
Another option is Cygwin. It compiles just fine in Cygwin. Details here: https://github.com/ggreer/the_silver_searcher/wiki/Windows
Enjoy.
Or try ack (http://beyondgrep.com/) or ag (https://github.com/ggreer/the_silver_searcher). Both of these will automatically exclude VCS files (e.g. the whole .git directory in Git projects), and use algorithms that are generally faster than grep, though sometimes less flexible.
I personally use ag for all searching, and it is incredibly fast.
LINK: <code>ag</code>
^(I am a bot, I make links more tappable on mobile)
^(fatFingersbot created by jackjgoodall,)
^(Please report any problems to r/fatFingersbot)
^(Reply '!thinfingers' to disable replies to you)
I use ack.vim configured to work with ag. Ag is a fast source code searcher I use inside and outside of vim, while ack.vim is just a small wrapper around vim's built-in :grep command, which adds some conveniences like automatically opening the quickfix list.
To configure I have this line in my init.vim: let g:ackprg = 'ag --nogroup --nocolor --column --hidden --path-to-ignore ~/.config/ag/.ignore'
A more native solution would be to use :grep with <code>ag</code>. From man ag:
set grepprg=ag\ --vimgrep\ $* set grepformat=%f:%l:%c:%m
Now you can do:
:grep --sass '.class p'
This will populate the quickfix. Use :cnext/:cprev to navigate the list and :copen to open the quickfix list window.
Note: Another popular grep alternative is ripgrep. Ripgrep also supports --vimgrep option (See man rg). The search would become: :grep -t sass '\.class p'.
What about fzf.vim?
I do not use fzf/fzf.vim so I am unsure how to accomplish this. It seems that you have an answer in a different thread. Personally, I tend to go for more native solutions
Use comm, the -v/--invert-match, and -l/--name-only/--files-with-matches together.
comm -12 <(git grep -l -e 'foo') <(git grep -l -v -e 'bar')
Read as all files containing foo, but not bar.
You can supply this to :args if you want to load the list of files into Vim.
:args comm -12 <(git grep -l -e 'foo') <(git grep -l -v -e 'bar')
For more help see: man comm, git help grep, and :h :args
Since you are not needing to search by lines then feel free to use any grep program that fits your needs, e.g. grep, git grep, ack, The Silver Searcher, ripgrep
Note: These examples use bash. If you have a different shell then you may need to do redirection and subshells differently
I find ripgrep or ag quite fast.
You could pair it with terminal velocity. Having everything as plain-text without any index or even management system required makes portability to other platforms easy, like just using any markdown editor on Android.
Not precisely what you're asking, but I highly recommend The Silver Searcher: https://github.com/ggreer/the_silver_searcher
The executable is called ag, and ag-project is an excellent interface for Emacs:
https://github.com/Wilfred/ag.el
I use helm for almost everything, but I find ag-project (the function provided by ag) to have better usability than helm-ag.
- It automatically inputs the symbol at point into to search field
- The results buffer persists automatically
But I think either solution is good. Ag is strictly better than grep in my experience unless you're commonly doing pretty arcane/advanced grepping. For my workflow, simple string matching on the source files in the project is 99% of my needs. Ag's biggest advantage is it makes search so fast it's basically free. It typically returns in under 100ms on my (modest) laptop.
The most useful tool here in my opinion is the recursive grep, or better, <code>ag</code>. This is useful both to find the part of the program you care about (e.g. by carefully searching for some UI text or error message) but also for understanding the program once you've got that foothold, e.g. finding where functions are implemented, where types are defined, what #defines expand to, all the places that call a given function, etc.
You should at least provide links: ag source and a blog pitch
I haven't used ag myself though. I've never once worried about the speed of ack, even though that blog asserts "trivial inconveniences matter." Ack is also directly available in more distros, but that's the sort of advantage that will fade over time. I have no skin in this game - if you like ag better, great!
> File system: anything I/O related on windows feels incredibly sluggish. Stupid things like virus scanners probably make things worse, but I guess NTFS wasn't meant for, erhm, accessing files? Searching for files, or files with a certain string, is horribly slow. Nothing beats grep for speed, and windows ain't got it.
Although I agree fully with you, ack and ag are much faster than grep -> https://github.com/ggreer/the_silver_searcher
>
> General tools: You want a decent text editor? Database? Web server? Java container? Version control? If they exist on windows, they're ports of *nix tools. And usually don't work as well, or require ghastly things like Cygwin. Git on windows anyone? Ugh.
How do you like Github's git UI? :D
> Silver searcher
https://github.com/ggreer/the_silver_searcher
sudo ag --silent --one-device xmrig /
xmrig or some part of the path which you found from previous steps, you have to be smart, because hackers are smart too.
If you have fzf.vim plugin installed, you can do global text search.
See list of commands
:Ag [PATTERN]
Ag requires The Silver Searcher (ag)
The are other options too, see the commands.
Vim also support native search using vimgrep or using unix grep.
> ripgrep
For me, it's The Silver Searcher, which is ag on the command line. It's exclusively for searching text files, but that's what makes it really really fast.
LINK: <code>ag</code> LINK: fzf
^(I am a bot, I make links more tappable on mobile)
^(fatFingersbot created by jackjgoodall,)
^(Please report any problems to r/fatFingersbot)
^(Reply '!thinfingers' to disable replies to you)
> Windows aggressively and continuously runs its indexing service and the so called superfetch service
But they only do that because I/O is slow.
Think about it. We can run indexers like the vaunted "Everything" on Linux, but we don't, because a simple <code>ag</code> or find is just as fast. Windows users ask if there's a utility to index everything on the disk, and Linux users are puzzled, because why would you bother?
Or possibly they do it because at Microsoft adding a feature is rewarded, but improving core performance is not. Features! Features! Features!
> all read/write operations are checked by the antivirus software built into the OS.
There's nothing built-in. Windows Defender is optional. It's true that traditional Windows A/V software is a nightmare for disk performance, though.
For locally searching a project in my terminal I use this: https://github.com/ggreer/the_silver_searcher
​
Although depending on your IDE there is a chance there is a built in tool for searching
I like using 2 tools for getting up to speed on code:
<code>ag</code>, silver searcher, to search through code to find variables, references, etc.
intero, for explaining types, and jumping to definitions
I recommend this project to use instead of grep command:
https://github.com/ggreer/the_silver_searcher
PS. I have no relationship with this project.
This is not what you asked for, but others have already given you those answers.
Instead here's a small ruby script I use often for similar (but not the same) purposes.
Often I need to open and edit all files whose contents match a certain regex. (Think refactoring.)
This script uses the silver searcher (but you can modify it easily to use ripgrep since that's the rage these days) to find all files matching the given regular expression, and open them in a series of vertical vim splits. (Again, you can modify this to use tabs or whatever else is your vim workflow.)
It even confirms the list of files with you so you don't accidentally match a hundred files.
#!/usr/bin/env bash exec /usr/bin/env ruby --disable-gems -x "$0" "$@" #!ruby
def yesno begin system("stty raw -echo") str = STDIN.getc ensure system("stty -raw echo") end
str.upcase == "Y" end
stdout = IO.popen(['ag', '-l0', *ARGV], in: :in, err: :err, &:read) files = stdout.split("\0")
if files.empty? $stderr.puts "no files matched" exit 1 end
puts "Will open:" files.each do |file| puts "- #{file}" end puts "" print "OK? [yn] "
if yesno exec("vim", "-O", *files) end
Some alternatives for some of these commands. If you have a process you want to kill, you usually do "ps -aux | grep processname" and then look for the process, and then kill the PID. I've started just using "pgrep processname" to shorten the first step. And then you can do "kill (pgrep processname)".
For a grep replacement when searching through files more intensly, I have been thrilled with the silver searcher. It is much faster than grep and I feel has defaults that align more with my use cases.
Also, for text replacement/matching, I started using sd instead of sed. It is sadly nowhere near as active as replacements like ag, but I much prefer the saner (IMHO) way of the input string and replacement string are split. Also, the regex style is one I much prefer as well. Combined with this online regex tool, I am now much more comfortable with regular expressions than before.
If you have access to a terminal/grep this is a quick option.
$ grep “{search_word}” {file_name} > result.txt
Where: {search_word} is the “certain word” that you want to find, {file_name} is the 40 gig file that will be searched, and result.txt will have the printed lines that contain your {search_word}.
Look into using flags for a more refined search. For example the following line will perform a case insensitive search:
$ grep -i “{search_word}” {file_name} > result.txt
If you want to improve performance of your search look into installing silver searcher ( https://github.com/ggreer/the_silver_searcher/).
I like having 'g' as a recursive grep. I prefer ripgrep but fall back to either the silver searcher or plain grep depending on what's installed. The for loop sets 'g' as an alias if either 'rg' or 'ag' are in $PATH. The second bit defines a 'g' function for calling grep if the 'g' alias wasn't set.
# pick the best recursive grep available for prg in 'rg' 'ag'; do type -P ${prg} > /dev/null && alias g="${prg} --ignore-case" && break done ; unset prg
# use a function wrapper if we are stuck with plain grep if ! alias g > /dev/null 2>&1; then function g() { grep -inRHI "$@" .; } fi
It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!
Here is link number 1 - Previous text "ag"
^Please ^PM ^/u/eganwall ^with ^issues ^or ^feedback! ^| ^Delete
This is great, thanks!
However, the recursive setting is not really usable in medium-sized projects for me. Have you considered supporting something like ag?
First of all I do recommend to install the_silver_searcher.
It searched ~ 1GB text file with ~ 29 million lines and found hundreds of searched word in only 00h 00m 00.73s, i.e. LESS than a second!
Here is the minimal version of code which searches for word and counts it:
import subprocess
word = "some" file = "/path/to/some/file.txt"
command = ["/usr/local/bin/ag", "-wc", word, file] output = subprocess.Popen(command, stdout=subprocess.PIPE).stdout.read() print("Found entries:", output.rstrip().decode('ascii'))
This version searches for word and prints line numbers + actual text were the word was found:
import subprocess
word = "some" file = "/path/to/some/file.txt"
command = ["/usr/local/bin/ag", "-w", word, file] output = subprocess.Popen(command, stdout=subprocess.PIPE)
for line in output.stdout.readlines(): print(line.rstrip().decode('ascii'))
I use jq constantly to filter and transform JSON. It's magic and can do so much.
the-silver-searcher is an awk replacement and is significantly (like 30x+) faster.
From the author's description, ag does indeed use pthreads to search multiple files in parallel. However, if we use xargs then xargs will only pass it a certain no. of files everytime it invokes ag. Won't that bottleneck ag?
Yes! Although Sublime's is very good! I tend to use vim for 99% of my things but I reach out to Sublime or VS Code for other things (like debugging in VS Code, it's fantastic).
So, to your question. The "project find" interface you talk about is basically vimgrep, although most people use some external tool piped to this interface (most even don't know they're using that!). I use The Silver Searcher and I can't recommend it enough. That coupled with this plugin (which is not entirely necessary but has some quickfix window goodies that are interesting and boring to set up) makes for a very nice "find in files" searcher.
That last paragraph is what a vim person would tell you. What a Sublime convert would recommend would be the CtrlSF plugin. Which basically mimics the ST3 interface. Why wouldn't I just tell you about this one? Because as time goes by using vim, people start to become a little elitist and purist and begin to see plugins this "complex" as too much. Vim stops being freaking fast to become "just another text editor".
I say to each its own and these kinds of plugins really help to make a smooth transition till you figure out ways to replace these kinds of plugins with simpler ones or even vanilla vim functions. All this preface to vim culture is because you should really come hang with us at r/vim, of course :). Everyone will try to help out with your troubles but there are some apparent bad apples (I can think of two) that would seem rather rude just linking something like :h :vimgrep. At first you'll hate them but then you'll understand they're just trying to help you get the correct topic of documentation that you need (is harder than it looks at first).
Goddamit, someone lets me talk about vim and I write a fucking novel.
You probably should/could use ag or the older ack for this. Advantage: ag lorem ipsum is a bit shorter (and also faster) than the above.
In the unlikely case you need to find a file that has the exact contents of $STRING then you can abuse rmlint (a duplicate file finder) for this. Advantage for this case: It's quite fast.
`rmlint -T df -m . // wanted # "wanted" is a file that contains "lorem ipsum"
A quick <code>ag</code> through Emacs sources shows that nothing uses el-search. The package is also not available on MELPA, so the vast majority of Emacs packages do not use it.
In short, I cannot find a package that uses el-search.
The problem, I think, is that the package is only available on ELPA, which makes it rather obscure.
ag is available on windows:
https://github.com/ggreer/the_silver_searcher/wiki/Windows
... i haven't used it for a year though... no more Windows.
Ever used ag, the Silver Searcher ? It's like ack (a programmer's grep), but written in C, and blazingly fast. If you put the source on an SSD and use ag, you can search through all of it nearly instantaneously, and then you're not tied to any particular editor.
Also, GNU Global (gtags) does a very good job indexing chrome (about 90% of what I need). It falls short on member function calls to heavily-overloaded words like "Send" though, and anything super-heavy c++.. that's where rtags really shines. Gtags has the upside of being super easy to use and run, and it works well in the terminal and as a plugin in several editors.
All the previous answers are valid. However when looking for a string in many files there is something that put everything else to shame.
https://github.com/ggreer/the_silver_searcher
It is available in the repo of most distributions.
A Firefox extension called Tree Style Tab is 99% of the reason I still use Firefox. I tend to open a lot of things in tabs by middle-clicking (or ctrl-clicking), and this neatly nests them under the place where they came from, helping me to organize and trace trains of thought.
.NET reflector is great because we have a fuck-ton of internal .NET libraries that people refuse to document and whose source I don't know how to find and in .NET you can basically turn DLLs back into source with some limitations. I don't know that I'd be lost without it but I do take for granted the ability to decompile. (not free so no linky)
I use ag for text searches, mostly an IDE guy but sometimes the IDE is way too slow or the text files in question aren't part of a project. Very fast, but I do have to keep track of the binary which isn't super easy to make or find. (Chocolatey has ag, but my experiences with Chocolatey have not been fun)
It is times like these where ag is my best friend, unless I'm on Windows and then it goes Everything Search Engine -> ag.
Also, I've had tons of issues getting GLFW all linked up nicely with my applications. My best setup now is to use cmake for my thing and then either include source directories or git submodules in my repo along with a add_subdirectory() to the GLFW source (as well as GLM and glad).
It builds correctly in Visual Studios and MinGW-w64 on Windows and regular Makefiles on Linux (though, handling includes and libraries on Linux is so much nicer which makes having a regular handwritten Makefile that much easier to write).
i code stuffs.
seriously though, i'm a programmer / devops guy. i use a slightly tweaked version of my same environment on every machine. i just clone my dotfiles and install/setup my apps. herbstluftwm is my current wm of choice, but any simple tiler will do. a terminal w/ zsh, tmux, and vim are the main parts of my shell setup. like z-brah said, i also use grep, find, and sed quite a bit. but i have recently started using the silver surfer's ag utility. it's an ack clone that's SUPER fast, and integrates very well with vim.
I am an embedded linux developer. This means my projects will cross compile using different flags, compiler and libraries. Every time I spend the effort and try to get clang working for autocomplete and syntax checking, I realize it is just too much effort to keep it working. What works for me is:
https://github.com/ggreer/the_silver_searcher and https://github.com/rking/ag.vim, there's packages for ubuntu. Really fast searching even large codebases. Put your cursor on a word and press F3 to search with this binding: nnoremap <silent> <F3> :Ag <CR>
https://github.com/junkblocker/patchreview-vim need to find all those unstaged changes you littered across your source tree? gvim -cDiffReview
set a makeprg so you can just call :make and it will jump to all the errors reported
Agree the silver searcher is incredible; if you spend a lot of time in vim and you love ctrl-p you can set up silver searcher as your file lister; put this (or similar) in your .vimrc:
" The Silver Searcher if executable('ag') " Use ag over grep set grepprg=ag\ --nogroup\ --nocolor
" Use ag in CtrlP for listing files. Lightning fast and respects .gitignore let g:ctrlp_user_command = 'ag %s -l --nocolor -g "" --ignore "node_modules/"'
" ag is fast enough that CtrlP doesn't need to cache let g:ctrlp_use_caching = 0 endif
There is also a nice integration plugin ag.vim which gives you an :Ag command and a nice listing buffer; works beautifully. A coworker introduced me to ag, and I can not imagine going back to anything I had before.
Glad to hear that you figured it out.
From your command I can see that you are using vimgrep as your grep program. vimgrep works fairly robustly, unfortunately it is quite slow. Other tools like the ag, the silver searcher are much faster because they search in parallel. I've experimented with a lot of different tools and I have found that ag is the best tool overall given its correctness, ease-of-use, and performance.
I usually find the events I'm interested in by either reading the file I expect to find the event in (e.g. events/wol_seduction_events.txt), or by searching for the localization text and then the localization key. But sometimes I do more specific searches, e.g. if I want to find an event that removes the depressed trait.
My setup for doing this in a terminal is:
- In my .profile, a shortcut
ckiito switch to the directory~/Library/Application Support/Steam/SteamApps/common/Crusader Kings II - ag for searches
- Another shortcut,
e, for opening a file in a graphical editor
I use Emacs with Projectile, The Silver Searcher, and most definitely Magit.
Also:
$ vim grep some_word . -rl -p
In fact I use 'ag' ("The Silver Searcher") instead of grep. It runs a lot faster and easier to type:
$ vim ag some_word -l -p
I want to let you know that the --vimgrep option has been merged by ggreer to the master branch. You can give it a try by building Ag from the source.
Like ggreer said, it would be nice to split out some of these options. IMHO, good candidates are --line-per-match and --sep(arator) while keeping --vimgrep as an intuitive option.
Feedback is appreciated, Regards
Thank you all for your interest!!
You are giving great feedback and I'd love to hear some more.
The option name need improvement, I agree with you. Feel free to comment at the github's pull request. I'm trying to get an answer from the ag author.
Regards
ack is perl and ag is c so good luck, whichever is your cup of tea.
If you give it a go, you might want to file an issue first to see if it would be accepted.
There are not that many. Its github page has more or less a manual and some use cases, and its man page covers most of the options. Checking the code also can be useful: up until recently there was a hidden command line option I needed to make it work perfectly within my text editor, I think now it is a "normal" visible option with -h.
It's faster for searching code bases than grep, and it's also a little more friendly. I have just gotten used to it faster than with grep, even after years of using grep when needed.
Ag (the Silver Searcher) is better than Ack. It's basically the same thing, except implemented in C (instead of Perl) and crazy fast. Like, stupidly fast. Like, I can use Ag to search for something in a huge project like Chromium faster than using cscope/ctags/gnu global.
I like ag for file contents - it's incredibly fast. ag takes 48 seconds to search the entire contents of my 73gig ~ folder, without an index. grep takes 130 seconds for an equivalent search.
For just file names, I tend to use locate or find, or even just ag to rifle through the contents as it's so fast.
https://github.com/ggreer/the_silver_searcher
thats really good for searching through plain text files. About PDF I have no idea though, I keep them in google docs which searches the text-based ones.