If you’re running Neovim, you might also want your session file to record details of which processes were running in terminal buffers. By taking care to name your terminal buffers appropriately, you can make your processes resume when you restore a session.

Preparation

The source code that accompanies this book includes a webapp directory. Switch to that directory and install the dependencies:

This directory contains a simple web server. You can start the server by running:

You’ll also find a small test suite, which you can run with:

We’ll use these commands to illustrate the examples in this tip, so make sure you can run them before you proceed.

Saving a Session Captures Terminal Buffers by Name

To get started, open the app.js file in Neovim:

Now you’re going to use two slightly different methods to start the webserver. First, open a new terminal buffer in a split:

Press i to activate Terminal mode, then start the webserver on port 3001:

Next, you’ll start a second webserver on port 3002 with this one-liner:

Side by side, the two terminal buffers look similar. There’s one significant difference I want to draw your attention to: the buffer names. You can list them by running:

These can be generalized as term://{cwd}//{pid}:{cmd}. We can ignore the {cwd} and {pid}, but the {cmd} is significant. In one terminal buffer, the {cmd} is /usr/local/bin/bash, while in the other one it’s PORT=3002 npm run server.

Save the current session then quit:

Then, restart Neovim using the -S flag to restore the session you just recorded:

You should now see two terminal buffers: one containing a webserver process, and the other containing a bash shell. This doesn’t faithfully reproduce the session you recorded, which had two webserver processes running side by side. So what’s going on here?

When you save a session, the name of each buffer is recorded. In one case, you used :terminal PORT=3002 npm run server to launch the webserver process directly. When the session was restored, Neovim re-created this buffer by running: :edit term://PORT=3002 npm run server, which restarts the webserver process.

In the other case, you used :terminal to start a bash shell, then ran the npm run server command inside of the shell to launch the webserver. When the session was restored, Neovim re-created this buffer by running :edit term:///usr/local/bin/bash, which restarts the bash shell. Commands that were entered in the shell are not recorded in the session, although you may be able to retrieve them from your bash history.

Generally speaking, if you start a process using :terminal {cmd}, the {cmd} process will be restarted when a session is restored. Whereas if you use :terminal to start a shell, restoring your session will restore the shell. It doesn’t matter what commands you executed in the original shell; they won’t be recorded as part of a Vim session.

Renaming a Terminal Buffer

When it comes to saving and restoring sessions, the name of a terminal buffer is significant. You’ll be pleased to learn that you can change the name of a terminal buffer after creating it. To see how this works, let’s set up a new scenario. Open the app.js and test/app-test.js files, each in their own tab pages:

In the first tab page, create a new terminal:

Then switch to Terminal mode and run:

Switch to the next tab and create a new terminal there:

Then switch to Terminal mode and run:

Now take a look at the buffer names:

You already know what would happen if you were to save your session now and restore it: you would end up with two terminal buffers, each running a bash shell. It would be better if restoring a session would cause both the webserver and the test runner processes to start up again. Let’s make it so.

You can use the :file {name} command to rename your terminal buffers (:help :file_f). Activate the window containing the webserver, then run:

Next, activate the window containing the test runner and run:

Inspect the buffer list to check that it’s worked, then record your session and quit Neovim:

Now, restart Neovim and load the session you just recorded:

You should find that both the webserver and the test runner processes have been restarted.