← Back to Blog

Short answer: Emacs has no native dictation, but a system-wide voice-to-text tool inserts text into any Emacs buffer without configuration. Pick a hotkey Emacs has not bound, make sure you are in insert state if you use Evil, and speak prose while typing the syntax.

Emacs users have an unusually strong reason to care about dictation, and it is not productivity. It is the hand. The chord-heavy key map that makes Emacs fast is also the one that produces the complaint the community named after itself, and a lot of people go looking for voice input in the same week their little finger starts objecting.

The good news is that the technical problem is smaller than it looks. Emacs is a text editor, buffers are text fields, and a dictation tool that inserts at point works in Emacs for the same reason it works everywhere else. The interesting part is not getting words into a buffer. It is knowing which words belong there, and which minor modes will mangle them on the way in.

This guide covers dictating in Emacs on macOS: setup and hotkey conflicts, the Evil mode trap, the modes worth toggling off, and the five kinds of writing where speaking genuinely beats typing.

You do not need a package for this

There are Emacs packages for voice input, and there is a long tradition of driving Emacs with speech-recognition grammars. That world is powerful and it is also a project. You configure a grammar, you learn a command vocabulary, you maintain it, and if you are trying to reduce keyboard strain this week rather than build a system this quarter, it is the wrong starting point.

The simpler approach is to keep dictation outside Emacs entirely. A system-wide tool that types at your cursor does not need to know what Emacs is, which means no elisp, no package, no configuration file that stops working after an upgrade. It also means the same tool works in your browser, your email, and your chat app, so you learn it once.

Voice Keyboard Pro works this way on the Mac. It sits in the menu bar, you hold a hotkey, speak, and release, and the text lands wherever the cursor is: an Org buffer, a docstring, a magit commit message, the minibuffer. Nothing is added to your Emacs configuration.

Setup: four things Emacs users specifically need to get right

1. Choose a hotkey Emacs has not already claimed

This matters more in Emacs than in any other application, because Emacs claims almost everything. Control and Meta chords are spoken for by definition, and on macOS your configuration has probably remapped Command or Option to Meta or Super, which quietly puts even more of the keyboard in play.

Pick something Emacs will never want. A single function key held down, or a right-side modifier used on its own, avoids the whole argument. If you have bound your dictation key to something Emacs also binds, you will get a mysterious command execution instead of a recording, and you will spend twenty minutes blaming the wrong software.

2. If you use Evil, be in insert state

This is the failure that scares people off in the first five minutes. Dictated text arrives as input. In Evil normal state, input is commands. Speak a sentence in normal state and you will watch your buffer get partially deleted, yanked, indented, and scrolled somewhere unfamiliar in about half a second.

Nothing is broken and nothing is unrecoverable. Press u until the buffer is back, press i, and try again. After a week, checking your state before you speak becomes as automatic as checking it before you type.

3. Consider what your minor modes will do to a spoken paragraph

Emacs is helpful, and some of that help fights dictation. The usual suspects:

4. Test in a scratch buffer first

C-x b, a throwaway buffer, fundamental mode, two dictated sentences. This confirms three things: that your hotkey survives Emacs, that text lands at point, and that punctuation behaves. If you run Emacs in a terminal, or you use an unusual key remapping setup, this thirty-second test is where you find out rather than in the middle of real work.

The five things worth dictating in Emacs

1. Org mode notes, journals and captures

Org is where most Emacs prose lives, and prose is what voice is for. Journal entries, meeting notes, project logs, the paragraph under a TODO that explains why the task exists at all. That last one is the highest-value and least-written text in most Org files, because a heading takes three seconds to type and the reasoning behind it takes three minutes.

The practical pattern: type the heading and any TODO keyword, tags and timestamp with the keys, then dictate the body underneath. Structure by keyboard, content by voice.

2. Comments and docstrings

Code is not dictation territory. Comments and docstrings absolutely are, and they are the part of a file most likely to be thin or missing. Explaining why a function takes an odd parameter, or what a non-obvious branch is defending against, is a sentence you would say out loud to a colleague in ten seconds and would probably not type.

Open the comment, dictate the explanation, then reflow. We go deeper on the general technique in dictating code comments, including how to phrase things so you are not fighting the transcription with symbol names.

3. Commit messages

The magit commit buffer is one of the best dictation surfaces in the whole editor. Almost everyone writes a short subject line and skips the body, because the body is the part that requires typing paragraphs at the exact moment you want to be finished. Speaking it costs nothing: what changed, why, what you considered and rejected, and what a future reader should be careful about.

Type the subject line, because it is short, conventional, and often contains an issue number. Dictate the body. If you also work in a terminal, the same applies there, and we covered that workflow in voice typing git commits in the terminal.

4. Documentation, README files and design notes

Long-form technical writing in Markdown or Org is where the speed difference compounds. Adult typing sits around 40 words per minute, professional typists reach 80 to 100, and comfortable speech runs at 130 to 150. Over a two-thousand-word design document, that gap is the difference between an afternoon and forty minutes, and the spoken version usually explains itself better because you write it the way you would explain it.

5. Email and long replies

If you read mail in Emacs, you already know that the reply which needed three paragraphs frequently gets one. That is the same input-cost problem in a different buffer. Dictate the reply, then edit it with the keys, which is the division of labour Emacs is best at.

Speak the sentences, type the syntax

