Protesilaos Stavrou
Philosopher. Polymath.

Notes about my Tmux and Vim

Prot's Dots For Debian - Book index

If bspwm is the brains of my custom desktop session, then tmux and vim must be its heart and liver, or something along those lines… Well, metaphors are not my strong point, otherwise I would be regaling you with literature, not this boring manual: the idea is that both Tmux and Vim are essential to my workflow. It is thus pertinent to inform you about their respective configuration files so that you know what to expect.

About my tmux setup

Let’s start with the terminal multiplexer (I also have a video demo about TMUX and BSPWM). It is the first thing you will interact with when you log into the session and type super + return:

~/cpdfd $ tree -aF tmux
└── .tmux.conf

0 directories, 1 file

Only its config is distributed with my dotfiles, which is another way of saying that I do not use any plugins whatsoever. What is provided by the program itself is more than enough.

To send commands to tmux you must first press its prefix key, which I have kept to the default of Ctrl + b as it is the one that causes no issues with other programs’ main functionality, in the way I use them. Then, while releasing the prefix key, you can either access the command prompt by pressing the colon : or type one of the many keys that are assigned to direct actions. In the configuration file, modifier keys are shortened. So Ctrl + b is written as C-b, Alt is A, Shift is S (just to be sure: S- inserts the majuscule, so when you see a capital letter, add it that way). We use this notation from now on.

Here are the main key bindings to get you started:

# Those that involve C-b (prefix)
# -------------------------------
<prefix> s        # split current pane horizontally
<prefix> v        # split current pane vertically
                  ### these are the same as Vim's C-w {s,v}
<prefix> S        # split the whole window horizontally
<prefix> V        # split the whole window vertically
<prefix> x        # kill current pane
<prefix> C-x      # kill all panes except the current one
<prefix> r        # reload the tmux conf
<prefix> m        # mark active pane
<prefix> C-m      # toggle maximise active pane
                  ### the default is <prefix> z (too close to x)
<prefix> A-{1-5}  # switch to one of the five layout presets
<prefix> E        # evenly spread out active and adjacent panes
<prefix> c        # create a new window (windows contain panes)
<prefix> !        # break pane from current window
<prefix> J        # the opposite of break-pane
<prefix> Tab      # swap active pane with the previous one
<prefix> C-Tab    # swap active pane with the marked one

# Keys without the prefix
# -----------------------
A-{h,j,k,l}       # navigate panes in the given direction
A-S-{h,l}         # move to left/right window

Read .tmux.conf for the entirety of my settings and custom key bindings. That file is heavily documented, as is the norm with practically every item in my dotfiles.

Now if you are thinking that you do not need a terminal multiplexer and have no time to learn how to use one, I urge you to think again. This is a great skill to master. It is what makes a terminal power user truly competent. The skill is highly portable. It will come in handy in a variety of situations whereas, say, learning bspwm may not be particularly useful outside the narrow confines of a custom desktop session.

About my Vim setup

That last piece of advice holds true for vim as well. Spend some time learning its basics. Over time you will become proficient at editing text.

And here is another piece of advice, before we delve into the specifics of my Vim setup: set a very high bar for the use of plugins or, as in my case, do not use plugins at all. The more comfortable you are with the generic program, the higher the portability of your knowledge.

Now on to my customisations.

~/cpdfd $ tree -aF vim
├── .vim/
│   ├── colors/
│   │   ├── tempus_autumn.vim
│   │   ├── tempus_classic.vim
│   │   ├── tempus_dawn.vim
│   │   ├── tempus_day.vim
│   │   ├── tempus_dusk.vim
│   │   ├── tempus_fugit.vim
│   │   ├── tempus_future.vim
│   │   ├── tempus_night.vim
│   │   ├── tempus_past.vim
│   │   ├── tempus_rift.vim
│   │   ├── tempus_spring.vim
│   │   ├── tempus_summer.vim
│   │   ├── tempus_tempest.vim
│   │   ├── tempus_totus.vim
│   │   ├── tempus_warp.vim
│   │   └── tempus_winter.vim
│   └── spell/
│       ├── el.utf-8.spl
│       ├── el.utf-8.sug
│       ├── en.utf-8.add
│       └── en.utf-8.add.spl
└── .vimrc

3 directories, 19 files

A quick rundown of my .vimrc:

  • I stick to the default key bindings.
  • I expect Vim to ask for confirmation when closing a modified buffer.
  • I use tabs instead of spaces for indentation, setting the width of the tab character to be equal to four spaces. I used to use spaces when I first started using a text editor, because that was the default. However experience suggests that tabs are semantically more appropriate for indentation. The tab key inserts its own characters, which can have an arbitrary width defined by the program that reads it. In short, tabs are better for indentation, while spaces are better for tabular layouts such as the tmux key table I presented above.
  • The text width is 72 characters long. This is particularly important for writing good git commit messages. And, because git is designed with email in mind, this line length is ideal for sending plain text email, such as with mutt or neomutt.
  • Sentences in a paragraph start with two spaces after a period or full stop. This is better visually when typing in a monospaced font. The various parsers, e.g. Markdown to HTML, know how to convert that to a single space, just as they know how to turn hard line wraps between consecutive lines of text into uniform paragraphs (a blank line marks a new paragraph).
  • The cursor’s shape changes depending on the mode. It is a steady block by default, turns into a steady bar in “Insert” mode and a steady underscore in “Replace” mode (here “steady” means the opposite of “blinking”).
  • Syntax highlighting is on and uses my Tempus themes. Do not edit this part manually, as it will be changed when running own_script_update_environment_theme or its tempusmenu interface (see chapter on Tempus themes).

Read the .vimrc for an in-depth understanding of my customisations (it is a fairly short config).

Vim is not an OS

Now you may be wondering how it is possible to use Vim without plugins and all the accoutrements of a modern code editor. The answer is rather simple: let Vim be a specialised tool and leave the rest to other programs.

Do you really need Vim’s sub-par approach to multiplexing (its own approach to splits, buffers, tabs) when you can just be a tmux ninja? Why do you require a plugin to check git information inside Vim when you can just use the command line? Open a new tmux split and type git status, git log, git diff… You need to commit only parts of a changed file? Know that git add --patch is your friend.

In the same spirit, use the core utilities like cd, ls, find, grep, cp, mv, rm. Keep things simple and avoid feature creep. Let the text editor edit text. If you truly need an extensible, fully-customisable integrated development environment, then you should seriously consider GNU Emacs (which is a Lisp interpreter that implements a text editor among many others).

Of course, there are scenaria where a plugin makes Vim better for the task at hand. My point is that you should be very picky about your choice of external functionality. GNU/Linux is a powerful OS. You do not need to incorporate every kind of feature in the text editor. Perhaps there are other operating systems that make things difficult for the power user: if you are forced to use one of those, then I agree that forcing the kitchen sink into Vim may be the right way to go.