hckrnws

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.

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.

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

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.

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).

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.

> 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.

> 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!)

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

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.

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.

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

    this is a very very
    long sentence
      - this is a very
        incredibly long
        sentence too

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?

You can just do `git diff --word-diff` and then the diffs look great even with one paragraph per line.

I used to do one sentence per line, but after getting used to how Emacs handles soft-wrapping, I now do one paragraph per line—also when I use Vim. This also makes collaboration with other authors easier, since most non-vim collaborators do that.

Also IMO, sentences are a more useful logical grouping. I might want to swap sentence orders, so having the quick dd then p command is nice. Paragraphs get moved occasionally but it is rare enough that I don’t mind grabbing them as if they are a collection of sentences.

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.

https://scott.mn/2014/02/21/semantic_linewrapping/

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.

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 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.

Wow, you use Word, Google Docs and Scrivener to author the content on your website? Tell me more.

The comment you're responding to is obnoxious, but authoring in Google Docs and exporting to HTML+CSS would be viable and is 10x more accessible than the simultaneously over- and underengineered toolchains and work practices that the professional web developer class has turned out, and doesn't produce output substantially worse than the now-widespread practice of sending mangled/minified payloads to UAs, which in the worst cases involves turning content into opaque blobs that you have to squirt through a JS runtime to get anything meaningful on screen.

The state of the art in Web publishing is such a mess that paid practitioners have, seemingly without realizing it, quietly eliminated the main reason why anyone should even have an expert handle the "lowering" from concept to HTML+CSS instead of using a quasi-WYSIWYG tool or some other crummy sitebuilder and working with whatever shoddy markup they give you.

berkshirehathaway.com (<https://berkshirehathaway.com/>) makes the rounds every now and then, and people ooh and aah over it in the comments, but you can tell they never really get it because then they just turn around and dump their next Vercel-hosted monstrosity on the world.

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!!

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.

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.

> 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.

It already is.

> 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.

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.

The workflow the original post is describing is basically a merge request.

As someone who uses Git for technical writing and Word's revision system for fiction that goes back and forth with an editor, I mean, sure, it's sort of a merge request, but you need to place a higher value on the "goes back and forth with an editor" part of the requirement than I think you are. :) An editor suggests changes, sometimes by editing directly and sometimes by leaving comments, that the author can accept, delete, or modify, right? If we're talking about technical writing that's already in a Git repo, then using a PR review system like GitHub's is an acceptable substitute. If we're talking about somebody sending a story to the New Yorker, we're not.

I'm definitely not saying established organizations should change their workflows to "just use git" or something—word processors already offer these features, and the workflow at the New Yorker is already tailored around the affordances of Word documents.

The underlying data model, though—passing around diffs and comments, tweaking sets of modifications before applying them—is the same. You could put together a decent editing workflow around git (although maybe the UI would need to be different from what we use for code). Version control is editing, is my point.

What, and do seperate commits and merges for every comma and dangling modifier? That makes no sense. In addition, there needs to be comments and queries.

Well, no, no more than you would package each comma or dangling modifier into a separate change-tracked .docx. The underlying unit of revision here is a full change set, rather than an individual change.

Line wrapping is one of those things I’ve just decided to give up on and let myself be at the mercy of the machine. I just resize the window to be a comfortable width for reading text while I’m typing it and turn on soft wrapping. If you really need hard wrapping your editor or viewer should handle that formatting for you

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.

solves no actual problem I have and not worth the security risk and extra complexity of a plugin by a random remote stranger

Luckily the plugin is<200 LoC