The rule that makes this work is a boundary, not a technique. Voice is excellent at language and poor at strings of symbols that have to be exactly right.

Speak: explanations, commit bodies, docstring prose, notes, design rationale, replies, anything you could say aloud to another person and have them understand.

Type:

This boundary is also why the "control Emacs entirely by voice" ambition tends to disappoint people who just wanted to stop hurting. Driving an editor by voice is a real skill with a real learning curve. Dictating the prose parts and keeping your hands for the structural parts gives you most of the keystroke reduction on day one.

The identifier problem, and the fix

Every codebase has fifteen or twenty words that appear constantly and exist nowhere in ordinary English: the internal service name, the acronym your team uses for a subsystem, the library nobody outside your stack has heard of, your colleagues' surnames in code review comments. They are a small share of the words you speak and they show up in nearly every sentence.

Correcting them by hand every time is what makes people quit dictation in week two. Smart Vocabulary is a personal dictionary with replacement rules, so a term you say every day gets spelled your way from then on. Build it as you go rather than trying to seed everything at once. Fifteen entries covers most of a working day, and it is the difference between dictation feeling like a tool and feeling like a chore.

Draft by voice, edit by keyboard

Emacs is a better editing environment than it is a composing environment, and dictation splits those two jobs cleanly. Speak the draft in one pass without stopping to fix anything. Then use the editor you already know: M-q to reflow, query-replace for the term that landed wrong three times, a keyboard macro if the same fix repeats, the mark ring to move between the spots you flagged.

Expect a specific and small error profile from dictated text: occasional homophones, a stray or missing comma, and proper nouns that are not in your dictionary yet. What you generally do not get is the hedged, half-finished prose that typing produces when you edit and compose at the same time. Our guide to editing dictated text lays out the two-pass method in more detail.

One habit worth keeping: read anything before you commit or send it. A commit body is read by other people, sometimes years later, sometimes during an incident.

If your hands are the reason you are here

Plenty of people arrive at this topic because something hurts. If that is you, dictation is worth treating as one part of a setup rather than the whole answer. Moving comment writing, commit bodies, documentation and email off the keyboard removes a large share of daily keystrokes without giving up the chords you rely on for navigation and editing.

We wrote about the broader picture in using voice typing to prevent RSI, and about desk arrangement in voice typing ergonomics. The short version worth repeating here: alternating input methods through the day is the point, and speaking for eight hours straight has its own costs.

Terminal Emacs, remote sessions and other setups

Emacs in a terminal. Dictation inserts text into whatever is focused, so a terminal-hosted Emacs works. Your terminal emulator may claim the hotkey you chose, so test there specifically. The general terminal case is covered in voice typing in the terminal.

Remote Emacs over SSH or TRAMP. This works, because the typing happens locally and only the resulting characters cross the connection. There is nothing to install on the remote host.

Emacs inside a VM or remote desktop. More variable, since it depends on how that layer forwards input. Test in a scratch buffer before you rely on it.

Vim users reading this out of curiosity. The mode trap is identical and the workflow transfers directly. See dictating in Neovim.

Troubleshooting

Nothing appears. Check focus first: the frame must be active and point must be in a buffer that accepts input. Then check the hotkey for a collision with an Emacs binding or a terminal emulator binding.

My buffer exploded. Evil normal state. Undo, enter insert state, retry.

Text arrived hard-wrapped in odd places. auto-fill-mode. Toggle it off for the dictation pass, or accept it and reflow later.

Indentation went strange in a code comment. Auto-indent reacting to inserted newlines. Dictate one comment line at a time.

The same name is wrong every time. Vocabulary, not accuracy. One dictionary entry fixes it permanently.

Text landed in the minibuffer. A minibuffer prompt was open when you started. Escape out, then dictate.

Frequently asked questions

Do I need an Emacs package or elisp configuration?

No. A system-wide dictation tool inserts text at point the way your keyboard does. Nothing goes in your init file, and nothing breaks when you upgrade Emacs.

Can I control Emacs by voice, not just insert text?

That is a different category of tool, built around speech grammars and command vocabularies. It is genuinely powerful and it is a project. If your goal is fewer keystrokes this week, dictating prose gets you most of the benefit immediately.

Does this work with Doom or Spacemacs?

Yes. Both are configurations, not different editors. The only thing to watch is that both bind more keys than vanilla Emacs, so check for a hotkey conflict, and both default to Evil, so mind your state.

Should I dictate code?

Generally no. Symbols, identifiers and structure are faster and safer by hand. Dictate the words around the code, which is the part that is usually missing anyway.

Does it work offline?

No. The transcription engine needs a connection. Keep the built-in macOS dictation available as a fallback for flights and dead zones.

What happens to what I say?

Voice Keyboard Pro's servers store only operational pings. No audio and no transcript content. Your text goes into your buffer and stays there. That said, apply the same judgement you would with any tool: do not dictate credentials or secrets, in the same way you would not paste them into a chat window.

The bottom line

Emacs is a superb environment for manipulating text you have already written, and an ordinary one for producing it, because producing text is bounded by how fast your fingers move. Speaking runs at three times the pace of average typing, and the text most affected is exactly the text Emacs users skip: the commit body, the docstring, the paragraph under the TODO explaining why it exists.

Keep the chords for editing. Give the prose to your voice. Voice Keyboard Pro has a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year. Try it on your next commit message, which is the shortest possible demonstration of the difference.