Neovim and tmux-resurrect session interaction

[arilebedey]

Description:

I have applied the entire tmux configuration, including the systemd service, as provided in this repository. However, I am encountering an issue where my Neovim sessions are not being restored as expected when using tmux-resurrect.

Steps Taken:

1. Applied the full tmux configuration from this repository.
2. Configured and enabled the systemd service as described.
3. Verified that tmux-resurrect is functioning for other aspects of my setup.

Issue:

When tmux-resurrect tries to restore a neovim session it runs always runs a command like this: nvim rtp^=/nix/store/i1lm10vb4qk5yx2zh2njik7a7x6gnd29-vim-pack-dir (with only the hash changing), which opens an empty file in Neovim.

Prediction:

My suspicion is that this could be due to some specific Neovim configuration, particularly involving the auto-sessions plugin, which I am using to successfully restore session on its own.

Any guidance or suggestions on how to troubleshoot or resolve this issue would be greatly appreciated.

Thank you for your assistance!

[p3t33]

Hi, As a reference you can look at a slimier issue Help with tmux-resurrect config that was resolved recently and has more description on how all of the plugins and neovim play ttogether.

Now I am glad to hear that the overall mechanics of tmux and the two plugins(resurrect and continuum) are working for you.

Just to make sure when you create a new session, open a new tab with htop in it. Will the session gets automatically saved for you to restore from once tmux starts does it automatically restores all the saved sessions? Keep in mind that tmux sessions only get saved if tmux is in the foreground and the interval for saving has passed(set to 10 minutes in my settings).

As I mentioned in the link I provided at the top of this comment, resurrect saves tmux state into a file which is then used for restoring the state(located at rresurrectDirPath) named last.

Now nix introduces some junk into this file that is cleaned in my settings using set -g @resurrect-hook-post-save-all 'sed -i -E "s|(pane.*nvim\s*:)[^;]+;.*\s([^ ]+)$|\1nvim \2|" ${resurrectDirPath}/last'

You need to make sure that your state files that are created using resurrect plugin are valid for vim/neovim.

This is a valid file example that I just copied form

pane conflict 1 1 : 1 home-desktop :/home/kmedrish/projects/lsp 1 nvim :nvim com.cpp pane nixos_flake 1 0 :- 1 home-desktop :/home/kmedrish/projects/nixos_flake 1nvim :nvim pane nixos_flake 2 1 : 1 home-desktop :/home/kmedrish/projects/nixos_flake 1zsh : window conflict 1 :"" 1 : cebd,114x39,0,0,0 : window nixos_flake 1 :"" 0 :- cebe,114x39,0,0,1 : window nixos_flake 2 :"" 1 : cec1,114x39,0,0,4 : state nixos_flake

Now the final part of the puzzle it neovim and its own sessions. At its core when you execute :mksession from within neovim you will get a Session file at the root of your directory.

This file can be used by tmux to not only resurrect your neovim but resurrect it with this Session file. This is defined with set -g @resurrect-strategy-nvim 'session' set -g @resurrect-strategy-vim 'session'

Once you introduce something like startify or auto-sessions(which I never used) you are enabling neovim to do its own "resurrect" of neovim session regardless of tmux. So in my case of using startify with neovim and Session file session restore provided by tmux is redundant. In your case with auto-sessions as you mentioned they might clash but before you go there first make sure that everything I suggested works for you first.

[arilebedey]

Hi,

Thank you for the detailed response and guidance.

I followed your suggestions and was able to successfully restore the htop session. Here are the steps I took:

1. Created a new session named "htop".
2. Opened htop in this new session.
3. Used prefix + C-s to save the session.
4. Used :kill-server to stop tmux.
5. Rebooted the machine.

After the reboot, htop was restored to the same working state!

However, I noticed a couple of issues regarding the content of the file located at {resurrectDirPath}/last:

1. Missing Session and Application Details: The file does not mention the htop session or the new session name. Instead, it seems to contain details of an old session. Is there a reason why the new session and htop are not being recorded?

2. Long Neovim Command: The details for Neovim in the file are quite extensive. Here is the content related to Neovim:

   pane    Neovim  0   1   :*  0   ncs :/home/ari  0   nvim    :/home/ari/.nix-profile/bin/nvim --cmd lua vim.g.loaded_node_provider=0;vim.g.loaded_perl_provider=0;vim.g.loaded_python_provider=0;vim.g.python3_host_prog='/nix/store/gm0h9gq6fb0n1bvynm39flbbndxgsw5v-neovim-0.9.5/bin/nvim-python3';vim.g.ruby_host_prog='/nix/store/gm0h9gq6fb0n1bvynm39flbbndxgsw5v-neovim-0.9.5/bin/nvim-ruby' --cmd set packpath^=/nix/store/i1lm10vb4qk5yx2zh2njik7a7x6gnd29-vim-pack-dir --cmd set rtp^=/nix/store/i1lm10vb4qk5yx2zh2njik7a7x6gnd29-vim-pack-dir
   pane    Neovim  0   1   :*  1   ncs :/home/ari  1   zsh :
   window  Neovim  0   :zsh    1   :*  c912,142x37,0,0[142x18,0,0,0,142x18,0,19,1] :
   state   Neovim

   The Neovim command seems unusually lengthy and complex. Could this be an indication that the session details are not being parsed correctly? Do you think this might be causing issues with the restoration process?

Thank you again for your assistance.

Best regards,
Ari

[p3t33]

A few pointers,

1. you can use systemd to restart tmux
   systemctl --user restart tmux.service

2. When you update your nix configuration tmux will take them into account only after you restart it or in case you source the new settings from tmux, in my config I use bind-key e source-file ${generatedConfigFilePath} \; display-message "${generatedConfigFilePath} evaluated."

