2026 on Emacs@ Dyerdwelling

Ollama Buddy - Web Search Integration

James Dyer — Wed, 04 Mar 2026 09:34:00 +0000

One of the fundamental limitations of local LLMs is their knowledge cutoff - they don’t know about anything that happened after their training data ended. The new web search integration in ollama-buddy solves this by fetching current information from the web and injecting it into your conversation context. Ollama has a specific API web search section, so it has now been activated!

Here is a demonstration:

https://www.youtube.com/watch?v=05VzAajH404

The web search feature implements a multi-stage pipeline that transforms search queries into clean, LLM-friendly context, your search query is sent to Ollama’s Web Search API, the API returns structured search results with URLs and snippets.

I have decided that each URL by default is fetched and processed through Emacs’ built-in eww and shr HTML rendering, but this can of course be configured, set ollama-buddy-web-search-content-source to control how content is retrieved:

`eww’ (default): Fetch each URL and render through eww/shr for clean text
`api’: Use content returned directly from Ollama API (faster, less refined)

The shr (Simple HTML Renderer) library does an excellent job of converting HTML to readable plain text, stripping ads, navigation, and other noise, so I thought why not just use this rather than the return results from the ollama API, as they didn’t seem to be particularly accurate.

The cleaned text is formatted with org headings showing the source URL and attached to your conversation context, so when you send your next prompt, the search results are automatically included in the context. The LLM can now reason about current information as if it had this knowledge all along.

There are multiple ways to search; firstly, is inline @search() syntax in your prompts (gradually expanding the inline prompting language!), so for example:

What are the key improvements in @search(Emacs 31 new features)?
Compare @search(Rust async programming) with @search(Go concurrency model)

ollama-buddy automatically detects these markers, executes the searches, attaches the results, and then sends your prompt, so you can carry out multiple searches.

You can also manual Search and Attach, Use C-c / a (or M-x ollama-buddy-web-search-attach)

The search executes, results are attached to your session, and the ♁1 indicator appears in the header line and the results can be viewed from the attachments menu, so for example would display something like:

* Web Searches (1)
** latest Emacs 31 features
*** 1. Hide Minor Modes in the Modeline in Emacs 31
*** 2. New Window Commands For Emacs 31
*** 3. Latest version of Emacs (GNU Emacs FAQ)
*** 4. bug#74145: 31.0.50; Default lexical-binding to t
*** 5. New in Emacs 30 (GNU Emacs FAQ)

with each header foldable, containing the actual search results.

There is a little configuration required to go through the ollama API, first, get an API key from https://ollama.com/settings/keys (it’s free). Then configure:

(use-package ollama-buddy
 :bind
 ("C-c o" . ollama-buddy-role-transient-menu)
 ("C-c O" . ollama-buddy-transient-menu-wrapper)
 :custom
 ;; Required: Your Ollama web search API key
 (ollama-buddy-web-search-api-key "your-api-key-here"))

For clarification, the content source options are as follows:

The ollama-buddy-web-search-content-source variable controls how content is retrieved:

eww (default, recommended)

Fetches each URL and renders HTML through Emacs’ eww/shr. Produces cleaner, more complete content but requires additional HTTP requests.

Pros:

Much cleaner text extraction
Full page content, not just snippets
Removes ads, navigation, clutter
Works with any website

Cons:

Slightly slower (additional HTTP requests)
Requires network access for each URL

api (experimental)

Uses content returned directly from the Ollama API without fetching individual URLs. Faster but content quality depends on what the API provides.

Pros:

Faster (single API call)
Less network traffic

Cons:

Content may be truncated
Quality varies by source
May miss important context

I strongly recommend sticking with eww - the quality difference is substantial.

By default, web search fetches up to 5 URLs with 2000 characters per result. This provides rich context without overwhelming the LLM’s context window.

For longer research sessions, you can adjust:

(setq ollama-buddy-web-search-max-results 10) ;; More sources
(setq ollama-buddy-web-search-snippet-length 5000) ;; Longer excerpts

Be mindful of your LLM’s context window limits. With 5 results at 2000 chars each, you’re adding ~10K characters to your context.

The web search integration fundamentally expands what your local LLMs can do. They’re no longer limited to their training data - they can reach out, fetch current information, and reason about it just like they would with any other context, so hopefully this will now make ollama-buddy a little more useful

