I’ve been using Vimwiki for 5 years, on and off. There’s a multi year gap in between, some entries are back to back for months on end, while some notes are quarters apart.

Over those 5 years I’ve tried a few different lightweight personal wiki solutions, but kept coming back to Vimwiki due to my excessive familiarity with Vim and the simplicity of the underlying format (plain text FTW).

I used to store my Vimwiki in Dropbox, but after Dropbox imposed a three device free tier limit, I migrated to Google Drive for all my storage needs (and haven’t looked back!). I’m able to view my notes on any platform (including previewing the HTML pages on mobile).

I love seeing how other people organize their Wiki homepage, so it’s only fair to share mine:

I use Vimwiki as a combination of a knowledge repository and a daily project/work journal (<Leader>wi). I love being able to interlink pages, and I find it extremely helpful to write entries journal-style, without having to think of a particular topic or a page to place my notes in.

Whenever I have a specific topic in mind, I create a page for it, or contribute to an existing page. If I don’t - I create a diary entry (<Leader>w<Leader>w), and move any developed topics into their own pages.

I use folders (I keep wanting to call them namespaces) for disconnected topics which I don’t usually connect with the rest of the wiki: like video games, financial research, and so on. I’m not sure I’m getting enough value out of namespaces though, and I might revisit using those in the future: too many files in a single directory is not a problem since I don’t interract with the files directly.

Most importantly, every once in a while I go back and revisit the organizational structure of the wiki: move pages into folders where needed (:VimwikiRenameLink makes this much less painful), add missing links for recently added but commonly mentioned topics (:VimwikiSearch helps here), and generally tidy up.

I use images liberally ({{local:images/nyan.gif|Nyan.}}), and I occasionally access the HTML version of the wiki (generated by running :VimwikiAll2HTML).

I’ve found useful to keep a running todo list with a set of things I need to accomplish for work or my projects, and I move those into corresponding diary pages once the tasks are ticked off.

At the end of each week I try to have a mini-retrospective to validate if my week was productive, and if there’s anything I can do to improve upon what I’m doing.

I also really like creating in-depth documentation on topics when researching something: the act of writing down and organizing information it helps me understand it better (that’s why, for instance, I have a beefy “financial/” folder, with a ton of research into somewhat dry, but important topics - portfolio rebalancing, health and auto insurance, home ownership, and so on).

Incoherent rambling aside, I’m hoping this post will spark some ideas about how to set up and use your own personal wiki.

Recently Dropbox hit me with the following announcement:

Basic users have a three device limit as of March 2019.

Being the “basic” user, and relying on Dropbox across multiple machines, I got unreasonably upset (“How dare you deny me free access to your service?!”) and started looking for a replacement.

I already store quite a lot of things in Google Drive, so it seemed like a no brainer: I migrated all my machines to Google Drive overnight. There was but only one problem: Google Drive has official clients for Windows and Mac, but there’s nothing when it comes to Linux.

I found the Internets to be surprisingly sparse on the subject, and I had to try multiple solutions and spent more time than I’d like researching options.

The best solution for me turned out to be rclone, which mounts Google Drive as a directory. It requires rclone service to be constantly running in order to access the data, which is a plus for me - I’ve accidentally killed Dropbox daemon in the past and had to deal with conflicts in my files.

Install rclone (instructions):

curl https://rclone.org/install.sh | sudo bash

From then on, rclone website some documentation when it comes to the setup. I found it somewhat difficult to parse, so here it is paraphrased:

Launch rclone config and follow the prompts:

• n) New remote
• name> remote
• Type of storage to configure: Google Drive
• Leave client_id> and client_secret> blank
• Scope: 1 \ Full access to all files
• Leave root_folder_id> and service_account_file> blank
• Use auto config? y
• Configure this as a team drive? n
• Is this OK? y

From here on, you can interact with your Google Drive by running rclone commands (e.g. rclone ls remote: to list top level files). But I am more interested in a continuous running service and mount is what I need:

rclone mount remote: $HOME/Drive

Now my Google Drive is accessible at ~/Drive. All that’s left is to make sure the directory is mounted on startup.

For Ubuntu/Debian, I added the following line to /etc/rc.local (before exit 0, and you need sudo access to edit the file):

