How to Dictate in Neovim on Mac (Without Breaking Your Buffer)

Short answer: Dictate in Neovim by entering insert mode first, then using a system-wide dictation hotkey that types at the cursor. Because Neovim is modal, dictated text in normal mode fires editing commands instead of inserting words. Speak the prose, type the syntax.

Neovim is the one editor where dictation advice usually falls apart. Every guide written for a conventional editor assumes that text you produce goes into the document. In a modal editor that assumption is not just wrong, it is actively dangerous: text produced outside insert mode is interpreted as a sequence of commands, and a dictated sentence is a very long sequence of commands.

Which is a shame, because Neovim users have more to gain from dictation than most. The whole premise of modal editing is that your hands should stay on the home row and never reach for a mouse. Dictation extends the same idea in a direction the keyboard cannot go: it removes the hand movement entirely for the parts of your work that are prose rather than structure. Comments, docstrings, commit messages, design notes, pull request descriptions. That is a meaningful share of what you type in a day, and none of it benefits from being typed character by character.

This guide covers how to set it up on macOS, the one rule that keeps it safe, and honestly where dictation helps and where it does not. If you work across editors, we have companion guides for dictating in Zed and dictating in Xcode.

Why Neovim needs a different approach

Neovim has no dictate button and never will. It also has no text field in the sense a dictation tool expects, because in a terminal it is drawing characters into a grid rather than hosting a native macOS text control. Anything that tries to integrate with the editor's own input handling is fighting the architecture.

The approach that works is the simplest one. Use a dictation tool that types at the system cursor, exactly as a keyboard would. From Neovim's point of view, nothing unusual is happening. Characters arrive at the input stream and get handled by whatever mode the editor is currently in. There is no plugin to install, no configuration to write, and no difference in behavior between terminal Neovim and a GUI build.

That property is what makes system-wide dictation the right shape for this problem, and it is the same reason it works in a shell prompt. If you spend time there too, our guide to voice typing in the terminal covers the specifics.

The one rule: insert mode first

Here is the rule that makes all of this safe, and it is worth internalizing before you dictate a single word.

Press i before you press the mic. Always. No exceptions.

If you dictate in normal mode, every character of your sentence is a command. Words containing d, c, x, and p will delete, change, cut, and paste their way through your buffer in ways that are genuinely difficult to reason about afterward. Uppercase letters make it worse. The result is not a typo you can fix by hand; it is a scrambled buffer.

Three habits keep you out of trouble:

• Make insert mode a physical part of the gesture. Enter insert mode, then reach for the dictation hotkey. Treat them as one motion rather than two decisions.
• Glance at the mode indicator. Your statusline already tells you which mode you are in. Use it. This is a one-second check that prevents the only serious failure mode in this workflow.
• Know your undo. If it does go wrong, u repeatedly is your friend, and Neovim's persistent undo means the history survives. It is worth confirming your config has undofile enabled before you start experimenting.

Once the habit forms, this stops being something you think about. It is the same muscle memory that already stops you from typing prose into normal mode when you return from a meeting.

Setting it up on macOS

The setup is deliberately boring, which is the point.

1. Install a dictation tool that inserts text at the cursor system-wide. Voice Keyboard Pro lives in the menu bar and works this way: hold a hotkey, speak, release, and the text appears wherever your cursor is.
2. Grant the macOS permissions it asks for on first launch. This is what allows text insertion into any app, terminal emulators included.
3. Pick a hotkey that does not collide with anything. This matters more for Neovim users than for most people, and the next section explains why.
4. Open Neovim, press i, hold the hotkey, and speak a sentence.

There is no step five. Because the text arrives as though typed, it works identically in Ghostty, kitty, WezTerm, Alacritty, Terminal, or a GUI Neovim build. It works over SSH into a remote machine, since the insertion happens locally and the characters travel the same path your keystrokes do. It works inside tmux.

Choosing a hotkey that survives your config

Neovim users have unusually crowded keyboard shortcut space. Between your leader mappings, your terminal emulator's bindings, your tmux prefix, and macOS system shortcuts, a lot of obvious combinations are taken.

Two things to check. First, whether the combination is claimed by macOS in System Settings under Keyboard Shortcuts. Second, whether your terminal emulator intercepts it before the shell or editor sees it. A modifier-held key that you never use in normal typing tends to work well, and holding rather than toggling means there is no state to get out of sync with your editing mode.

What to dictate and what to type

This is where most people either succeed or give up, so it is worth being blunt about it.