Ollama Buddy v2.5 - RAG (Retrieval-Augmented Generation) Support

James Dyer — Tue, 24 Feb 2026 11:50:00 +0000

One of the things that has always slightly bothered me about chatting with a local LLM is that it only knows what it was trained on (although I suppose most LLMs are like that) . Ask it about your own codebase, your org notes, your project docs - and it’s just guessing. Well, not anymore! Ollama Buddy now ships with proper Retrieval Augmented Generation support built-in

What even is RAG?

If you haven’t come across the term before, the basic idea is simple. Instead of asking the LLM a question cold, you first go off and find the most relevant bits of text from your own documents, then you hand those bits to the LLM along with your question. The LLM now has actual context to work with rather than just vibes. The “retrieval” part is done using vector embeddings - each chunk of your documents gets turned into a mathematical representation, and at query time your question gets the same treatment. Chunks that are mathematically “close” to your question are the ones that get retrieved.

In this case, I have worked to keep the whole pipeline inside Emacs; it talks to Ollama directly to contact an embedding model, which then returns the required information. I have tried to make this as Emacs Org-friendly as possible by storing the embedding information in Org files.

Getting started

You’ll need an embedding model pulled alongside your chat model. The default is nomic-embed-text which is a solid general-purpose choice:

ollama pull nomic-embed-text

or just do it within ollama-buddy from the Model Management page.

Indexing your documents

The main entry point is M-x ollama-buddy-rag-index-directory. Point it at a directory and it will crawl through, chunk everything up, generate embeddings for each chunk, and save an index file. The first time you run this it can take a while depending on how much content you have and how fast your machine is - subsequent updates are much quicker as it only processes changed files.

Supported file types (and I even managed to get pdf text extraction working!):

Emacs Lisp (.el)
Python, JavaScript, TypeScript, Go, Rust, C/C++, Java, Ruby - basically most languages
Org-mode and Markdown
Plain text
PDF files (if you have pdftotext from poppler-utils installed)
YAML, TOML, JSON, HTML, CSS

Files over 1MB are skipped (configurable), and the usual suspects like .git, node_modules, __pycache__ are excluded automatically.

The index gets saved into ~/.emacs.d/ollama-buddy/rag-indexes/ as a .rag file named after the directory. You can see what you’ve got with M-x ollama-buddy-rag-list-indexes.

The chunking strategy

One thing I’m quite happy with here is the chunking. Rather than just splitting on a fixed character count, documents are split into overlapping word-based chunks. The defaults are:

(setq ollama-buddy-rag-chunk-size 400) ; ~500 tokens per chunk
(setq ollama-buddy-rag-chunk-overlap 50) ; 50-word overlap between chunks

The overlap is important - it means a piece of information that sits right at a chunk boundary doesn’t get lost. Each chunk also tracks its source file and line numbers, so you can see exactly where a result came from.

Searching and attaching context

Once you have an index, there are two main ways to use it:

M-x ollama-buddy-rag-search - searches and displays the results in a dedicated buffer so you can read through them
M-x ollama-buddy-rag-attach - searches and attaches the results directly to your chat context

The second one is the useful one for day-to-day work. After running it, your next chat message will automatically include the retrieved document chunks as context. The status line shows ♁N (where N is the number of attached searches) so you always know what context is in play. Clear everything with M-x ollama-buddy-clear-attachments or C-c 0.

You can also trigger searches inline using the @rag() syntax directly in your prompt and is something fun I have been working on to include an inline command language of sorts, but more about that in a future post.

The similarity search uses cosine similarity with sensible defaults (hopefully!)

(setq ollama-buddy-rag-top-k 5) ; return top 5 matching chunks
(setq ollama-buddy-rag-similarity-threshold 0.3) ; filter out low-relevance results

Bump top-k if you want more context, lower the threshold if you’re not getting enough results.

A practical example

Say you’ve been working on a large Emacs package and you want the LLM to help you understand something specific. You’d do:

M-x ollama-buddy-rag-index-directory → point at your project directory
Wait for indexing to complete (the chat header-line shows progress)
M-x ollama-buddy-rag-attach → type your search query, e.g. “streaming filter process”
Ask your question in the chat buffer as normal

The LLM now has the relevant source chunks as context and can give you a much more grounded answer than it would cold.

