| ▲ | Vim-pencil: Rethinking Vim as a tool for writing(github.com) |
| 93 points by gurjeet 4 days ago | 33 comments |
| |
|
| ▲ | pixelmonkey 3 hours ago | parent | next [-] |
| 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 |
| |
| ▲ | amouat 2 hours ago | parent | next [-] | | 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. | |
| ▲ | Agentlien 3 hours ago | parent | prev [-] | | 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. | | |
|
|
| ▲ | commandersaki 24 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | fleshmonad 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | criddell 2 hours ago | parent | next [-] | | 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... | | |
| ▲ | KPGv2 2 hours ago | parent [-] | | 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. | | |
| ▲ | amdivia an hour ago | parent | next [-] | | 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 | |
| ▲ | fleshmonad an hour ago | parent | prev | next [-] | | 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. | |
| ▲ | JadeNB 22 minutes ago | parent | prev [-] | | > 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!) |
|
| |
| ▲ | cryptonector 10 minutes ago | parent | prev | next [-] | | Yes, this. Vim needs no plugins for writing prose. | |
| ▲ | Roundish7334 4 hours ago | parent | prev | next [-] | | I agree - sometimes it is too easy to get lost when people create plugins for simple configuration options that are already built-in. | |
| ▲ | CamT 4 hours ago | parent | prev [-] | | I feel similarly, but I could see folks who use vim as more of an IDE finding this useful. |
|
|
| ▲ | schmeichel 4 hours ago | parent | prev | next [-] |
| 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! |
| |
| ▲ | bee_rider 4 hours ago | parent [-] | | 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… | | |
| ▲ | statusfailed 3 hours ago | parent [-] | | 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? | | |
| ▲ | setopt 2 hours ago | parent [-] | | 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. |
|
|
|
|
| ▲ | twobitshifter 2 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | dghf 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | velcrovan 2 hours ago | parent | next [-] | | https://scott.mn/2014/02/21/semantic_linewrapping/ | |
| ▲ | KPGv2 2 hours ago | parent | prev [-] | | > 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. | | |
| ▲ | velcrovan an hour ago | parent | next [-] | | Wow, you use Word, Google Docs and Scrivener to author the content on your website? Tell me more. | |
| ▲ | dghf an hour ago | parent | prev [-] | | 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. |
|
|
|
| ▲ | eviks 2 hours ago | parent | prev | next [-] |
| > 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! |
| |
| ▲ | KPGv2 an hour ago | parent [-] | | 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. |
|
|
| ▲ | xavortm 4 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | spankibalt 2 hours ago | parent | prev | next [-] |
| I'll keep using Symantec GrandView. For writing non-code, it outclasses anything mentioned so far by a considerable degree. |
|
| ▲ | Finnucane 3 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | twobitshifter 2 hours ago | parent | next [-] | | 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. | |
| ▲ | i_am_proteus 3 hours ago | parent | prev [-] | | 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. | | |
|