Do not dictate code. Not because it cannot be made to work, but because it is slower and more annoying than typing it. Code is dense with symbols, brackets, and precise casing. Speaking const handleSubmit = async (event) => { out loud takes longer than typing it and produces something you then have to fix. Your fingers are already good at syntax, and so is your completion engine.

Do dictate the prose. Everything in a codebase that is written in English rather than in a language grammar is a candidate:

• Comments explaining why. The comment that explains a non-obvious tradeoff is the most valuable comment in any codebase and the one least likely to get written, because writing it interrupts the flow of the work. Speaking it costs almost nothing.
• Docstrings and function documentation. Type the delimiters, speak the description, parameters, and return semantics.
• Commit messages. The commit body is where reasoning belongs, and it is chronically underwritten because you are writing it at the end of a task when your patience is gone. Dictating a real three-sentence explanation takes about fifteen seconds. We cover this workflow in more depth in our guide to voice typing git commit messages.
• Markdown docs and READMEs. Long-form prose in a buffer is the single best case for dictation in Neovim. There is no syntax to speak, and you are in insert mode continuously.
• Pull request descriptions and issue text. Often drafted in a buffer before being pasted elsewhere.
• Prompts to AI coding assistants. If you use a plugin that takes a natural language prompt, that prompt is prose, and a longer prompt with real context produces a better result. Dictation removes the tax on being specific.

The pattern across all of these is the same. Speak the sentences, type the symbols. Our post on dictating code comments goes further into the specific rhythms that work.

Punctuation, and the editing pass

Two practical notes that make the output usable.

First, punctuation. Voice Keyboard Pro's transcription engine handles ordinary sentence punctuation from your natural delivery, so a normally spoken sentence arrives already punctuated. You do not need to say "period" at the end of every line the way older dictation systems required. Where you do want explicit control, saying the mark works.

Second, and this is the part that fits Neovim particularly well: dictate first, edit after. Get the paragraph out of your head and into the buffer without stopping to fix anything. Then press Esc and do what you are already extremely fast at. Reflowing a paragraph with gq, changing a word with ciw, joining lines, fixing a phrase with a substitution across the block. Modal editing is a genuinely excellent revision tool, and it pairs better with a fast rough draft than with slow careful typing.

That two-phase split is the actual argument for dictation in a modal editor. You are not replacing your editing workflow. You are feeding it faster.

Watch out for autopairs and completion

One real friction point worth naming. Dictated text arrives quickly, and plugins that react to what you type can react to it.

Auto-pairing plugins insert closing brackets and quotes as you type opening ones. If your dictated prose contains a quotation mark or parenthesis, you may end up with a stray closing character. Completion popups can also appear mid-insertion, though since dictation types plain characters rather than pressing Enter or Tab, they generally do not accept a suggestion on their own.

Neither is a serious problem for prose, which is mostly words. If it does annoy you, dictating into a buffer with autopairs disabled for markdown filetypes is a small config change that removes the issue for exactly the case where you dictate most.

The identifiers problem

Here is the failure you will hit that no amount of technique solves. Your codebase has names in it. Internal service names, library names, domain-specific abbreviations, the particular way your team capitalizes a product. A general speech model has never seen any of them, so it guesses, and it guesses differently each time.

Dictating a comment that mentions your internal auth service by name, three times, and getting three different spellings is the thing that makes people quit. It is also the one accuracy problem that is not about your microphone or your enunciation.

Voice Keyboard Pro's Smart Vocabulary on the Mac addresses this directly. You add the terms you actually use along with replacement rules, and they come out spelled your way rather than being re-guessed on every dictation. For a codebase with a consistent vocabulary, this is the difference between dictation being useful and dictation being a correction chore. Casing conventions get their own treatment in our post on dictating camelCase and snake_case.

Away from the desk

The thinking that goes into code does not stay at the desk, and neither does the writing. The Voice Keyboard Pro iPhone keyboard has a mic button built in, so the design note you work out on a walk or the issue description that occurs to you on a commute can be captured in whatever app you already use for notes, then pasted into a buffer later. Voice Edit lets you speak a correction rather than tapping through text on a phone screen, which matters when the thing you are capturing is three paragraphs long.

Worth stating plainly for anyone dictating about proprietary code: Voice Keyboard Pro's servers store only operational pings. No audio, no transcript content. As with any tool you point at work you do not own, check what your employer's policy allows before dictating anything sensitive.

Frequently asked questions

Is there a Neovim plugin for dictation?

You do not need one, and that is the better outcome. A system-wide tool that types at the cursor works in every mode, every terminal emulator, over SSH, and inside tmux, with nothing to configure or keep updated against breaking changes.

What happens if I dictate in normal mode?

Every character becomes a command and your buffer gets scrambled. Press u repeatedly to undo. Then build the habit of entering insert mode before reaching for the mic, because prevention is the only real fix here.

Does this work over SSH?

Yes. Text insertion happens on your Mac and the characters travel to the remote host the same way your keystrokes do. The remote machine cannot tell the difference.

Can I dictate actual code?

You can, but you will be slower than typing it. Symbols, brackets, and casing are exactly what speech is bad at and fingers are good at. The value is in the prose: comments, docstrings, commit messages, and documentation. Our broader guide to dictation for coding covers where the line sits.

Does it work in Vim as well as Neovim?

Yes. The mechanism is character insertion at the cursor, so anything that accepts keyboard input accepts it, including classic Vim and vi-mode in your shell.

Getting started

Try one thing this week. The next time you finish a piece of work and reach the commit message, stop before typing. Enter insert mode, hold the hotkey, and explain out loud what you changed and why, in three sentences, as though telling a colleague. Read what lands in the buffer.

Most people find it is the best commit message they have written in months, and it took less time than the one-line version they would have typed. That gap is the whole case: speech runs at 130 to 150 words per minute against roughly 40 for an average typist and 80 to 100 for a fast one, and it costs you nothing to reach for because you already know how to talk.

Voice Keyboard Pro has a free tier with daily limits, with Pro at $4.99 a month or $34.99 a year. Press i first.