rclone mount remote: $HOME/Drive

For my i3 setup, all I needed was to add the following to ~/.config/i3/config:

exec rclone mount remote: $HOME/Drive

It’s been working without an issue for a couple of weeks now - and my migration from Dropbox turned out to be somewhat painless and quick.

Vim comes with a set of often outdated and counter-intuitive defaults. Vim has been around for around 30 years, and it only makes sense that many defaults did not age well.

Neovim addresses this issue by being shipped with many default options tweaked for modern editing experience. If you can’t or don’t want to use Neovim - I highly recommend setting some these defaults in your .vimrc:

if !has('nvim')
  set nocompatible
  syntax on

  set autoindent
  set autoread
  set backspace=indent,eol,start
  set belloff=all
  set complete-=i
  set display=lastline
  set formatoptions=tcqj
  set history=10000
  set incsearch
  set laststatus=2
  set ruler
  set sessionoptions-=options
  set showcmd
  set sidescroll=1
  set smarttab
  set ttimeoutlen=50
  set ttyfast
  set viminfo+=!
  set wildmenu
endif

The defaults above enable some of the nicer editor features, like autoindent (respecting existing indentation), incsearch (search as you type), or wildmenu (enhanced command-line completion). The defaults also smooth out some historical artifacts, like unintuitive backspace behavior. Keep in mind, this breaks compatibility with some older Vim versions (but it’s unlikely to be a problem for most if not all users).

If you’re using a custom color scheme (why wouldn’t you?) in conjunction with a terminal mode in Vim (again, why wouldn’t you?), you may have noticed that the terminal status bar has no respect for your color scheme.

Run :term, and you’ll be greeted to the default status bar:

Since terminal mode is still in beta in Vim 8.1, we have to manually set the highlighting groups. It’ll require a bit of digging.

Navigate to the directory containing your current color scheme. Depending on the plugin manager, the color schemes are located in different places. On Linux, default color schemes often live in /usr/share/vim/vimcurrent/colors. In this example, I’m using PaperColor scheme, and I have it installed using vim-plug in ~/.vim/plugged/papercolor-theme, and colors/PaperColor.vim is the file we’re looking for.

Search for StatusLine and StatusLineNC (tip: you can do a whole word search in Vim by running /\<StatusLine\>), and note the values used (you might have to jump through a few variables if the color scheme author decided to be fancy). You’re interested in ctermbg, ctermfg, guibg, and guifg.

You might find something like this:

hi StatusLine ctermbg=24 ctermfg=254 guibg=#004f87 guifg=#e4e4e4
hi StatusLineNC ctermbg=252 ctermfg=238 guibg=#d0d0d0 guifg=#444444

Copy those lines to your ~/.vimrc. Change StatusLine to StatusLineTerm, and change StatusLineNC to StatusLineTermNC:

" Manually set the status line color.
hi StatusLineTerm ctermbg=24 ctermfg=254 guibg=#004f87 guifg=#e4e4e4
hi StatusLineTermNC ctermbg=252 ctermfg=238 guibg=#d0d0d0 guifg=#444444

Reload ~/.vimrc (:w | so %), and the terminal mode status line should have the same colors as your color scheme:

Above, hi is a shorthand for highlight, which is used to define highlight group colors. StatusLineTerm and StatusLineTermNC define the highlight groups for terminal mode status line (in active and inactive windows respectively). Options ctermbg and guibg define the background color, and ctermfg and guifg are responsible for the foreground (text) color.

Over the past six to nine months I’ve been working on a book - Mastering Vim. Mastering Vim is a passion project which is meant to take the reader (you) from zero to a hero (future you): from knowing nothing about Vim, to becoming a power user. I cover many of Vim’s mysterious commands, philosophy behind the beloved editor, configuration tips, a plethora of community created plugins, as well as creating your own plugins.

Mastering Vim was written with support from Packt Publishing and was kindly reviewed by Bram Moolenaar (website) - the creator of Vim. Many people made this book possible, including VimConf Japan crew, who kindly hosted me earlier this year. Thank you to everyone for making Mastering Vim happen!

Give it a read and let me know what you think, Mastering Vim is available on Amazon!

P.S: This post, like many others, is written in Vim.