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.
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.
I saw this headline and excitedly clicked through expecting to find an attempt to make a modal drawing canvas made using lessons from and the ethos of vim.
It isn't that. It's a vim plugin for writers. Which is fine, just not what I hoped for.
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.
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...
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.
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
I'm not sure if vim-pencil addresses this, but I find writing in the online typst editor to be a delight, particularly its soft-wrap mode and its auto-indent.
Even though I have a very narrow editor when you type for example:
this is a very very long sentence
- this is a very incredibly long sentence too
And say it is too narrow for the viewport, it will soft wrap like so:
this is a very very
long sentence
- this is a very
incredibly long
sentence too
Even though the bulleted sentence is soft wrapped, it maintains the indent of the sentence which I find a really useful visual aid.
I love this. I use various text editors mostly used by devs (moving back and forth between emacs and sublime on mac and textastic on ipad) for serious longform writing all the time, usually using markdown +
pandoc, and it has a bunch of advantages and disadvantages.
IME the main advantages are (1) not having to fight with useless Microsoft word (and similar) behavior, bloat, bugs, etc. and (2) being able to mix in a spot of code as needed, for example compiling different sections together, doing a bit of text replacement and templating etc.
The main disadvantage is that the tooling isn't really there. I've done a stupid amount of yak shaving trying to get things like footnote folding in emacs, word count, etc., the spell checking is waaay behind, outline formats don't really work right (though they also don't really work right in word etc.)
So three cheers for anyone working on making the tooling problem better!!
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.
As someone who writes academic essays and prose, I can't live without this plugin. I will constantly need to write multiple page paragraphs, and it's incredibility more convient to be able to navigate within a paragraph as if it was multiple lines, as opposed to needing to perform some horizontal motion gymnastics to get the cursor where I need it to be.
Hat's off to everyone who has worked on this plugin!
Ahh I thought I was the only one! One line per sentence makes the diffs so much nicer too, maybe we need git hooks to reject multiple sentences per line?
I can't remember who suggested it, but I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
Of course, this assumes that you're writing in Markdown or ASCIIDoc or something else that will get processed into the final displayed form. But even with plain text, you could always run it through fmt or something similar.
Personally, I just change the diff engine to use difftastic, which can handle diff's on a syntactic level. Works great.
You could also just change git's diff settings to highlight word-based changes if you don't want to use external tools. I believe you can even use regex to redefine a word to match sentences.
> I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
What you're describing is called "track changes" in word processors.
I'd say an alternative to using Git or JJ or whatever is use a version control that exists to serve non-code. That is to say, use Track Changes! :D
Word, Google Docs, Scrivener (this is my favorite), etc. have no problem telling you "hey you changed this draft by inserting a paragraph and changing this other word's verb ending, while also replacing this one with a synonym."
Yeah, if you use Git, which was designed for tracking changes to a far more limited kind of language, you're going to run into incompatibilities. So track changes with a version control created for tracking changes to human language.
If you have to "rethink" your app in order to serve a new purpose, it's a red flag that you're trying to square a circle.
Better to use a tool that was created for your purpose.
I mean, whatever works for you. Go for it. It wasn't my intention to be prescriptive.
I don't like word processors. They're heavy and don't cleanly separate style from structure. And they use more or less obscure file formats.
I like text editors -- vim especially -- and plain text (or plain text with a thin layer of lightweight markup, like Markdown). And semantic linewrapping plus git is good enough for my purposes.
It may not be for yours, and that's OK. We are allowed to be different.
for writing - instead, it might've been more useful of a plugin if it was targeted at specific problem. Example - creative writing - if you had LSP-like feature on top that can link to characters, scenes, add scenes, find chapters, jump between content. Add character bio, traits and more and have easy "peak" as in a function signature to see details. I know it's different than what the plugin showcases, just sharing thoughts on what I find as a meaningful feature add. here, it's just as commented below, it's basically Vim.
> 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.
Writers are renown for ther love of coding domain specific languages!
They'd even trade such writing fundamentals like bold in nicely looking proportional fonts for that!
There's even a suggestion here advocating for changing how one writes prose in order to accommodate version control! But this is a solved problem from at least as early as the 1990s. Track changes! Don't use git to track versions of your novel.
Track changes, and label a specific part of your timeline as draft 1. Google Docs supports this. Scrivener (created specifically for writing novels) does this. Etc.
Why would I use git? It's designed for tracking changes to linted code.
> 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
Suggestion: use 72. It's divisible by 2, 3, 4, 6, 8, 9, 12, 18, 24, and 36, simplifying tables, columns, centering, etc.
Vim only works for writing if you are writing in a language that uses the latin alphabet. It's one of its bigger failings as a text editor and I have considered if it would be possible to remap everything so it uses only ctrl- and alt- key combinations for commands (those always send the equivalent ascii keycode), but in the end that sounds like a completely new editor.
Is there a way to do the equivalent of Word's 'track changes' feature in Vim/Neovim? As an editor who reviews manuscripts in Word, I want to be able to make edits, have the author review/approve them, then clean up the result into a file that goes to the typesetter. If I could do that, then a plugin like this becomes potentially more useful to our workflow.
A source control tool such as git or mercurial will solve this. Any collaborator who uses vi should have no issues with a git/hg workflow for managing changes.
> Creates undo points on common punctuation during Insert mode, including deletion via line <C-U> and word <C-W>
When I've used Vim, the undo points frustrated me: One undo covers a much larger set of events / longer time than in other writing applications. I think it 'undoes' until the last command.
Every other program does it more granually and, once I thought about it, amazingly intuitively - I've never had to think about it. Is there a general algorithm they all use?
> soft line wrap
Also, is there a way to make Vim's soft line wrap break lines at standard points, such as between words and at hyphens? Vim seems to break lines at the line character limit, regardless of where that is in the word or sentence.
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
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.
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.
Glad I could be helpful! They are great plugins.
I saw this headline and excitedly clicked through expecting to find an attempt to make a modal drawing canvas made using lessons from and the ethos of vim. It isn't that. It's a vim plugin for writers. Which is fine, just not what I hoped for.
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.
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...
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.
5 replies →
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
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
I agree - sometimes it is too easy to get lost when people create plugins for simple configuration options that are already built-in.
I feel similarly, but I could see folks who use vim as more of an IDE finding this useful.
Yes, this. Vim needs no plugins for writing prose.
I'm not sure if vim-pencil addresses this, but I find writing in the online typst editor to be a delight, particularly its soft-wrap mode and its auto-indent.
Even though I have a very narrow editor when you type for example:
And say it is too narrow for the viewport, it will soft wrap like so:
Even though the bulleted sentence is soft wrapped, it maintains the indent of the sentence which I find a really useful visual aid.
I love this. I use various text editors mostly used by devs (moving back and forth between emacs and sublime on mac and textastic on ipad) for serious longform writing all the time, usually using markdown + pandoc, and it has a bunch of advantages and disadvantages.
IME the main advantages are (1) not having to fight with useless Microsoft word (and similar) behavior, bloat, bugs, etc. and (2) being able to mix in a spot of code as needed, for example compiling different sections together, doing a bit of text replacement and templating etc.
The main disadvantage is that the tooling isn't really there. I've done a stupid amount of yak shaving trying to get things like footnote folding in emacs, word count, etc., the spell checking is waaay behind, outline formats don't really work right (though they also don't really work right in word etc.)
So three cheers for anyone working on making the tooling problem better!!
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.
As someone who writes academic essays and prose, I can't live without this plugin. I will constantly need to write multiple page paragraphs, and it's incredibility more convient to be able to navigate within a paragraph as if it was multiple lines, as opposed to needing to perform some horizontal motion gymnastics to get the cursor where I need it to be.
Hat's off to everyone who has worked on this plugin!
I usually do one line per sentence when writing papers. But a co-author will usually mess that up, so I could see some value to a plugin…
Ahh I thought I was the only one! One line per sentence makes the diffs so much nicer too, maybe we need git hooks to reject multiple sentences per line?
2 replies →
I can't remember who suggested it, but I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
Of course, this assumes that you're writing in Markdown or ASCIIDoc or something else that will get processed into the final displayed form. But even with plain text, you could always run it through fmt or something similar.
Personally, I just change the diff engine to use difftastic, which can handle diff's on a syntactic level. Works great.
You could also just change git's diff settings to highlight word-based changes if you don't want to use external tools. I believe you can even use regex to redefine a word to match sentences.
https://scott.mn/2014/02/21/semantic_linewrapping/
> I'm sold on the idea that if you're committing your drafts to version control, then you should break your lines at syntactic points: at the end of a short sentence, or at the ends of the component phrases of a longer sentence. This should typically lead to a cleaner and more readily comprehensible version history.
What you're describing is called "track changes" in word processors.
I'd say an alternative to using Git or JJ or whatever is use a version control that exists to serve non-code. That is to say, use Track Changes! :D
Word, Google Docs, Scrivener (this is my favorite), etc. have no problem telling you "hey you changed this draft by inserting a paragraph and changing this other word's verb ending, while also replacing this one with a synonym."
Yeah, if you use Git, which was designed for tracking changes to a far more limited kind of language, you're going to run into incompatibilities. So track changes with a version control created for tracking changes to human language.
If you have to "rethink" your app in order to serve a new purpose, it's a red flag that you're trying to square a circle.
Better to use a tool that was created for your purpose.
Wow, you use Word, Google Docs and Scrivener to author the content on your website? Tell me more.
I mean, whatever works for you. Go for it. It wasn't my intention to be prescriptive.
I don't like word processors. They're heavy and don't cleanly separate style from structure. And they use more or less obscure file formats.
I like text editors -- vim especially -- and plain text (or plain text with a thin layer of lightweight markup, like Markdown). And semantic linewrapping plus git is good enough for my purposes.
It may not be for yours, and that's OK. We are allowed to be different.
for writing - instead, it might've been more useful of a plugin if it was targeted at specific problem. Example - creative writing - if you had LSP-like feature on top that can link to characters, scenes, add scenes, find chapters, jump between content. Add character bio, traits and more and have easy "peak" as in a function signature to see details. I know it's different than what the plugin showcases, just sharing thoughts on what I find as a meaningful feature add. here, it's just as commented below, it's basically Vim.
> 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.
Writers are renown for ther love of coding domain specific languages!
They'd even trade such writing fundamentals like bold in nicely looking proportional fonts for that!
There's even a suggestion here advocating for changing how one writes prose in order to accommodate version control! But this is a solved problem from at least as early as the 1990s. Track changes! Don't use git to track versions of your novel.
Track changes, and label a specific part of your timeline as draft 1. Google Docs supports this. Scrivener (created specifically for writing novels) does this. Etc.
Why would I use git? It's designed for tracking changes to linted code.
I'll keep using Symantec GrandView. For writing non-code, it outclasses anything mentioned so far by a considerable degree.
> 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
Suggestion: use 72. It's divisible by 2, 3, 4, 6, 8, 9, 12, 18, 24, and 36, simplifying tables, columns, centering, etc.
Vim only works for writing if you are writing in a language that uses the latin alphabet. It's one of its bigger failings as a text editor and I have considered if it would be possible to remap everything so it uses only ctrl- and alt- key combinations for commands (those always send the equivalent ascii keycode), but in the end that sounds like a completely new editor.
Is there a way to do the equivalent of Word's 'track changes' feature in Vim/Neovim? As an editor who reviews manuscripts in Word, I want to be able to make edits, have the author review/approve them, then clean up the result into a file that goes to the typesetter. If I could do that, then a plugin like this becomes potentially more useful to our workflow.
Other commenters have mentioned entering one sentence per line as a good way to track revisions in git.
You could then use a git workflow to do your reviews and edits.
A source control tool such as git or mercurial will solve this. Any collaborator who uses vi should have no issues with a git/hg workflow for managing changes.
Version control is not editing.
3 replies →
> Creates undo points on common punctuation during Insert mode, including deletion via line <C-U> and word <C-W>
When I've used Vim, the undo points frustrated me: One undo covers a much larger set of events / longer time than in other writing applications. I think it 'undoes' until the last command.
Every other program does it more granually and, once I thought about it, amazingly intuitively - I've never had to think about it. Is there a general algorithm they all use?
> soft line wrap
Also, is there a way to make Vim's soft line wrap break lines at standard points, such as between words and at hyphens? Vim seems to break lines at the line character limit, regardless of where that is in the word or sentence.
solves no actual problem I have and not worth the security risk and extra complexity of a plugin by a random remote stranger