I am back to writing with Vim again. I have been flip-flopping among writing tools, and finally settled back on Vim. For those who are not familiar with Vim, it is a text editor that has been around forever. It is not for the feint of heart. It can be somewhat difficult to learn, especially if you are not used to a modal tool, or not a fan of keyboard commands.
So then why use it? I’ve given this quite a bit of thought over the last week or so that I’ve been back with it, and there are several reasons I think I will stick with it going forward.
1. Future compatibility
A few months ago, I began to try to collect all of my old writing. My intention was to build an archive of my writing from the time I first started, right through the present, and then keep it going forward. I wanted an easy way to see anything I’d ever written with the intent of paid publication. I started to write with the intent to sell stories in December 1992. Believe it or not, I still have those files 27 years later. I used Microsoft Word 5.5. for DOS back then, and these files are all in that format. The latest version of Microsoft Word can’t read them.
This is an example of a compatibility problem I want to avoid going forward. If my writing is going to be stored digitally, I want it to be in a format that is mostly immune to compatibility issues. Plain text is the answer. Vim is a text editor and allows me to write plain text files. I use Markdown in my plain text to get formatting I want in the output, but the files themselves are nothing more than simple text.
There are many advantages to this, a few of which I will touch on later.
2. Separating content from presentation
WYSIWYG just doesn’t work for me the way I envisioned it would when it first came out. I remember the first version of Microsoft Word that had a what-you-see-is-what-you-get interface. Even earlier, I remember AppleWorks, which also had a WYSIWYG interface. It was very cool to be able to layout the document on the screen to appear exactly as you want it on the page.
As I began to write, however, I quickly learned two things:
- I spent too much time playing around with formatting options, when I should have been writing.
- There are really only a small handful of standard formats that I use on a day-to-day basis.
Scrivener was the first writing tool I used that did a very good job of separating the content form the presentation of a document. In Scrivener, you write content and then compile it into one of many formats. You can move text around easily, and make the screen look however you want it to look, but the presentation–that is, the document that Scrivener compiles–can look completely different from what appears on the screen.
Vim allows me this separation as well. How things look on my screen is completely different from how the document they produce looks, but that is okay, because I still only use a few standard output formats (standard manuscript, letter, etc.). I use Pandoc to compile my Vim markdown into a Word document, or a PDF.
3. Look and feel
I’ve mentioned that my favorite word process of all time was Microsoft Word 5.5 for DOS. Maybe it’s because it was the first word processor I used when I started writing to sell stories, and its look and feel somehow imprinted on me at an impressionable age, but I like the look of white text on that blue screen.I have tried to mimic that look and feel in a variety of text editors and word processors over the years. When I came back to Vim a week ago, I took another focused crack at it–and managed to get as close as I possibly can. The text on the screen looks exactly as I want it to look:
- White text with a blue background.
- Show underlines instead of italics in markup–because underline is how you represent italics in a standard manuscript format, and it stands out better on the screen.
- Not too much else on the screen.
I realize that I can come close to this in other word processors. What I have not been able to do is get the look and feel that I want, while maintaining compatibility, and separating the content from the presentation layer–until now.
4. Change history
I like being able to see the evolution of what I write. Plain text makes it easy to see differences from one version to the next. I use flashbake, which is a tool that automatically checks in what I am working on to git’s revision control system every 15 minutes. Everything I write has an automated history of its construction. I tag certain check-ins, like “first draft”, “second draft”, “submitted draft”, “corrected draft”, “published draft”, etc. I can check out any of these and compare to any other.
I learn from these changes. It is interesting to be able to go back into time and look at things I took out, or left in. It also means nothing is ever wasted or deleted. If I write a scene that I really like, but doesn’t quite work in the story, I can remove it and yet the scene is still retained in git where I can always find it.
Here is a recent example of part of the git change log from a story that I have been working on.
5. One tool for all my writing
Over the years, I’ve found myself using different tools for different types of writing: one for paid writing, another (WordPress) for blogging, another still when writing correspondence. It means having to remember a variety of different key commands (which tend to vary from one tool to the next) as well as differences in the way they function.
I want one tool for all of my writing. I look back to writers in the first half of the twentieth century, doing the bulk of their writing on one typewriter, and using it until the poor machine wore down. Story drafts, letters, essays, everything goes through that one machine. It becomes an extension of the writer. In an effort to simplify, I’d like to be able to use just one tool for all of my writing. Of course, there is writing that I do that won’t get into Vim–mostly email–but there are always exception.
I can do this easily with Vim thanks to Pandoc, which can take my markdown file and convert it to any format I want, using template files. I have a letter template, a standard manuscript template, etc. From the plain text markup, I can produce with a single command, a properly formatted manuscript in Word format, or PDF format. I can do the same for letters, notes, critiques, etc.
6. Searching
With all my files as plain text, searching is much easier. Plus, tools like Vim make it easy to use regular expressions for searching, and I can easily search multiple files at once.
I’ve been using Vim for all of my writing for the last two weeks or so and I’ve gotten more and more comfortable with it. I’m trying hard to stick with Vim’s standard keyboard navigation (instead of the arrow keys) because I think it will make it easier to use with other computers over time. Plus, as I get more familiar with them, I find Vim’s navigation to be a power tool.
And yes, as you can see from the screenshot above, this post was written in Vim.
RSS - Posts
As with all good Swiss Army knives, there are more addons and extensions than you can shake a stick at with vim. For browsing interests, you might find some useful ideas over at http://www.naperwrimo.org/wiki/index.php?title=Vim_for_Writers
Viva la editor!
Yeah, I’m using a few. I particularly like Goyo for its clutter-free interface.
Hey, I’m a returning reader of your blog (been following you back in the Evernote days).
I also used to use Evernote, and then a few other apps until I found Org-mode and Emacs.
What I’m curious about (not sure how much you want to get into it or can in a comment), is why/how did you leave Evernote?
From this post I see what got you to write into Vim and I’d say 80% of what you say here is true for me an Emacs as well. If you’re curious, btw, there are a couple of examples using Emacs for writing, I’m sure some of it applies to vim as well.
Thanks for writing! 🙂
Josh, thanks for reading! I’ve never left Evernote. I never used Evernote for writing. I still use for the same things I’ve always used it for, and it has recently been very helpful as we get our house ready to sell so that we can buy a new one. I stopped writing the Going Paperless posts because I felt I was getting repetitive, and wanted to write about other things. That said, I’ve got a post in the works based on my recent experience using Evernote to manage this whole real estate process. Stay-tuned!
I used to be an Emacs user back in the mid-late-1990s. Did my share of elisp coding. I can’t remember why I ultimately gave it up.
I wrote an article years ago about how I use Markdown & an IDE to write, and a custom ruby app to compile it into PDF or ePUB. I had previously written my first novel in LaTeX and compiled with a simple make file, but it wasn’t very ePUB friendly.
While I liked the Ruby app, I wanted to move more towards CI/CD so that I didn’t have to keep going to the command line (of which I was once a native).
On 12 January 2019, I started full tilt on a Pandoc toolchain leveraging Docker and Circle CI (both being free at my level of usage). The link is below. I need to build out the documentation, and make the template more extensible. But basically, check the book into Github, and about 2 minutes later a compiled copy of what you’ve written is pushed as a release to the GH repository. Not apparent in the current version is that the Markdown files can be in subdirectories (as chapters or stories) and individual files. (I know the date because Git remembers. ;))
https://github.com/Merovex/pandoc-book
The repo has everything necessary to use the CI/CD feature, but without documentation of the setup may be a bit of a PITA to use at first. It has a DOCX version which is good for sending to editors. It doesn’t do MOBI because that conversion can happen at KDP.
As an author (not very active of late), I like one scene per file, and one directory per chapter…though I am moving away from chapters. It runs a straight sort, so Directory & Filenames should be in numerical order (01..99). I need to set this up so that it can compile multiple books at one time, since this is all feeding in to a novella series I am developing.
I’ve been working a side project where I’ve been applying Pandoc Book, and have made quite a few enhancements that I’ve not yet brought back to Pandoc Book. I was planning tonight to clean it up a bit more (family’s out-of-town). So, check it out and let me know if it is interesting. I’d like to make it useful for like-minded authors, so any suggestions, defects, enhancements suggested will be seriously considered.
I use Atom for my IDE, which has some nice plugins for Markdown, and a Git plugin that lets me do the code check-in and push from the IDE.
As for Vim, I’ve found myself dropping to my old favorite from time to time; when I have short things to write up or need to bulk edit. It’s like a familiar friend I’ve not seen in a while. The state-of-the-art with Vim has progressed considerably, so I might give it another look. But, I like the speed I get with Atom.
If you guys have recommended plugins for someone who’s not been on VIM since…2007…I would appreciate the advice.
I enjoyed reading about your use of VIM and especially about using MS Word for DOS. My first job out of University was support Word for DOS. It really was a great program. Thanks Jamie and take care!
Hi there Jamie
You may want to try using LibreOffice to open those old docs so you can reformat them for further preservation. It looks like LibreOffice may well open those docs:
Thanks, Paul. I was able to get at them with a text editor, and pull out what I needed from most of them, but it took a little work.
It looks like my Markdown image link didn’t work there. Here’s a screenshot of supported file types: https://cld.wthms.co/zjkjPF
only one problem…
VIM on the phone/mobile?
Not a problem for me for two reasons: (1) I don’t write or code on my mobile device, and (2) because I was curious, I did find a version of vim (iVim on the App Store) that works great on my iPhone and iPad. So if I did write on these devices, I’d have a tool.
I agree on the “faint of heart”-ness of Vim. I made the transition from Notepad to Vim in ’00 (VI, actually) when I started my first professional developer gig. My team lead handed me the nutshell book and told me she’d break my knuckles if she saw Notepad opened again.
The learning curve is reduced when you’re already a touch-typist, which I am.
I love Vim, though I only find myself using it every few weeks…usually when I have to edit a configuration file. It’s funny that even though I use Atom IDE for day-to-day writing…and could easily edit the config files that way, I drop into Vim for config files. I’m rusty as hell, but can still do 80% of the commands I used to by feel.
I’d be hard pressed to use Vim on a phone. The touch interface and key placement sort of trumps the value of Vim’s keyboard-friendly navigation. Nano or Pico might be better options…I can’t remember which one (or both) retains the edit/maneuver nature of Vim.
If you want to do Vim on a mobile device such as a smartphone or tablet it can be done providing you are online. All you really need is a ssh terminal app, a cloud hosted Linux instance and you can use ssh, blink, tmux, etc. Highly recommend a bluetooth keyboard or an iPad w/keyboard Air or Pro model. Using a cloud based Linux shell means you can connect and disconnect with tmux and pick up right where you left off, you can run multiple tmux sessions for different purposes or projects and have your workflow windows and panes organized for each project. There are ways to preserve these sessions between reboots of the server as well.
Also be sure to checkout the latest Neovim which has a built-in Lua JIT and you can use Lua based configuration files and Lua based plugins. The latest cutting edge Lua plugins are ridiculously fast. Many times faster than Vimscript plugins. Treesitter is a tree parser model and it can be used to color syntax highlight much faster. Support for advanced language autocompletion with built-in Lsp. A new Telescope plugin for advanced fuzzy find that is wicked fast. Yes you can do most of this in ViM but Neovim is seriously upping the bar lately. There’s also a lot of videos and tutorials to get all this working. Checkout Lunarvim’s GitHub repo and see the Neovim from scratch course. You can either use Lunarvim (opinionated sensible config) or build your own by going through the excellent Neovim from scratch tutorial. Lunarvim is worth trying, it keeps itself apart from your Vim / Neovim configs and you execute lvim instead of vim or vim to run it.