And the important aspect, especially regarding local models which don’t often have the huge context sizes often found in online LLMs is that it allows for very efficient context retrieval.

That’s pretty much it!

The whole thing is self-contained inside Emacs, no external packages or vector databases, you index once, search as needed, and the LLM gets actual information rather than hallucinating answers about your codebase or anything else that you would want to ingest and it will hopefully make working with local LLMs through ollama noticeably more useful and accurate.

Ollama Buddy v2.0 - LLMs can now call Emacs functions!

James Dyer — Mon, 16 Feb 2026 08:56:00 +0000

Tool calling has landed in ollama-buddy!, it’s originally not something I really thought I would end up doing, but as ollama has provided tool enabled models and an API for this feature then I felt obliged to add it. So now LLMs through ollama can now actually do things inside Emacs rather than just talk about them, my original “do things only in the chat buffer and copy and paste” might have gone right out the window in an effort to fully support the ollama API!

What is Tool Calling?

The basic idea is simple: instead of the model only generating text, it can request to invoke functions. You ask “what files are in my project?”, and instead of guessing, the model calls list_directory, gets the real answer, and responds with actual information.

This creates a conversational loop:

You send a prompt
The model decides it needs to call a tool
ollama-buddy executes the tool and feeds the result back
The model generates a response using the real data
Steps 2-4 repeat if more tools are needed

All of this is transparent - you just see the final response in the chat buffer.

The new ollama-buddy-tools.el module ships with 8 built-in tools:

Safe tools (read-only, enabled by default):

read_file - read file contents
list_directory - list directory contents
get_buffer_content - read an Emacs buffer
list_buffers - list open buffers with optional regex filtering
search_buffer - regex search within a buffer
calculate - evaluate math expressions via calc-eval

Unsafe tools (require safe mode off):

write_file - write content to files
execute_shell - run shell commands

Safe mode is on by default, so the model can only read - it can’t modify anything unless you explicitly allow it, I think this is quite a nice simple implementation, at the moment I generally have safe mode off but always allowing confirmation for each tool action, but of course you can configure as necessary.

Example Session

With a tool-capable model like qwen3:8b and tools enabled (C-c W):

>> PROMPT: What defuns are defined in ollama-buddy-tools.el?

The model calls search_buffer with a regex pattern, gets the list of function definitions, and gives you a nicely formatted summary. No copy-pasting needed.

Custom Tools

