Recently, I wrote about a few . The benefits I discussed there are independent of one’s choice of text editor. But if you’re a vim user, the benefits of tmux reach even further. One of my favorite aspects of tmux is that it unlocks the potential for a more powerful vim-based development environment, allowing vim and the shell to feel more like a single cohesive tool. benefits of using tmux In this post we’ll look at a few ways of customizing tmux and vim to help get more done with less typing and context switching. Configuring tmux and vim to get the exact behavior you want is often a time consuming endeavor, but in my view it’s worth it. Over the last few years of using tmux and vim together, I’ve found a few tips and plugins that have really stood out. This post is a collection of those essential tips that have become indispensable parts of my development workflow. If you’re just getting started with tmux and vim, see the related reading section for links to some resources to get you up to speed. Moving around vim and tmux Seamless navigation As a general goal, I want to be able to use vim-style movements and text editing patterns whether I’m in vim or some other tmux pane. In vim, we use to divide up the current view, allowing us to edit several files side by side, or even to edit multiple regions of a single file without having to scroll around. Similarly, tmux’s allow us to divide up our window so we can run and view several terminal based commands and programs at the same time. splits panes I’m constantly using vim splits, so being able to move between splits efficiently is crucial. By default, if you want to move from one split to another, vim requires that you hit and then one of the directional keys (i.e. h, j, k, l).This isn’t as efficient as it could be, especially for such a common operation. ctrl-W To address this, like many vim users, I edited my to simplify split navigation, so that I can jump between vim splits using , , etc. This is already a great efficiency win. With tmux in the picture, we can use to not only set up these vim key bindings, but also to set up similar key bindings for tmux pane navigation. This allows us to use to move anywhere in our tmux window, whether we’re jumping between vim splits or tmux panes. .vimrc ctrl-j ctrl-k vim-tmux-navigator ctrl-<direction> Customizing tmux navigation behavior You may find yourself wanting to customize these navigation key bindings in programs other than vim. For example, recently I’ve been using the command line fuzzy finder quite a lot. Out of the box, fzf supports and for moving up and down its list of search matches. Unfortunately, this won’t work if you’re using vim-tmux-navigator’s key bindings in your , which are as follows: fzf ctrl-k ctrl-j suggested .tmux.conf is_vim="ps -o state= -o comm= -t '#{pane_tty}' \
                        | grep -iqE '^[^TXZ ]+ +(\S+\/)?g?(view|n?vim?x?)(diff)?$'"

bind-key -n C-h  if-shell  "$is_vim"  "send-keys C-h"  "select-pane -L"
bind-key -n C-j   if-shell  "$is_vim"  "send-keys C-j"   "select-pane -D"
bind-key -n C-k  if-shell  "$is_vim"  "send-keys C-k"  "select-pane -U"
bind-key -n C-l   if-shell  "$is_vim"  "send-keys C-l"   "select-pane -R"
bind-key -n C-\   if-shell  "$is_vim"  "send-keys C-\"  "select-pane -l" This bit of configuration works by adding conditional logic to the key bindings. When one of these movement commands is used, it checks if the current tmux pane is running vim. If so, the appropriate vim split navigation command is sent. Otherwise, the appropriate tmux pane navigation command is sent. ctrl-<direction> Using a slightly different approach, we can add logic so that tmux will treat fzf like it treats vim, sending fzf its own internal navigation commands rather than tmux’s pane navigation commands.‍ is_vim="ps -o state= -o comm= -t '#{pane_tty}' \
| grep -iqE '^[^TXZ ]+ +(\S+\/)?g?(view|n?vim?x?)(diff)?$'"

is_fzf="ps -o state= -o comm= -t '#{pane_tty}' \
 | grep -iqE '^[^TXZ ]+ +(\S+\/)?fzf$'"

bind -n C-h run "($is_vim && tmux send-keys C-h) || \
                             tmux select-pane -L"

bind -n C-j run "($is_vim && tmux send-keys C-j)  || \
                               ($is_fzf && tmux send-keys C-j) ||\
                                tmux select-pane -D"

bind -n C-k run "($is_vim && tmux send-keys C-k) || \
                       ($is_fzf && tmux send-keys C-k)  || \
                         tmux select-pane -U"

bind -n C-l run  "($is_vim && tmux send-keys C-l) || \
                       tmux select-pane -R"

