POSTS

Use Vim's Sessions to Defray Context-Switching Costs

Blog

Introduction

The Vim editor has a built-in function for preserving your editor state – which files you had open, which tabs they were in, etc. – called “Sessions.” In my experience, few Vim users, even experienced / advanced users, take advantage of this feature and that is a shame. Sessions allow you to get you back into the working context of a given problem immediately . If you’ve avoided a needed reboot for software update or wished you could save the context of your editing as related to a specific problem, you should take the time to learn a little bit about sessions.

Curating an Editor State

As developers, we generally start with a single file (“QA says there’s a bug in this view”) and then realize it has a relationship with another file (“Hm, but I need this as the data source / dependency / etc.”). Over time we come to recognize that there are several files whose relationship and interaction creates a “feature” we want to work on. I call this collection of files that represents the means to the solution the “curated list.” We groom our curated list into a user interface that helps us address the problem:

#

The curated list for this blog post

Finding yourself needing to reboot, where you would wipe away this solution context like some Tibetan sand mandala might put you into a panic routine:

“Which files do I have open? Which directories am I in, which server processes are running?”

The Oatmeal comic hits home:

#

To save your state all you need to do is run :mksession. By default this will create a file called Session.vim in your working directory. Its contents are a full list of Vimscript commands that will be issued when you launch Vim with a reference to that file with vim -S session_file_name at a later date. Reading this file is also a great way to learn some powerful Vimscript commands.

#

The commands it requires to re-build your Vim session as it is right now

Standard Vim file-write semantics still apply To overwrite the old session it’s :mksession! and :mksession session-from-after-lunch.vim It is this latter usage which allows you to create ’topic based sessions.'

Topic-Based Vim Sessions

The average Vim session is very small (kilobytes) and they can be made cheaply (less than a second) therefore, as I work on problems I’ve taken to creating multiple Vim sessions so that I can address a feature and come back to it painlessly.

Presently I’m experimenting on creating sessions based on bug-tracker stories. The session files (ending in .vim) are included in my global .gitignore file. Given that a certain feature may be revisited at any point, it seems a good idea to keep each in its own session so that I can pick it back up again for subsequent bugs / improvements. AND should a refactor add a new file or drop one, all that’s required is a simple mkession! to write a new session.

Gotchas

By default mksession saves blank, buffers, curdir, folds, help, options, tabpages, winsize. Depending on how heavily customized your Vim configuration is, you may find these session commands clashing with your default options. For a heavily customized Vim installation (like Janus Vim) this can create some erratic results. To prevent any clashes, I have modified the default sessionoptions configuration in my .vimrc to be the following:

" Sessions in Janus are overwrought
set sessionoptions=blank,buffers,curdir,folds,help,tabpages,winsize

Reference

As sessionoptions seems to suggest, there are a wide variety of things that can be preserved. :help sessionoptions and :help mksession in the on-line Vim help guide should help you tweak your configuration to perfection.

I can even seen an argument for adding a :mksession! as an autocommand, so that your session is written on every file-write or buffer-change event. I don’t (yet) see a need for that, but it’s great to know that Vim has that capability.

Conclusion