Vim-pencil: Rethinking Vim as a tool for writing

2026-02-130:3515755github.com

Rethinking Vim as a tool for writing. Contribute to preservim/vim-pencil development by creating an account on GitHub.

Vint

Rethinking Vim as a tool for writers


demo

The pencil plugin aspires to make Vim as powerful a tool for writers as it is for coders by focusing narrowly on the handful of tweaks needed to smooth the path to writing prose.

  • For editing prose-oriented file types such as text, markdown, mail, rst, tex, textile, and asciidoc
  • Agnostic on soft line wrap versus hard line breaks, supporting both
  • Auto-detects wrap mode via modeline and sampling
  • Adjusts navigation key mappings to suit the wrap mode
  • Creates undo points on common punctuation during Insert mode, including deletion via line <C-U> and word <C-W>
  • Buffer-scoped configuration (with a few minor exceptions, pencil preserves your global settings)
  • Support for Vim’s Conceal feature to hide markup defined by Syntax plugins (e.g., _ and * markup for styled text in _Markdown_)
  • Support for display of mode indicator ( and , e.g.) in the status line
  • Pure Vimscript with no dependencies

In addition, when using hard line break mode:

  • Makes use of Vim’s powerful autoformat while inserting text, except for tables and code blocks where you won’t want it.
  • NEW Optional key mapping to suspend autoformat for the Insert.

Need spell-check, distraction-free editing, and other features? Vim is about customization. To complete your editing environment, learn to configure Vim and draw upon its rich ecosystem of plugins.

With plenty of word processing applications available, including those that specifically cater to writers, why use a modal editor like Vim? Several reasons have been offered:

  • Your hands can rest in a neutral ‘home’ position, only rarely straying to reach for mouse, track pad, or arrow keys
  • Minimal chording, with many mnemonic-friendly commands
  • Sophisticated capabilities for navigating and manipulating text
  • Highly configurable, enabling you to build a workflow that suits your needs, with many great plugins available
  • No proprietary format lock-in

But while such reasons might be sound, they remain scant justification to switch away from the familiar word processor. Instead, you need a compelling reason—one that can appeal to a writer’s love for language and the tools of writing.

You can find that reason in Vim’s mysterious command sequences. Take cas for instance. You might see it as a mnemonic for Change Around Sentence to replace an existing sentence. But dig a bit deeper to discover that such commands have a grammar of their own, comprised of nouns, verbs, and modifiers. Think of them as the composable building blocks of a domain specific language for manipulating text, one that can become a powerful tool in expressing yourself. For more details on vi-style editing, see...

You can install using your favorite Vim package manager. (E.g., Pathogen, Vundle, or Plug.) If you are using a recent version of vim or neovim, you can also use native package support. (See :help packages.)

For those new to Vim: before installing this plugin, consider getting comfortable with the basics of Vim by working through one of the many tutorials available.

You can manually enable, disable, and toggle pencil as a command:

  • Pencil - initialize pencil with auto-detect for the current buffer
  • NoPencil (or PencilOff) - removes navigation mappings and restores buffer to global settings
  • TogglePencil (or PencilToggle) - if on, turns off; if off, initializes with auto-detect

Because auto-detect might not work as intended, you can invoke a command to set the behavior for the current buffer:

  • SoftPencil (or PencilSoft) - initialize pencil with soft line wrap mode
  • HardPencil (or PencilHard) - initialize pencil with hard line break mode (and Vim’s autoformat)

Initializing pencil by file type is optional, though doing so will automatically set up your buffers for editing prose.

Add support for your desired file types to your .vimrc:

set nocompatible
filetype plugin on " may already be in your .vimrc augroup pencil autocmd! autocmd FileType markdown,mkd call pencil#init() autocmd FileType text call pencil#init()
augroup END

You can initialize several prose-oriented plugins together:

augroup pencil autocmd! autocmd FileType markdown,mkd call pencil#init() \ | call lexical#init() \ | call litecorrect#init() \ | call textobj#quote#init() \ | call textobj#sentence#init()
augroup END

For a list of other prose-oriented plugins, consult the See also section below.

Coders will have the most experience with the former, and writers the latter. But whatever your background, chances are that you must contend with both conventions. This plugin doesn’t force you to choose a side—you can configure each buffer independently.

In most cases you can set a default to suit your preference and let auto-detection figure out what to do.

let g:pencil#wrapModeDefault = 'soft' " default is 'hard' augroup pencil autocmd! autocmd FileType markdown,mkd call pencil#init() autocmd FileType text call pencil#init({'wrap': 'hard'})
augroup END