3. continuum plugin saves(using the resurrect plugin) sessions state only when tmux is in focus and only at defined interval.

The continuum plugin should be considered the last piece of the puzzle, in the sense it only automates the use of resurrect plugin to save sessions automatically and automates restoring the most current state(defined in last file which is just a soft link pointing at the last state file in the resurrect directory). So when debugging your issue you should remember that continuum is just the automation you first need to make sure your foundation(resurrect is working).

Also neovim, and its representation in the last file(created by resurrect plugin) is a separate issue. *And in your file it is full of junk that needs to be cleaned up with the sed command.

So I would debug in this order:

1. I will create a very basic session with htop, man page(of somehting), then execute prefix + C+s and then look at the last file and the file it points to to see if everything checks out. Each time you execute prefix + C+s you should see a new file created in the resurrect directory with last file pointing to it.
2. Next assuming this works you can optionally check if continuum plugin is working. By leaving tmux in the foreground and making a change of state a new state file should be created in the resurrect directory every 10 minutes(my config settings) automatically. Note every time you change something(adding or removing tab a pane) and waiting the 10 minutes you should see a new state file created in the resurrect directory.
3. Now speaking about neovim as I already mentioned your state file is full of junk that sed command should handle. Make sure you are using my current command(as it defined in the nix file for tmux :

set -g @resurrect-dir ${resurrectDirPath}
set -g @resurrect-hook-post-save-all 'sed -i -E "s|(pane.*nvim\s*:)[^;]+;.*\s([^ ]+)$|\1nvim \2|" ${resurrectDirPath}/last'

[arilebedey]

Hi,

Thank you for the detailed pointers and guidance. I’ve made some progress and have a few observations and questions.

1. Wrong Directory Issue: I realized that I was initially looking at the wrong directory. My tmux can restore a basic session with htop, a man page, and a simple Neovim file. This confirms that the fundamental mechanics of tmux-resurrect are working properly.

2. Auto-sessions Plugin Conflict: The auto-sessions plugin for Neovim appears to be the root of the problem. This plugin attempts to restore a session for each directory when opening Neovim from that directory. I can see how this might clash with tmux-resurrect.

Given these points, I am curious about your workflow around Neovim sessions. The 1-session-per-directory limitation of the auto-sessions plugin seems restrictive, especially considering the flexibility that tmux offers. Do you have a different approach or workflow for managing Neovim sessions that might avoid this conflict? Any insights on how you effectively manage and restore Neovim sessions alongside tmux-resurrect would be greatly appreciated.

Thank you again for your assistance! =)

Best regards,
Ari

[p3t33]

Start by disabling your auto-sessions plugin and Create the Session file using :mksession and see how tmux handles this. Assuming there is a conflict and you want to keep using the auto-sessions pluginYou can side step the incompatibility of tmux-resurrect and the plugin. Just disable tmux-resurrect form handling the restoring of neovim sessions by removing

set -g @resurrect-strategy-nvim 'session' set -g @resurrect-strategy-vim 'session'

from the tmux config file.

I can also add that the vim-startify plugin I am using which can manage and restore sessions(among other things) works just fine with tmux resurrect-strategy- with no conflicts. But as I mentioned at this point this interaction is just a redundancy and there is no real reason for me to keep the tmux resurrect-strategy- configurations besides removing vim-startify and some point and then scratching my head when tmux stops restoring my neovim sessions.

I don't feel restricted with one neovim Session per directory as each such directory is usually a git repository so it makes sense to have single session for each git branch I am working on. To expand on this. I am using git worktrees, so each branch is represented by separate directory inside of the git repository and inside each such directory I create neovim Session file. Now each such directory correspondence to a single tmux session. *additional benefit of git worktrees is the fact that I don't need to stash anything which makes the process of context switching much less mentally taxing.

Sn the high level I switch between tmux sessions(which becomes my multiple session manager with or without neovim in them), each representing a single work directory(mostly git branches in the form of git worktree directory). Inside of each neovim session I use fzf/telescope plugin to find files of interest and then I "harpoon" the once I access the most using the harpoon plugin.

When tmux starts on boot(as systemd service), it loads all of my sessions state from the last file and once I open tmux and just jump right back to where I last left off.

So to sum up its a separation of responsibilities, with tmux being the high level session manager and neovim only managing the state of files of interest inside of a single tmux session.

[arilebedey]

Hi,

Thank you for the detailed explanation and suggestions.

To summarize your advice:

1. Disabling Auto-Sessions Plugin:

   • I should disable the auto-sessions plugin and create the Neovim session file manually using :mksession to see how tmux handles it.
   • If I want to keep using the auto-sessions plugin, I can avoid the conflict by removing the following lines from my tmux config:

     set -g @resurrect-strategy-nvim 'session'
     set -g @resurrect-strategy-vim 'session'

2. Using Vim-Startify Plugin:

   • The vim-startify plugin can manage and restore sessions without conflicts with tmux-resurrect.
   • Keeping the tmux resurrect-strategy-* configurations is redundant with vim-startify but may be useful if I ever stop using vim-startify.

3. Your Workflow:

   • You don't feel restricted with one Neovim session per directory, as each directory usually represents a git repository or a worktree.
   • Tmux acts as the high-level session manager, and Neovim manages the state of files within each tmux session.
   • This separation of responsibilities allows for an efficient workflow and context switching.

This is a great starting point for me to resolve the conflicts and streamline my workflow. I appreciate the insights into your setup and how you manage sessions with tmux and Neovim.

Thanks again for your help!

Best regards,
Ari

[p3t33]

You welcome, good luck.