bind-key -n C-\if-shell "$is_vim" "send-keys C-\" "select-pane -l" Using this general pattern in your , you can further customize vim-tmux-navigator’s behavior to work nicely with any command line utilities that use vim-style navigation. .tmux.conf The following demonstrates how you can move around vim splits, tmux panes, and fzf results all using . ctrl-<direction> It’s worth noting that you don’t need to do this just to use vim-tmux-navigator and fzf together. In addition to and , fzf supports and for navigating search results. It even has a option for setting custom fzf key bindings. But, if you specifically want to maximize the versatility of the , , etc. bindings across several applications running in tmux, this pattern will help. ctrl-j ctrl-k ctrl-n ctrl-p --bind ctrl-j ctrl-k A more vim-like shell Tmux and bash both have support for vi modes, which can help make your shell feel more like your editor. This is great because it means that when you move from a vim pane to a shell pane, you don’t have to do as big of a context switch. Many of the same patterns for moving around and working with text can still apply. You can use tmux’s to make tmux’s copy mode feel more like vim. In this mode you can use familiar vim commands to scroll, search, select, and copy text. vi mode Similarly, you can try bash’s . Being able to use vi style movements and character matching commands to quickly edit shell commands is really nice. Suddenly writing shell commands in bash and lines of code in vim begin to feel a lot more similar. Also, if you find yourself editing a complex shell command and you want to jump into vim for real, just enter normal mode and hit . This will drop you into vim, where you can finish editing your command, writing this file will bring you back to the shell and execute the command. vi editing-mode v It’s common practice for vim users to remap custom keys to escape, so we can so far every time we change from insert to normal mode. For example, I’m using the sequence to bring me out of insert mode. In order for bash’s vi mode to feel comfortable, it’s important to be able to use your familiar mapping to go from insert to normal mode on the command line. avoid reaching kj This can be configured in your file. In my case, to make work,I’ve added the following: ~/.inputrc kj set editing-mode vi ‍

  # vi settings
$if mode=vi
    set keymap vi-insert
    "kj" # remap escape
$endif Simplify vim split and tmux pane creation Splits and panes are both foundational concepts and should be really easy to use. We’ve already covered standardizing the way we move between splits and panes, but what about creating them in the first place? I’m not a big fan of tmux’s defaults for a working with panes for a few reasons. First, if you’re already familiar with vim split terminology, the words horizontal and vertical will mean the opposite of what you’d expect when it comes to tmux panes. And second, the default commands ( and ) for creating tmux splits never seemed intuitive to me. <Prefix>% <Prefix>" I’m using on the following in my : .tmux.conf bind | split-window -h -c "#{pane_current_path}"
bind - split-window -v -c "#{pane_current_path}" The beauty of this is that it allows you to continue thinking about splits and panes in terms of the orientation of the divider, the same way you’d think about a vim split. With these bindings, adds a vertical pane divider (like a vertical split in vim), and adds a horizontal one. If I remember correctly, I first saw these bindings recommended in the book Tmux: , which is full of great tmux tips and really worth a read. <Prefix>| <Prefix>- Productive Mouse-FreeDevelopment In vim, I primarily use vertical splits. So I’ve set the following in my which means that from normal mode, creating a new vertical split is as simple as hitting . .vimrc vv " vv to generate new vertical split 
  nnore map <silent> vv <C-w>v Splits and panes are excellent features, so the most important thing is to find key bindings that make them quick and intuitive for you to use. Quickly run shell commands without leaving vim Using what we’ve already covered, we now have the ability to quickly create tmux panes and move between them, running commands where we wish. Easy as this is, it’s sometimes preferable to create a pane and run a command in it without leaving vim at all. I use and its associated plugins to run terminal commands from inside vim. vimux Vimux essential commands One of the basic features of vimux is its ability to run an arbitrary shell command from within vim. Once vimux is installed, you can access the command prompt from within vim by running . You can then immediately start typing your shell command. Pressing enter will run the command in a tmux pane in the current window. If necessary, vimux will create a new pane for the command to run in. :VimuxPromptCommand Typing every time you want to run a command isn’t the best, so it’s recommended to add a mapping to your like the following: :VimuxPromptCommand .vimrc " Prompt for a command to run