In the example above, for buffers of type markdown this plugin will auto-detect the line wrap approach, with soft line wrap as the default.

For buffers of type text, it will initialize with hard line breaks, even if auto-detect might suggest soft line wrap.

The ‘autoformat’ feature affects HardPencil (hard line break) mode only.

When inserting text while in HardPencil mode, Vim’s powerful autoformat feature will be enabled by default and can offer many of the same benefits as soft line wrap.

To set the default behavior in your .vimrc:

let g:pencil#autoformat = 1 " 0=disable, 1=enable (def)

You can override this default during initialization, as in:

augroup pencil autocmd! autocmd FileType markdown call pencil#init({'wrap': 'hard', 'autoformat': 1}) autocmd FileType text call pencil#init({'wrap': 'hard', 'autoformat': 0}) ...
augroup END

...where buffers of type markdown and text will use hard line breaks, but text buffers will have autoformat disabled.

There are two useful exceptions where autoformat (when enabled for the buffer) will be temporarily disabled for the current Insert:

First is pencil’s ‘blacklisting’ feature: if used with popular prose-oriented syntax plugins, pencil will suspend autoformat when you enter Insert mode from inside a code block or table.

Second, where blacklisting falls short, you can optionally map a buffer-scoped ‘modifier’ key to suspend autoformat during the next Insert:

let g:pencil#map#suspend_af = 'K' " default is no mapping

Using the above mapping, with Ko you’ll enter Insert mode with the cursor on a new line, but autoformat will suspend for that Insert. Using o by itself will retain autoformat.

By default no modifier key is mapped.

(See the advanced section below for details on how blacklisting is implemented and configured).

Note that you need not rely on Vim’s autoformat exclusively and can manually reformat paragraphs with standard Vim commands:

  • gqap - format current paragraph (see :help gq for details)
  • vapJgqap - merge two paragraphs (current and next) and format
  • ggVGgq or :g/^/norm gqq - format all paragraphs in buffer

Optionally, you can map these operations to underutilized keys in your .vimrc:

nnoremap <silent> Q gqap
xnoremap <silent> Q gq
nnoremap <silent> <leader>Q vapJgqap

Or you may wish to ‘unformat’, (i.e., remove hard line breaks) when using soft line wrap.

  • vipJ - join all lines in current paragraph
  • :%norm vipJ - unformat all paragraphs in buffer

You can configure the textwidth to be used in HardPencil (hard line break) mode when no textwidth is set globally, locally, or available via modeline. It defaults to 74, but you can change that value in your .vimrc:

let g:pencil#textwidth = 74

By default, when formatting text (through gwip, e.g.) only one space will be inserted after a period(.), exclamation point(!), or question mark(?). You can change this default:

let g:pencil#joinspaces = 0 " 0=one_space (def), 1=two_spaces

By default, h/l and the left/right cursor keys will move to the previous/next line after reaching first/last character in a line with a hard break. If you wish to retain the default Vim behavior, set the cursorwrap value to 0 in your .vimrc:

let g:pencil#cursorwrap = 1 " 0=disable, 1=enable (def)

pencil enables Vim’s powerful Conceal feature, although support among Syntax and Colorscheme plugins is currently spotty.

You can change pencil’s default settings for conceal in your .vimrc:

let g:pencil#conceallevel = 3 " 0=disable, 1=one char, 2=hide char, 3=hide all (def)
let g:pencil#concealcursor = 'c' " n=normal, v=visual, i=insert, c=command (def)

For more details on Vim’s Conceal feature, see:

:help conceallevel
:help concealcursor

Syntax plugins such as tpope/vim-markdown support concealing the markup characters when displaying _italic_, **bold**, and ***bold italic*** styled text.

To use Vim’s Conceal feature with Markdown, you will need to install:

  1. tpope/vim-markdown as it’s currently the only Markdown syntax plugin that supports conceal.

  2. A monospaced font (such as Cousine) featuring the italic, bold, and bold italic style variant for styled text.

  3. A colorscheme (such as preservim/vim-colors-pencil) which supports the Markdown-specific highlight groups for styled text.

You should then only see the _ and * markup for the cursor line and in visual selections.

Terminal users: consult your terminal’s documentation to configure your terminal to support bold and italic styles.

Your status line can reflect the wrap mode for pencil buffers. For example, to represent HardPencil (hard line break) mode. To configure your status line and ruler, add to your .vimrc:

set statusline=%<%f\ %h%m%r%w\ \ %{PencilMode()}\ %=\ col\ %c%V\ \ line\ %l\,%L\ %P
set rulerformat=%-12.(%l,%c%V%)%{PencilMode()}\ %P

or if using bling/vim-airline:

let g:airline_section_x = '%{PencilMode()}'

The default indicators now include ‘auto’ for when Vim’s autoformat is active in hard line break mode. (If autoformat is suspended for the Insert, it’ll show the ‘hard’ indicator.)

let g:pencil#mode_indicators = {'hard': 'H', 'auto': 'A', 'soft': 'S', 'off': '',}

If Unicode is detected, the default indicators are:

let g:pencil#mode_indicators = {'hard': '', 'auto': 'ª', 'soft': '', 'off': '',}

If you don’t like the default indicators, you can specify your own in your .vimrc.

Note that PencilMode() will return blank for buffers in which pencil has not been initialized.

You may want to refactor initialization statements into a function in your .vimrc to set up a buffer for writing:

function! Prose() call pencil#init() call lexical#init() call litecorrect#init() call textobj#quote#init() call textobj#sentence#init()  " manual reformatting shortcuts nnoremap <buffer> <silent> Q gqap
 xnoremap <buffer> <silent> Q gq
 nnoremap <buffer> <silent> <leader>Q vapJgqap

 " force top correction on most recent misspelling nnoremap <buffer> <c-s> [s1z=<c-o>
 inoremap <buffer> <c-s> <c-g>u<Esc>[s1z=`]A<c-g>u

 " replace common punctuation iabbrev <buffer> --iabbrev <buffer> ---iabbrev <buffer> << « iabbrev <buffer> >> »  " open most folds setlocal foldlevel=6  " replace typographical quotes (reedes/vim-textobj-quote) map <silent> <buffer> <leader>qc <Plug>ReplaceWithCurly
 map <silent> <buffer> <leader>qs <Plug>ReplaceWithStraight

 " highlight words (reedes/vim-wordy) noremap <silent> <buffer> <F8> :<C-u>NextWordy<cr>
 xnoremap <silent> <buffer> <F8> :<C-u>NextWordy<cr>
 inoremap <silent> <buffer> <F8> <C-o>:NextWordy<cr>

endfunction " automatically initialize buffer by file type
autocmd FileType markdown,mkd,text call Prose() " invoke manually by command for other file types
command! -nargs=0 Prose call Prose()

For highly-granular control, you can override pencil and other configuration settings when initializing buffers by file type:

augroup pencil autocmd! autocmd FileType markdown,mkd call pencil#init() \ | call litecorrect#init() \ | setl spell spl=en_us fdl=4 noru nonu nornu \ | setl fdo+=search autocmd Filetype git,gitsendemail,*commit*,*COMMIT* \  call pencil#init({'wrap': 'hard', 'textwidth': 72}) \ | call litecorrect#init() \ | setl spell spl=en_us et sw=2 ts=2 noai autocmd Filetype mail call pencil#init({'wrap': 'hard', 'textwidth': 60}) \ | call litecorrect#init() \ | setl spell spl=en_us et sw=2 ts=2 noai nonu nornu autocmd Filetype html,xml call pencil#init({'wrap': 'soft'}) \ | call litecorrect#init() \ | setl spell spl=en_us et sw=2 ts=2
augroup END

Configurable options for pencil#init() include: autoformat, concealcursor, conceallevel, cursorwrap, joinspaces, textwidth, and wrap. These are detailed above.

The ‘autoformat’ feature affects HardPencil (hard line break) mode only.

To suspend autoformat for the next Insert, see above.

When you need to manually enable/disable autoformat for the current buffer, you can do so with a command:

  • PFormat - enable autoformat for buffer (can still be disabled via blacklisting)
  • PFormatOff - disable autoformat for buffer
  • PFormatToggle - toggle to enable if disabled, etc.

You can map a key in your .vimrc to toggle Vim’s autoformat:

noremap <silent> <F7> :<C-u>PFormatToggle<cr>
inoremap <silent> <F7> <C-o>:PFormatToggle<cr>

The ‘autoformat’ feature affects HardPencil (hard line break) mode only.

When editing formatted text, such as a table or code block, Vim’s autoformat will wreak havoc with the formatting. In these cases you will want autoformat suspended for the duration of the Insert.

When entering Insert mode, pencil will determine the highlight group at the cursor position. If that group has been blacklisted, pencil will suspend autoformat for the Insert. For example, if editing a buffer of type ‘markdown’, autoformat will be suspended if you invoke Insert mode from inside a markdownFencedCodeBlock highlight group.

Blacklists are now declared by file type. The default blacklists (and whitelists) are declared in the plugin/pencil.vim module. Here’s an excerpt showing the configuration for the ‘markdown’ file type:

 let g:pencil#autoformat_config = { \  'markdown': { \  'black': [ \  'htmlH[0-9]', \  'markdown(Code|H[0-9]|Url|IdDeclaration|Link|Rule|Highlight[A-Za-z0-9]+)', \  'markdown(FencedCodeBlock|InlineCode)', \  'mkd(Code|Rule|Delimiter|Link|ListItem|IndentCode)', \  'mmdTable[A-Za-z0-9]*', \  ], \  'white': [ \  'markdown(Code|Link)', \  ], \  }, [snip] \ }

The whitelist will override the blacklist and enable Vim’s autoformat if text that would normally be blacklisted doesn’t dominate the entire line. This allows autoformat to work with inline code and links.

If you didn’t explicitly specify a wrap mode during initialization, pencil will attempt to detect it.

It will first look for a textwidth (or tw) specified in a modeline. Failing that, pencil will then sample lines from the start of the buffer.

Will the wrap mode be detected accurately? Maybe. But you can improve its chances by giving pencil an explicit hint.

At the bottom of this document is a odd-looking code:

This is an optional ‘modeline’ that tells Vim to run the following command upon loading the file into a buffer:

It tells pencil to assume hard line breaks, regardless of whether or not soft line wrap is the default editing mode for buffers of type ‘markdown’.

You explicitly specify soft wrap mode by specifying a textwidth of 0:

Note that if the modelines feature is disabled (such as for security reasons) the textwidth will still be set by this plugin.

If no modeline with a textwidth is found, pencil will sample the initial lines from the buffer, looking for those excessively-long.

There are two settings you can add to your .vimrc to tweak this behavior.

The maximum number of lines to sample from the start of the buffer:

let g:pencil#softDetectSample = 20

Set that value to 0 to disable detection via line sampling.

When the number of bytes on a sampled line per exceeds this next value, then pencil assumes soft line wrap.

let g:pencil#softDetectThreshold = 130

If no such lines found, pencil falls back to the default wrap mode.

Bloggers and developers discuss pencil and its brethern:

Other plugins of specific interest to writers:

Markdown syntax plugins

Markdown users typically won’t need to install a syntax plugin unless they want the latest version of Pope’s syntax highlighting:

  • tpope/vim-markdown - (recommended) the latest version of Pope’s syntax plugin which ships with Vim

Those using tables and footnotes should consider installing this plugin:

Alternatives to Tim Pope’s syntax highlighting include:

Note that the plasticboy and gabrielelana plugins may incorrectly reformat bulleted lists when Vim’s autoformat is active in pencil’s HardPencil mode.

If you find the pencil plugin useful, check out these others originally by @reedes:

Unimpressed by pencil? vim-pandoc offers prose-oriented features with its own Markdown variant.

If you’ve spotted a problem or have an idea on improving pencil, please report it as an issue, or better yet submit a pull request.


Read the original article

Comments

  • By pixelmonkey 2026-02-1613:212 reply

    I've used vim as a prose editor in addition to a code editor for a long time.

    For me, Goyo was the plugin that always matched what I wanted vim to become when I was in "prose writing mode."

    https://github.com/junegunn/goyo.vim

    I combine with limelight.vim:

    https://github.com/junegunn/limelight.vim

    This partially simulates the experience/UX of the product iA Writer on macOS or iPad, which is my favorite prose editor, but is proprietary software and doesn't work on Linux.

    As others mentioned, when in prose writing mode you can also flip on a handful of vim options, I save these as hotkeys in my vimrc. For example, spell checking and line wrapping.

    In case you're curious:

    https://github.com/amontalenti/home/blob/master/.vimrc

    • By amouat 2026-02-1614:48

      I played with some of these tools 12 years ago and created "dim", but it was really just Vim with limelight and goyo in a Docker container.

      https://github.com/amouat/dim

      There is something nice about having the editor as a separate command especially for writing.

    • By Agentlien 2026-02-1614:011 reply

      I just checked these out and Limelight feels wonderful when editing and reading prose in Vim! I will definitely be using this in the future - especially when writing things for my blog.

      • By pixelmonkey 2026-02-1614:27

        Glad I could be helpful! They are great plugins.

  • By fleshmonad 2026-02-1612:165 reply

    Vim is my only text editor, I use it for writing everything. Emails, scripts, messages, 100k+ lines codebases, prose, never needed this plugin. One line for 80 char wrap on certain filetypes, and a that is it, never needed such a plugin.

    For prose, you can simply hard wrap at 80 (arguably you should), and vim supports this via a single config line. OOTB vim soft breaks anyway and you can navigate between in those broken lines via gj, gk etc.

    Seems like bloat to me.

    • By criddell 2026-02-1614:321 reply

      I'm your opposite. I use Pages for letter writing, Word for documentation, PyCharm for Python, Visual Studio for C++, VSCode for Javascript, Outlook for email, vi for bash and config files, SublimeText for markdown and html, OneNote for todos and project planning, Obsidian for my work log and outlines, the Notes app for on-the-go capture, etc...

      • By KPGv2 2026-02-1615:005 reply

        This is the way.

        For a community that prides itself on "one small tool for a specific purpose," people sure like to use VIM for a thousand different purposes by hacking plugins. This used to be derided as the microsoft way decades ago.

        For writing prose, I use an app specifically designed for writing prose: Scrivener. See elsewhere saying "you should change how you write in order to use version control when writing prose." Totally forgetting that there's been a version control for prose for literal decades: tracking changes in a word processor.

        Do you want to process words? Use a word processor. Not a text editor. Writing prose isn't editing text.

        • By amdivia 2026-02-1615:25

          The thing is, in this context "editing text" is seen as the one job, that one tool should do.

          So when you're working with multiple applications, all of which are trying to force you to use their own way of editing text, it feels highly fragmented and un-unixy

          I do understand what you're saying, it's just that I wish the text editing portion of most of these tools is abstracted to a degree that allows for my text-editing tool of choice to be used within it

        • By JadeNB 2026-02-1616:11

          > For a community that prides itself on "one small tool for a specific purpose," people sure like to use VIM for a thousand different purposes by hacking plugins. This used to be derided as the microsoft way decades ago.

          I'm not sure that this is the meaning of the slogan. The slogan says that a programmer shouldn't try to make one tool to do all things, not, I think, that users shouldn't be given the freedom to adapt their favorite tool to do all the things that they want to do. (Imagine, for example, if one applied this understanding of the slogan to C, and regretted the thousand and thousand thousand different purposes to which users were putting it!)

        • By fleshmonad 2026-02-1615:45

          This doesn't have to be the way. I write documents using typst, with the occasional latex document sprinkled in by necessity. Not everybody needs a WYSIWYG editor. Most of them are WYGIWYG anyway. You're free to use whatever tools you like, but claiming that something is _the_ way would be absurd. And if you like little bloat, a system that just works across many domains, you don't need 100 different "apps" that each try to implement the features you get when chaining together the coreutils.

        • By bccdee 2026-02-1617:171 reply

          My issue is that word processors mostly amount to bad typesetting tools. Your editor doesn't need configurable document margins or page numbers. Semantic styling should be visible but unobtrusive, e.g. markdown.

          If I were a Mac user, I'd probably use iA Writer. Instead, I'm very happy with Sublime. I appreciate Scrivener's bells and whistles but I find I never need more than documents, folders, and headings (although I wouldn't say no to Obsidian-style wikilinks).

          • By KPGv2 2026-02-174:54

            Yeah, I do think different uses require different editors. I write novels, and Scrivener works better for me than iA writer. I used Sublime as a code editor a decade or so ago, but never for anything more.

        • By hearsathought 2026-02-1619:04

          > For a community that prides itself on "one small tool for a specific purpose,"

          You think this "community" is a tech community? Let alone a unix community? And using a text editor for text processing is definitely aligned with the "unix way" than your way.

          > This used to be derided as the microsoft way decades ago.

          No. Your way was derided as the microsoft way. The unix way was to treat everything as text! Programs/processes feed/pipe text to each other.

    • By 1vuio0pswjnm7 2026-02-1618:53

      Seems like bloat to me, too

      I prefer writing with a mechanical pencil

      For editing text on a screen, I prefer UNIX utilities ed, sed, ex/vi and custom filters written in C. The later can be used within ed or ex/vi via

         :!filter
      
      The slow, error-prone step is getting the text _accurately_ from the paper to bits in the computer. A personalised OCR that can recognise own handwriting might be helpful

    • By Roundish7334 2026-02-1612:33

      I agree - sometimes it is too easy to get lost when people create plugins for simple configuration options that are already built-in.

    • By CamT 2026-02-1612:49

      I feel similarly, but I could see folks who use vim as more of an IDE finding this useful.

    • By cryptonector 2026-02-1616:23

      Yes, this. Vim needs no plugins for writing prose.

  • By twobitshifter 2026-02-1614:27

    This is neat, but I think I would avoid it given the speed with which I can make edits in Vim.

    One thing I’ve learned about writing prose vs. code is that you should not be quick to edit your prose and instead continue writing and finish the complete draft. This is why studies show that typewriters and pen and paper give a better creative process. I can’t foresee me looking for things like autocomplete or pure speed when trying to put thoughts to paper.

HackerNews