You can register your own tools with ollama-buddy-tools-register:

 (ollama-buddy-tools-register
'my-tool
"Description of what the tool does"
'((type . "object")
(required . ["param1"])
(properties . ((param1 . ((type . "string")
(description . "Parameter description"))))))
(lambda (args)
(let ((param1 (alist-get 'param1 args)))
(format "Result: %s" param1)))
t) ; t = safe tool

The registration API takes a name, description, JSON schema for parameters, an implementation function, and a safety flag. The model sees the schema and decides when to call your tool based on the conversation.

A ⚒ symbol now appears next to tool-capable models everywhere - header line, model selector (C-c m), and model management buffer (C-c M). This follows the same pattern as the existing ⊙ vision indicator, so you can see at a glance which models support tools.

That’s it. Pull a tool-capable model (qwen3, llama3.1, mistral, etc.) or use an online tool enabled model from ollama and start chatting. Next up is probably some web searching!, as again the ollama API supports this, so you will be able to pull in the latest from the interwebs to augment your prompt definition!

Automatically Syncing Emacs Tab Bar Styling With Your Theme

James Dyer — Wed, 11 Feb 2026 18:26:00 +0000

If you’ve ever enabled a new theme and noticed your tab-bar faces stubbornly hanging onto old colours or custom tweaks, I have found often that the tab-bar, tab-bar-tab, and tab-bar-tab-inactive faces don’t always blend cleanly with freshly loaded themes — especially of the older variety (a bit like me) and especially ones that came out before the tab bar was introduced into Emacs.

So how about a simple solution?, Can I implement something, that whenever I load a theme, the tab-bar faces update based on the theme’s default faces to establish a visually pleasant and coherent look?

Yes, yes I can!; the result is a tiny Elisp enhancement that hooks directly into Emacs’ theme-loading process.

Firstly however we need to have a method that will reliably pass over the themes default faces to the tab-bar. Here’s the function that realigns the tab-bar styling with your active theme:

(defun selected-window-accent-sync-tab-bar-to-theme ()
"Synchronize tab-bar faces with the current theme."
(interactive)
(let ((default-bg (face-background 'default))
(default-fg (face-foreground 'default))
(inactive-fg (face-foreground 'mode-line-inactive)))
(custom-set-faces
`(tab-bar ((t (:inherit default :background ,default-bg :foreground ,default-fg))))
`(tab-bar-tab ((t (:inherit default :background ,default-fg :foreground ,default-bg))))
`(tab-bar-tab-inactive ((t (:inherit default :background ,default-bg :foreground ,inactive-fg)))))))

This simply rebuilds the key tab-bar faces so they derive their colours from the current theme’s normal face definitions, so any old themes should now not leave the tab bar faces hanging.

Now for the function activation; Emacs 29 introduced enable-theme-functions, a hook that runs every time a theme is enabled — perfect for our use case, but as always I have my eye on older Emacs versions, so lets fall back to a classic approach: advice on load-theme.

Here’s a version‑aware setup that does the right thing automatically:

(if (version<= "29.1" emacs-version)
;; Emacs 29.1+ — use the official theme hook
(add-hook 'enable-theme-functions
(lambda (_theme)
(selected-window-accent-sync-tab-bar-to-theme)))
;; Older Emacs — fall back to advising load-theme
(progn
(defun selected-window-accent-sync-tab-bar-to-theme--after (&rest _)
(selected-window-accent-sync-tab-bar-to-theme))
(advice-add 'load-theme :after
#'selected-window-accent-sync-tab-bar-to-theme--after)))

With this tweak in place, every time you change themes, your tab-bar instantly updates, colours stay consistent, clean, and theme‑accurate without you having to do anything at all! The downside to this of course is that any newer themes that were created after the advent of the tab bar in Emacs will have their tab-bar faces overridden, but for me this solution is good enough and gives a pleasant coherent visual tab bar experience.

Yay!, yet another Yak shaved!

Spent a bit of free time polishing ollama-buddy - github Copilot is now onboard!

James Dyer — Wed, 04 Feb 2026 10:40:00 +0000

I’ve had a little free time recently (figuring out this baby stuff!) and thought I would spend time revisiting and refining my AI assistant ollama-buddy

I’ve been playing around with agentic coding and keeping up-to-date on the rapid development of the Emacs AI package landscape and I think I have refined in my own mind my idea of what I would like to see in an Emacs AI assistant.

The headline change regarding the latest release of ollama-buddy is GitHub Copilot integration; the rest of the work is about smoothing the UI and simplifying day-to-day use.

What’s new - the Copilot addition (v1.2)

GitHub Copilot Chat API support via a new file, ollama-buddy-copilot.el, so Copilot models can be used alongside your existing providers.
Authentication uses GitHub’s device flow (OAuth). No API key required: M-x ollama-buddy-copilot-login opens a browser and guides you through secure authentication.
Copilot models are identified with a “p:” prefix (for example, p:gpt-4o). The header line shows a “p” indicator when the Copilot provider is loaded so you always know it’s available.
Copilot access exposes a broad set of models from multiple vendors through the Copilot interface: OpenAI (gpt-4o, gpt-5), Anthropic (claude-sonnet-4, claude-opus-4.5), Google (gemini-2.5-pro), and xAI models.
Quick usage notes:
1. Ensure you have an active GitHub Copilot subscription.
2. Run M-x ollama-buddy-copilot-login.
3. Enter the device code in your browser at github.com/login/device when prompted.
4. Select a Copilot model with C-c m (e.g., p:gpt-4o).
Example config to load Copilot support:

(use-package ollama-buddy
:bind
("C-c o" . ollama-buddy-menu)
("C-c O" . ollama-buddy-transient-menu-wrapper)
:config
(require 'ollama-buddy-copilot nil t))

Other notable updates in this release series

v1.2.1 (2026-02-02)
- Attachment count indicator on the header line so you get a constant visual reminder that the session has attachments.
v1.1.5 (2026-01-31)
- Global system prompt feature (enabled by default): sets a baseline set of instructions (for example, to prefer plain prose and avoid markdown tables) that is prepended to session-specific system prompts. This helps keep responses consistent across providers and things like malformed markdown tables for example, which seems to be common. There’s a toggle (ollama-buddy-global-system-prompt-enabled) and a quick command to flip it (ollama-buddy-toggle-global-system-prompt), plus a transient-menu entry.
- Consolidated model management: streamlined into a single model management buffer (C-c W) and the welcome screen now points to that buffer for model tasks.
v1.1.4 (2026-01-31)
- Header-line and keybinding cleanup: C-c RET to send prompts (matches gptel, as I feel this seems intuitive), removed a redundant backend indicator, shortened the markdown indicator to “MD”, and fixed markdown → org heading conversion to keep structure sane.
v1.1.3 (2026-01-31)
- Chat UX improvements and simplification: added ollama-buddy-auto-scroll (default nil — don’t auto-scroll so you can read while streaming) and ollama-buddy-pulse-response (flashes the response on completion, taking from gptel again, as if there is no autoscrolling it is useful to visually see when the response has completed). Removed the model name coloring feature and related toggles to simplify code and improve org-mode performance.
v1.1.2 (2026-01-30)
- Streamlined welcome screen and model selection, clearer provider indicators in the header line and an improved list of enabled online LLM providers.

Ollama buddy now supports cloud models!

James Dyer — Wed, 28 Jan 2026 08:29:00 +0000

Having another look at my AI assistant - ollama-buddy, its been a while and it seems ollama has moved on since I started creating this package last year, so I have developed a new roadmap and the first step is to add ollama cloud models!

Here are some references to the project, including a youtube channel where I upload ollama-buddy demonstrations:

https://melpa.org/#/ollama-buddy

https://github.com/captainflasmr/ollama-buddy

Here is the changelog for the cloud model implementation:

<2026-01-28 Wed> 1.1

Added Ollama Cloud Models support

Cloud models (running on ollama.com infrastructure) now work seamlessly
ollama-buddy-cloud-signin to automatically open browser for authentication
Cloud models are proxied through the local Ollama server which handles authentication
Use C-u C-c m or transient menu “Model > Cloud” to select cloud models
Status line shows ☁ indicator when using a cloud model
Available cloud models include: qwen3-coder:480b-cloud, deepseek-v3.1:671b-cloud, gpt-oss:120b-cloud, minimax-m2.1:cloud, and more

Auto-Populating Weekly Dates in Org-Mode Tables

James Dyer — Mon, 26 Jan 2026 10:13:00 +0000

Here is just a quick one, I was working with an org-mode table for tracking work weeks and needed to auto-populate a Date column where each row increments by exactly one week. The table structure looked like this:

The first row has a base date (2026-01-05), and I wanted subsequent rows to automatically calculate as weekly increments: 2026-01-12, 2026-01-19, and so on.

Initially, I tried several approaches that seemed logical but encountered #ERROR results and eventually settled on a working solution which is to hardcode the base date directly in the formula:

#+TBLFM: $3='(format-time-string "%Y-%m-%d" (time-add (date-to-time "2026-01-05") (* (- @# 2) 7 24 3600)))

which gave:

and I can now of course extend the table for all the weeks in the year and I don’t have to fill in manually any more!

Here’s how it works:

(date-to-time "2026-01-05") - Convert the hardcoded base date to Emacs time format
(- @# 2) - Calculate the offset from the base row
(* (- @# 2) 7 24 3600) - Convert the offset to seconds (weeks × days × hours × seconds)
time-add - Add the offset to the base date
format-time-string "%Y-%m-%d" - Format back to ISO date string

Speed Reading in Emacs: Building an RSVP Reader

James Dyer — Sun, 18 Jan 2026 10:30:00 +0000

I recently came across a fascinating video titled “How Fast Can You Read? - Speed Reading Challenge” that demonstrated the power of RSVP (Rapid Serial Visual Presentation) for speed reading. The concept is quite nice and simple and I vaguely remember seeing something about it a few years back. Instead of your eyes scanning across lines of text, words are presented one at a time in a fixed position. This eliminates the mechanical overhead of eye movements and can dramatically increase reading speed!

So, I immediately wondered, could I build this into Emacs?, actually no, firstly I thought, are there any packages for Emacs that can do this?, of course there are!, the spray package from MELPA is a more mature, feature-rich option if you’re looking for production-ready RSVP reading in Emacs, and also there is speedread. However, there’s something satisfying about having a compact, single-function solution that does exactly what you need, so lets see if I can build one!

RSVP works by displaying words sequentially in the same location on screen. Your eyes remain stationary, focused on a single point, while words flash by at a controlled pace. This technique can boost reading speeds to 300-600+ words per minute, compared to typical reading speeds of 200-300 WPM.

The key innovation is the Optimal Recognition Point (ORP) - typically positioned about one-third into each word. This is where your eye naturally fixates when reading. By aligning each word’s ORP at the same screen position, RSVP creates an optimal visual flow.

Given Emacs’ extensive text processing capabilities, this sounds something that Emacs could eat for breakfast. Here is what I came up with:

Here is a quick video of my implementation:

and the defun:

(defun rsvp-minibuffer ()
 "Display words from point (or mark to point) in minibuffer using RSVP.
Use f/s for speed, [/] for size, b/n to skip, SPC to pause, q to quit."
 (interactive)
 (let* ((start (if (region-active-p) (region-beginning) (point)))
 (end (if (region-active-p) (region-end) (point-max)))
 (text (buffer-substring-no-properties start end))
 (wpm 350) (font-size 200) (orp-column 20)
 (word-positions '()) (pos 0) (i 0)
 (message-log-max nil)) ; Disable message logging
 ;; Build word positions list
 (dolist (word (split-string text))
 (unless (string-blank-p word)
 (when-let ((word-start (string-match (regexp-quote word) text pos)))
 (push (cons word (+ start word-start)) word-positions)
 (setq pos (+ word-start (length word))))))
 (setq word-positions (nreverse word-positions))
 ;; Display loop
 (while (< i (length word-positions))
 (let* ((word (car (nth i word-positions)))
 (word-pos (cdr (nth i word-positions)))
 (word-len (length word))
 (delay (* (/ 60.0 wpm)
 (cond ((< word-len 3) 0.8) ((> word-len 8) 1.3) (t 1.0))
 (if (string-match-p "[.!?]$" word) 1.5 1.0)))
 (orp-pos (/ word-len 3))
 (face-mono `(:height ,font-size :family "monospace"))
 (face-orp `(:foreground "red" :weight normal ,@face-mono))
 (padded-word (concat
 (propertize (make-string (max 0 (- orp-column orp-pos)) ?\s) 'face face-mono)
 (propertize (substring word 0 orp-pos) 'face face-mono)
 (propertize (substring word orp-pos (1+ orp-pos)) 'face face-orp)
 (propertize (substring word (1+ orp-pos)) 'face face-mono))))
 (goto-char (+ word-pos word-len))
 (message "%s" padded-word)
 (pcase (read-event nil nil delay)
 (?f (setq wpm (min 1000 (+ wpm 50))))
 (?s (setq wpm (max 50 (- wpm 50))))
 (?\[ (setq font-size (max 100 (- font-size 20))))
 (?\] (setq font-size (min 400 (+ font-size 20))))
 (?b (setq i (max 0 (- i 10))))
 (?n (setq i (min (1- (length word-positions)) (+ i 10))))
 (?\s (read-event (format "%s [PAUSED - WPM: %d]" padded-word wpm)))
 (?q (setq i (length word-positions)))
 (_ (setq i (1+ i))))))))

The function calculates the ORP as one-third through each word and highlights it in red. By padding each word with spaces, the ORP character stays perfectly aligned in the same column, creating that crucial stationary focal point.

To ensure pixel-perfect alignment, the function explicitly sets a monospace font family for all displayed text. Without this, proportional fonts would cause the ORP to drift slightly between words, although I think at times there is a little waddle, but it is good enough.

Also, Not all words are created equal:

Short words (< 3 characters) display 20% faster
Long words (> 8 characters) display 30% slower
Words ending in punctuation (.!?) get 50% more time

This mimics natural reading rhythms where you’d naturally pause at sentence boundaries.

While reading, you can try these keybindings: (which I borrowed off spray)

f / s - Speed up or slow down (±50 WPM)
[ / ] - Decrease or increase font size
b / n - Skip backward or forward by 10 words
SPC - Pause (press any key to resume)
q - Quit
C-g - Emergency quit

Also The function tracks each word’s position in the original buffer and updates point as you read. This means:

You can see where you are in the text
When you quit, your cursor is at the last word you read
You can resume reading by running the function again

To use it, simply:

Position your cursor where you want to start reading (or select a region)
Run M-x rsvp-minibuffer
Watch the words flow in the minibuffer

The function works from point to end of buffer, or if you have an active region, it only processes the selected text.

If you’re curious about RSVP reading, drop this function into your Emacs config and give it a try. Start at 300-350 WPM and see how it feels. You might be surprised at how much faster you can consume text when your eyes aren’t constantly moving across the page.

The code is simple enough to customize - adjust the default WPM, change the ORP colour, modify the timing multipliers, or add new controls. That’s the beauty of Emacs, if you can imagine it, you can build it.

A single function ripgrep alternative to rgrep

James Dyer — Fri, 09 Jan 2026 09:43:00 +0000

For years, rgrep has been the go-to solution for searching codebases in Emacs. It’s built-in, reliable, and works everywhere. But it’s slow on large projects and uses the aging find and grep commands.

Packages like deadgrep and rg.el provide ripgrep integration, and for years I used deadgrep and really liked it. But what if you could get ripgrep’s speed with just a single function you paste into your config?

This post introduces a ~100 line defun that replaces rgrep, no packages, no dependencies, just pure Elisp. It’s fast, asynchronous, works offline, and mimics rgrep’s familiar interface so it can leverage grep-mode

So, why not just use rgrep?

I think that rgrep has three main limitations:

Firstly, speed. On a project with 10,000+ files, rgrep can take 15-30 seconds. Ripgrep completes the same search in under a second.

Secondly, file ignoring, rgrep requires manually configuring grep-find-ignored-directories or grep-find-ignored-files, I had the following typical configuration for rgrep, but it wasn’t as flexible as I would like it to be:

(eval-after-load 'grep
 '(progn
 (dolist (dir '("nas" ".cache" "cache" "elpa" "chromium" ".local/share" "syncthing" ".mozilla" ".local/lib" "Games"))
 (push dir grep-find-ignored-directories))
 (dolist (file '(".cache" "*cache*" "*.iso" "*.xmp" "*.jpg" "*.mp4"))
 (push file grep-find-ignored-files))
 ))

Ripgrep automatically respects an .ignore file. Just create an .ignore file in your project root and list patterns to exclude, this is just a simple text file, universally applied across all searches and any changes can be easily applied.

Thirdly, modern features. Ripgrep includes smart-case search, better regex support, and automatic binary file detection. Of course, there is a context that can be displayed around the found line, but in order to get ripgrep to work with grep-mode, this is not really doable, and it’s not something I need anyway.

Here is the complete ripgrep implementation that you can paste directly into your init.el:

(defun my/grep (search-term &optional directory glob)
 "Run ripgrep (rg) with SEARCH-TERM and optionally DIRECTORY and GLOB.
If ripgrep is unavailable, fall back to Emacs's rgrep command. Highlights SEARCH-TERM in results.
By default, only the SEARCH-TERM needs to be provided. If called with a
universal argument, DIRECTORY and GLOB are prompted for as well."
 (interactive
 (let* ((univ-arg current-prefix-arg)
 (default-search-term
 (cond
 ((use-region-p)
 (buffer-substring-no-properties (region-beginning) (region-end)))
 ((thing-at-point 'symbol t))
 ((thing-at-point 'word t))
 (t ""))))
 (list
 (read-string (if (string-empty-p default-search-term)
 "Search for: "
 (format "Search for (default `%s`): " default-search-term))
 nil nil default-search-term)
 (when univ-arg (read-directory-name "Directory: "))
 (when univ-arg (read-string "File pattern (glob, default: ): " nil nil "")))))
 (let* ((directory (expand-file-name (or directory default-directory)))
 (glob (or glob ""))
 (buffer-name "*grep*"))
 (if (executable-find "rg")
 (let ((buffer (get-buffer-create buffer-name)))
 (with-current-buffer buffer
 (setq default-directory directory)
 (let ((inhibit-read-only t))
 (erase-buffer)
 (insert (format "-*- mode: grep; default-directory: \"%s\" -*-\n\n" directory))
 (if (not (string= "" glob))
 (insert (format "[o] Glob: %s\n\n" glob)))
 (insert "Searching...\n\n"))
 (grep-mode)
 (setq-local my/grep-search-term search-term)
 (setq-local my/grep-directory directory)
 (setq-local my/grep-glob glob))

 (pop-to-buffer buffer)
 (goto-char (point-min))

 (make-process
 :name "ripgrep"
 :buffer buffer
 :command `("rg" "--color=never" "--max-columns=500"
 "--column" "--line-number" "--no-heading"
 "--smart-case" "-e" ,search-term
 "--glob" ,glob ,directory)
 :filter (lambda (proc string)
 (when (buffer-live-p (process-buffer proc))
 (with-current-buffer (process-buffer proc)
 (let ((inhibit-read-only t)
 (moving (= (point) (process-mark proc))))
 (setq string (replace-regexp-in-string "[\r\0\x01-\x08\x0B-\x0C\x0E-\x1F]" "" string))
 ;; Replace full directory path with ./ in the incoming output
 (setq string (replace-regexp-in-string
 (concat "^" (regexp-quote directory))
 "./"
 string))
 (save-excursion
 (goto-char (process-mark proc))
 (insert string)
 (set-marker (process-mark proc) (point)))
 (if moving (goto-char (process-mark proc)))))))
 :sentinel
 (lambda (proc _event)
 (when (memq (process-status proc) '(exit signal))
 (with-current-buffer (process-buffer proc)
 (let ((inhibit-read-only t))
 ;; Remove "Searching..." line
 (goto-char (point-min))
 (while (re-search-forward "Searching\\.\\.\\.\n\n" nil t)
 (replace-match "" nil t))

 ;; Clean up the output - replace full paths with ./
 (goto-char (point-min))
 (forward-line 3)
 (let ((start-pos (point)))
 (while (re-search-forward (concat "^" (regexp-quote directory)) nil t)
 (replace-match "./" t t))

 ;; Check if any results were found
 (goto-char start-pos)
 (when (= (point) (point-max))
 (insert "No results found.\n")))

 (goto-char (point-max))
 (insert "\nRipgrep finished\n")

 ;; Highlight search terms using grep's match face
 (goto-char (point-min))
 (forward-line 3)
 (save-excursion
 (while (re-search-forward (regexp-quote search-term) nil t)
 (put-text-property (match-beginning 0) (match-end 0)
 'face 'match)
 (put-text-property (match-beginning 0) (match-end 0)
 'font-lock-face 'match))))

 ;; Set up keybindings
 (local-set-key (kbd "D")
 (lambda ()
 (interactive)
 (my/grep my/grep-search-term
 (read-directory-name "New search directory: ")
 my/grep-glob)))
 (local-set-key (kbd "S")
 (lambda ()
 (interactive)
 (my/grep (read-string "New search term: "
 nil nil my/grep-search-term)
 my/grep-directory
 my/grep-glob)))
 (local-set-key (kbd "o")
 (lambda ()
 (interactive)
 (my/grep my/grep-search-term
 my/grep-directory
 (read-string "New glob: "))))
 (local-set-key (kbd "g")
 (lambda ()
 (interactive)
 (my/grep my/grep-search-term my/grep-directory my/grep-glob)))

 (goto-char (point-min))
 (message "ripgrep finished."))))
 )
 (message "ripgrep started..."))
 ;; Fallback to rgrep
 (progn
 (setq default-directory directory)
 (message (format "%s : %s : %s" search-term glob directory))
 (rgrep search-term (if (string= "" glob) "*" glob) directory)))))

That’s it. ~100 lines. No dependencies. No packages to manage! (well except ripgrep of course)

Now that I have complete control over this function, I have added further improvements over rgrep, inspired by deadgrep

S - New search term
D - New directory
o - New glob pattern
g - Re-run current search

and a universal argument can be passed through to set these up on the initial grep

I have tried to make the output as similar as possible to rgrep, to be compatible with grep-mode and for familiarity, so it will be something like:

-*- mode: grep; default-directory: "~/project/" -*-
[o] Glob: *.el
./init.el:42:10:(defun my-function ()
./config.el:156:5: (my-function)
./helpers.el:89:12:;; Helper for my-function
Ripgrep finished

and if a glob is applied it will display the glob pattern.

Its perfect for offline environments, and yes, I’m banging on about this again!, no network, no package manager, no dependencies (except ripgrep of course!)