I am trying to persist some state about my buffers, specifically terminal buffers, over vim sessions with :mksession through the plugin vim-session by Xolox.

The goal is to assign labels to the terminal buffers (for usage with the terminal JSON API, implementing a source/sink based dynamic coupling), but for the future, I would like to have arbitrary data coupled tightly with my buffers. Terminals already restore nicely over sessions if their invocation command captures all behavior. It would maybe be possible to capture a label in those commands, but I don't like that as a system as it only solves the issue for terminals, but not for buffers in general.

The buffer number does not stay constant over session instances, so a global variable that I may persist to index the buffers (the Xolox session-plugin allows this) is out of the question.

I have scoured the :opt list of buffer options for something that is designed to store some arbitrary data, but found none.

How would I go about achieving that goal of attaching metadata to a buffer for permanent identification?

1 Answer 1


The buffer number does not stay constant over session instances,

:mksession reloads the buffer list: the buffer numbers will be same.

so a global variable that I may persist to index the buffers (the xolox session-plugin allows this) is out of the question.

I'm note sure what you mean/want, since I have never used the plugin before. However, :mksession does restore global variables. You can take a look at :h :mksession (specially point '1' and point '7':

1 - Restores global mappings and options, if 'sessionoptions' contains "options". Script-local mappings will not be written.

7 - Reloads the buffer list, with the last cursor positions. If 'sessionoptions' contains "buffers" then all buffers are restored, including hidden and unloaded buffers. Otherwise only buffers in windows are restored.

It seems to me that what you are looking for is already built-in. Are you sure it is not an issue with the plugin? The xolox/vim-session I've found received its last 3 years ago.

By the way, in case you need more control on the name of your terminal buffers, you can change the buffers name with :file [filename]. E.g. you could have one terminal named "term_one: :file term_one and another one named "term_two": :file term_two. This way next time you come back your session, they will have the same buffer numbers and names (more on :h file_f).

  • Hi, I think you are incorrect in "the buffer numbers stay the same." I deactivated the session plugin, checked for any set sessionopts assignment in my vimrc and run a test with pure :mksession. I wrote a few buffers so that their basename corresponds to the buffer number at the time of writing. After :mksession and :sourceing it again, the numbers were mismatched, as can be seen in this screenshot: i.snag.gy/qIBuHl.jpg
    – simlei
    Aug 26, 2018 at 12:50
  • Further, I appreciate your tip with :file. It does however not serve. It would actually assign a buffer a different file name for writing. Too invasive...
    – simlei
    Aug 26, 2018 at 12:57
  • To clarify w.r.t :file, this actually seems to work for terminal buffers, as their buffer initialization is inependent of this attribute. I would however like to find a solution that is applicable to all kinds of buffers...
    – simlei
    Aug 26, 2018 at 18:54
  • About the numbers: we have had different experiences, since they annoy me exactly because they don't change, and I do make use of sessions. You're right, it just makes sense to :file to terminal buffers. However, with the ability to type in only partial names and press enter, I didn't look for relabeling other buffers. BTW, from :h :buffers: Each buffer has a unique number. That number will not change. Sorry I couldn't help. Good lucky with your issue. (:
    – lsrdg
    Aug 27, 2018 at 9:16
  • Thanks! I have as yet not been able to find a custom data field, and the buffer numbers do seem to be inconsistent across sessions (that may be just how it is.).
    – simlei
    Sep 3, 2018 at 5:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.