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.
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
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'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 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.
Maybe I just haven’t discovered the track changes feature in word processors enough, but I find it lacking: no explicit grouping of changes (the git commit), no clear timeline of changes, no tagging / naming of versions etc.
Not saying that a line-by-line diff is that much better. Neither is great imo.
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!!
> 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.
Readit News
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
https://github.com/amouat/dim
There is something nice about having the editor as a separate command especially for writing.
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.
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.
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 helpfulOne 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.
Hat's off to everyone who has worked on this plugin!
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.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.
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.
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 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.
Not saying that a line-by-line diff is that much better. Neither is great imo.
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!!
Suggestion: use 72. It's divisible by 2, 3, 4, 6, 8, 9, 12, 18, 24, and 36, simplifying tables, columns, centering, etc.