map <Leader>vp :VimuxPromptCommand<CR> Now, from normal mode you’ll be able to type to bring up the prompt and issue commands, as shown here. <Leader>vp That’s already useful, especially for running tests, builds, or data processing scripts. In many cases, especially for tests, you’ll find yourself wanting to run a shell command, make some code changes, and then run the shell command again. " Run last command executed by VimuxRunCommand
map <Leader>vl :VimuxRunLastCommand<CR> Now, from normal mode will rerun the most recent vimux command. This really shines when it comes to running tests. <Leader>vl On running tests with vimux Vimux is especially helpful when you have a failing test that you are trying to fix. The workflow looks like this: Locate the failing test, read it, and run it Make changes to the application code to get the test passing Rerun the last test (i.e. that last vimux command) using <Leader>vl Repeat steps 2 and 3 until the test passes Using this workflow, it’s possible to more efficiently get a failing test passing, all without ever leaving vim. Quickly rerunning the last test command is especially helpful. When possible, consider using a vimux . These provide support for running the currently focused test in a test file, running all the tests in the current file, etc. platform-specific-plugin Quickly copying vimux output Let’s say you want to scroll through or copy a bit of output from the vimux pane. You could use to move from vim to the vimux pane, then you’d enter tmux’s copy mode using . That’s a bit involved. Fortunately, vimux offers a shortcut for this workflow. ctrl-<direction> <prefix> Add the following to your : .vimrc " Inspect runner pane 
map <Leader>vi :VimuxInspectRunner<CR> Now is all you need to jump from vim into the vimux pane, already in copy mode. From here, you can use as mentioned earlier, to move around, select text, and copy it to the clipboard. <Leader>vi vi style movements Getting a better look at vimux output Sometimes, especially when looking at test output on a laptop screen, it can be a little cumbersome to read long lines in a small pane. There are all sorts of ways you can efficiently resize your panes with tmux, but in this case, I’ve found vimux’s zoom feature to be a big help. If you haven’t used zoom before, it’s a tmux feature that maximizes the active pane to fill the space of the entire tmux window. When you’re done zooming, you’ll return to the previous pane arrangement you had before. More info on tmux zoom can be found . I’ve mapped vz to the vimux command which will zoom in on the tmux runner pane. here " Zoom the tmux runner pane 
<leader>vz :VimuxZoomRunner<CR> Now, you can run your tests with one vimux command, and if you need to, zoom in on the results with . Typically, at this point in order to leave the zoomed mode, you’d have to use tmux’s , and that’ll work just fine. But, if you’re using vim-tmux-navigator as mentioned above, you can also use the commands to exit the zoom mode as well. <Leader>vz <Prefix>z ctrl-<direction> Going faster with chords I use vimux commands a lot. So much so, that using leader-prefixed commands like I’ve described above (e.g., ) began to feel inefficient. ~3 keystrokes is too much for an action that has become so central to my vim workflow. <Leader>vl In practice, I’ve set up for common use cases like running a single test, running all the tests in a file rerunning the last command etc. If you haven’t given chords a try, I’d highly recommend it. Anytime the leader key starts feeling more like a speed bump than a shortcut, I start asking whether I should use a chord. Vim chords can be mapped to whatever functionality you like, but personally I use them almost exclusively for vimux bindings. vim chords Here’s a basic example, showing a simple workflow for fixing a failing test. This combines several of the elements discussed so far: The test is originally run using a chord mapped to test method. The chord is effectively a single keystroke. vimux-ruby’s RunRubyFocusedTest The vim split navigation is done using ctrl-l Subsequent test runs are done using another chord that reruns the last vimux command. Final thoughts Over the last few years, tmux and vim together with these customizations and practices, have formed the basis of a really enjoyable development environment for me. This post covers just a few of the many possible ways to configure tmux and vim to get even more out of both. The underlying principle here is about seeking efficiency, specifically: when practical, we should reduce the keystrokes and the cognitive load required to do common bits of work. Whether you use vim and tmux or not, it’s worth considering the intent behind these tips as it applies to your own development tools. I hope you find the process as fun as I have. Many thanks to Bram Moolenaar, Chris Toomey, Ben Mills, and Junegunn Choi for their thoughtful comments on earlier versions of this post and more importantly for their invaluable open source contributions.

bugsnag

What is The Ariane 5 Disaster? The Worst Computer Bugs in History Series

jQuery is Not Defined: How to Fix This Common Error

Visit Us

Too Long; Didn't Read

Make resilience your competitive advantage

Taking a Deeper Dive into Tmux and Vim

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How NetEngine Tracks Critical Bugs Using BugSnag

51 Stories To Learn About Bugs

A Little Dropbox, Bugsnag, and a Lot of Visibility During Error Investigation

A Quick Guide on Best Practices for JavaScript Error Monitoring

"Alerts need to be useful"

How NetEngine Tracks Critical Bugs Using BugSnag

51 Stories To Learn About Bugs

A Little Dropbox, Bugsnag, and a Lot of Visibility During Error Investigation

A Quick Guide on Best Practices for JavaScript Error Monitoring

"Alerts need to be useful"

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps