deadgrep puts ripgrep inside Emacs and guesses your search context

One Emacs Lisp file wrapping a command line tool

deadgrep is an Emacs package for searching text with ripgrep. Its whole implementation lives in a single file, deadgrep.el, with a Cask file, a CHANGELOG.md, a docs directory holding the screenshots and a test directory beside it. The project is written in Emacs Lisp and is distributed through MELPA.

The audience is an Emacs user who has already accepted ripgrep as the search tool and would rather not leave the editor to type a command line. The package sits in the same space as the built-in M-x grep, but the search is executed by rg rather than by an Emacs regexp engine, which is the whole point of the design.

The repository is not archived and the last push was on 2026-08-18, on the master branch, and there are no GitHub releases, so the changelog file and the MELPA package are where version information lives. There is also no licence file among the top level entries of the repository, which is worth knowing before you copy any of the code into a project of your own.

Context awareness is the feature that saves keystrokes

Most of what makes deadgrep pleasant is inference rather than speed. The search term defaults to the active region if you have one selected. The search directory defaults to the root of the version control repository your current file sits in, so a search started from a file inside a repository covers the repository rather than the current directory. The regexp and case sensitivity options are carried over from your last search, so the same pattern stays in force.

File types and globbing are also suggested, based on the file you started the search from. If you are looking for a symbol in a source file, deadgrep can propose narrowing the search to that kind of file instead of matching it in every generated artefact in the tree.

Remote files are handled through Tramp: when you are editing a file on another machine, deadgrep searches that machine, which requires rg to be installed there. That last requirement is the one people miss. A Tramp session without ripgrep on the far side does not fall back to a local search, so the search either fails or is not what you expected.

Changing your mind is cheap, because the same settings can be altered from the results buffer by pushing the relevant button. The search term, search type and search directory can all be changed after the fact without retyping the command.

Installation: ripgrep 0.8, MELPA and one optional keybinding

There are two prerequisites and one optional step. First, ripgrep itself has to be on the system, and the README asks for version 0.8 or later. Second, you install the package itself, either with M-x package-install followed by RET and the name deadgrep inside Emacs 25.1 or later, or by copying the files into your ~/.emacs.d directory.

The optional step is a shortcut, and the README suggests F5 for it:

(global-set-key (kbd "<f5>") #'deadgrep)

Without that line the package still works, you just have to invoke deadgrep by name each time. With it, one key starts a search using the context described above, so the usual loop becomes: select the text you are looking at, press F5, read the results buffer, move to the hit you want.

Note what the install does not do for you. Nothing configures a keybinding automatically, nothing sets a search directory, and nothing checks that rg is on the PATH before you start searching. If rg is missing or too old, you find out when a search returns nothing.

A keyboard driven results buffer

The results buffer is where the package earns its place, and its keys are worth learning. Navigation is RET to visit the result at point, o to open it in another window, n and p to move between search hits, and M-n and M-p to move between file headers. The commands deadgrep-forward and deadgrep-backward move between buttons as well as hits, which matters when the results are grouped by file.

Search parameters are changed in place. S changes the search term, T cycles through the search types (string, words and regexp), C cycles through the case sensitivity modes (smart, sensitive and ignore), F cycles through the file modes (all, type and glob), and D changes the search directory. Two keys are less obvious. The caret re-runs the search in the parent directory, which is a quick way to widen a search you started too deep. And I switches to incremental search, re-running on every keystroke.

Stopping and starting are handled too. C-c followed by C-k stops a running search, and a prefix argument prevents the search commands from starting automatically, which is the escape hatch for when a key press would otherwise fire off a search you did not want.

The minibuffer is where you type the term, and it remembers: M-p reuses a previous search term and M-n lets you edit the default one.

deadgrep-debug shows the rg command behind the results

When results are not what you expected, the package offers a direct route to the truth. The deadgrep-debug function, run with M-x deadgrep-debug from a results buffer, opens a debug buffer showing the rg command that was executed along with its output and the environment used. From there you can read the exact command string and see for yourself whether the directory was the one you wanted, whether the file mode was applied, or whether rg errored out.

That is a much better answer than guessing at configuration, and it is the fastest way to learn what deadgrep actually did with your context. Two other commands round out the buffer handling: imenu moves between files in a results buffer, and deadgrep-kill-all-buffers kills all open deadgrep buffers, which is what you want after a session of many searches.

The package also adds polish that you notice only when it is missing elsewhere. A spinner tells you whether a search has finished, regexp syntax is highlighted according to the syntax rg accepts, the matching part of a line is highlighted when you navigate to it, TAB collapses and expands the results for a file, long minified lines are truncated for display, and jumping to a position works even in files that contain tab characters.

Editing from results is beta, and wgrep-deadgrep is the other route

The feature that would make deadgrep a complete replacement for a grep style workflow is editing files from the results buffer, and it is explicitly unfinished. The package provides M-x deadgrep-edit-mode, which lets you edit the matched files directly from the results, but the README marks it as currently in beta.

The alternative approach comes from a different package. wgrep is a separate Emacs package built around editing grep results, and in April 2023 it added support for deadgrep buffers through wgrep-deadgrep. That bridge enables editing behaviour that deadgrep itself does not provide, including deleting a line in edit mode with C-d.

The difference in approach is worth spelling out. deadgrep is a search interface that borrows rg's speed and adds context inference, then leaves the editing problem to another package. wgrep treats editing as the point and searches as the entry to it. If your workflow is mostly searching, deadgrep on its own is enough, and the bridge is only needed when you intend to change the matched text rather than only read it.

The limits you will hit first

The dependency on an external binary is the main one. deadgrep does not search anything by itself, and the README specifies ripgrep 0.8 or later, so a machine with an older rg, or with rg installed somewhere the Emacs process cannot see, produces an empty or failing search rather than an error message. The Tramp case is the sharper version of the same problem, since the far end of a remote session needs its own rg installation.

Second, the context inference can surprise you. Because the search directory defaults to the version control root and the file modes default to a suggestion, a search you thought was scoped to one directory may cover a whole repository, and one you thought would include generated files may exclude them. The debug buffer exists precisely because these defaults are guesses.

Third, the project has no tagged releases and no licence file at the top level. Without releases, there is no migration path between versions to plan for, and MELPA is where the packaged versions live. Without a licence file, the terms for reuse are not stated in the repository, which is a practical obstacle for anyone who intends to base work on the code rather than merely install it.

Finally, the keybinding surface is large. S, T, C, F, I, D, g and the caret all do different things inside the results buffer, and they are single keystrokes that shadow ordinary editing commands while the buffer is active. A new user will mispress something in the first ten minutes.

Editorial conclusion

Adopt deadgrep if you already live in Emacs, already run ripgrep in a terminal, and want the same search to arrive pre-configured instead of retyped. Do not adopt it if you need editing from the results buffer as a settled feature, since deadgrep-edit-mode is still beta, and do not adopt it if you plan to redistribute the code, because no licence file appears among the top level repository entries and the terms need checking before use. Before you bind a key, install ripgrep 0.8 or later and read the deadgrep-debug buffer once, because it shows the exact rg command, its output and the environment, and that single command tells you whether deadgrep searched the directory you expected.

Frequently asked questions

Official sources

1. Issues
2. README
3. Wilfred/deadgrep on GitHub