[FEATURE] Allow option to preserve jumplist on session restore

[tinzh]

Is your feature request related to a problem? Please describe.
The jumplist used to be saved and it was helpful for picking back up, but now it gets cleared on session restore with no option to turn it off.

Describe the solution you'd like
A config option that allows the jumplist to not be cleared on session restore. I don't have that much context on why the jumplist needs to be cleared, but maybe it could be moved to somewhere else and serve the same purpose?

Describe alternatives you've considered
Currently manually removing the lines where clearjumps is called, which is hacky.

Additional context
Jumplist clearing on restore introduced in #334

[cameronr]

in #334, I unified some logic between SessionRestore and auto-restoring a session when changing a directory (when cwd_change_handling is true). The first didn't clear jumps but the second one did.

I think the idea behind clearing the jumps is that they may be from a previous session. That said, I could see how that could be annoying if you're loading the same session regularly. Ideally, jumps would be saved as part of the session (rather than in a global file) but that's not how nvim sessions work currently.

@rmagatti do you remember the original reason for clearing jumps (I think in originally added in 9848758)?

[rmagatti]

@cameronr yes, when jumps are not cleared and you change sessions you might end up jumping to files that have nothing to do with the session or project you're currently on. Ex: If I am in my dotfiles working on some changes, and then I switch to a new session from a work project, for example, and immediately I hit Ctrl+O, then what would happen is I would jump to my dotfiles' latest buffer, which is undesired.

And yes, I'd love for jumps to be saved as part of sessions, but I don't believe that's possible currently with mksess

[cameronr]

I briefly looked into the possibility of saving the jumplist but while there's a way to get the jumplist (vim.fn.getjumplist()) it doesn't look like there's a way to then set the jumplist.

My proposal would be to add a config option clear_jumplist and have it default to true and work as it currently does. When set to false, it will not clear the jumplist when restoring a session.

@rmagatti how does that sound?

[tinzh]

I never realized jumps were saved globally, so this makes sense why it's cleared by default. My nvim workflow though is to keep a lot of nvim windows open in tmux, and if I close one, I open the same one right back up and the jumps match.

Maybe there could be a global sentinel file that has which session the jumplist was last saved for, and if that same session is opened, the jumplist isn't cleared? A simple to config to always not clear the jumplist (and accepting the possibility of a junk jumplist) would also work for me. Thanks again!

[tinzh]

Could also try this: https://www.reddit.com/r/neovim/comments/18zvlq6/manually_changing_jumplist/

[cameronr]

@tinzh Nice find! I added ShaDa saving support. Any interest in testing it out? If so, temporarily change your lazy auto-session config as follows:

  -- 'rmagatti/auto-session',
  'cameronr/auto-session',
  branch = 'shada',
  opts = {
    ...
    save_and_restore_shada = true,
  }

If you test it, let me know how it works for you.

[tinzh]

Sure thing, I can do it when I get to work Tuesday 👍

[rmagatti]

Ah yes, I remember looking into Shada back in the day, pretty interesting!

[tinzh]

Ok it seems to work! Here's what I did to test:

• jump in nvim 1
• jump in nvim 2
• repeat both a few times
• close nvim 1
• close nvim 2
• open nvim 1
• open nvim 2

The resulting jumplist is right for both nvim sessions.

I think nvim already saves shada by default (my jumps were saved before somehow), so to avoid doing it twice, could we maybe set the shada or shadafile opts before opening nvim? At a glance, it isn't clear at what point on startup nvim reads shada/on exit writes shada, and if it's before/after any plugins can do anything. Setting shadafile="NONE" doesn't work, even though I feel like it should if you're providing a filename; I'll make an nvim issue for this: neovim/neovim#32510

Relevant docs: https://neovim.io/doc/user/options.html#'shada' https://neovim.io/doc/user/starting.html#_shada-(

[disrupted]

@tinzh Nice find! I added ShaDa saving support. Any interest in testing it out? If so, temporarily change your lazy auto-session config as follows:

-- 'rmagatti/auto-session',
'cameronr/auto-session',
branch = 'shada',
opts = {
...
save_and_restore_shada = true,
}
If you test it, let me know how it works for you.

this is fantastic and something I've been looking for because I've also been annoyed with the shared jumplist across different projects.

Could we maybe separate auto restore of the shada and session?

Because currently I have auto-session configured with auto_restore=false. I manually run :SessionRestore when needed. But I'd like to always restore the saved shada to have a project-local jumplist.

[cameronr]

@tinzh great, thanks for the testing! I also played around with setting shadafile but it didn't seem any better than what I'd committed. I don't mind the double writing just because it makes sense to me to save the shada at the same time when saving the session. The default shadafile gets written on exit which means starting nvim in a dir with no session will pick up the shada from the last session that but that also seems reasonable to me.

@disrupted does the shada/jumplist work as you're expecting with my branch? there's no technical reason it couldn't be separated but I'm worried about scope creep for auto-session. one way to support it would be to expose the get_session_file_name function in auto-session and then you could use hooks like this:

    ---@type AutoSession.Config
    opts = {
      -- i think you don't want the shada code i just added to run because when you don't load a session, calling
      -- SessionRestore will replace your current shada (jumplist) with what was last written to disk
      -- save_and_restore_shada = false

      -- read shada on startup if it exists
      no_restore_cmds = {
        function()
          local autosession = require('auto-session')
          local shada_file_name = autosession.get_root_dir() .. autosession.get_session_file_name() .. '.shada'
          vim.notify('loading shada')
          if vim.fn.filereadable(shada_file_name) == 1 then vim.cmd('rshada! ' .. shada_file_name:gsub('%%', '\\%%')) end
        end,
      },

      -- save shada when we save a session
      post_save_cmds = {
        function()
          local autosession = require('auto-session')
          local shada_file_name = autosession.get_root_dir() .. autosession.get_session_file_name() .. '.shada'
          vim.notify('saving shada')
          vim.cmd('wshada! ' .. shada_file_name:gsub('%%', '\\%%'))
        end,
      },

    }

Note: this code won't work until we decide and check in exposing get_session_file_name
Note2: you'd have to replace event = 'VimLeavePre', with lazy = false, in you auto-session config so it can load shada on startup

@rmagatti what do you think about shada support (as checked into this branch) and what are your thoughts about the above solution?

[disrupted]

@disrupted does the shada/jumplist work as you're expecting with my branch? there's no technical reason it couldn't be separated but I'm worried about scope creep for auto-session. one way to support it would be to expose the get_session_file_name function in auto-session and then you could use hooks like this:

tbh I haven't tested it that thoroughly in everyday usage yet. I would be completely fine with using those hooks. It looks like exactly what I want to achieve. Always save and load shada to achieve the project-local jumplist, save session on quit, restore session manually.

edit: I am wondering if for my use-case I even need the auto-session integration. based on your proposal above I could just define the two autocmds.

edit2: wouldn't it actually suffice to set vim.o.shadafile = '.vim.shada' (disable global shada, use project-local shadafile instead) to achieve the same result?

[cameronr]

I haven't had much experience with setting shadafile but if you don't want any global shada, that seems like it should do what you want? Let us know if it does end up solving your use case.

[disrupted]

It seems to work really well so far.

With the previous approach I encountered an issue where the global shadafile was leaking into the project-local shada on initial creation. For my use case I figured I simply don't need a global shada, so it's better to disable it entirely.

With the new config I like that it keeps the project shada files relatively small and tidy (marginal performance gains? nothing noticeable anyways) and I can easily reset it on a per-project basis by deleting the file if needed. Plus I can continue to lazy-load auto-session.

edit: I made it a little bit more sophisticated now to determine the Git root for each project workspace instead of saving a separate shada for each subfolder. Also reconsidered the save location and settled for the standard nvim state path. disrupted/dotfiles@0e7302e

[rmagatti]

@cameronr I've looked at the implementation in your branch and find it interesting. However, I noticed an important consideration: there isn't currently a distinction between a "global shada" and a "per-session shada" file.

While saving jumplists and search history is very useful within the context of a single session, it becomes problematic when these elements from one project "bleed" into another project's session.

I believe session isolation is crucial. A potential solution could be to save a separate shada file per session and load it accordingly during session restoration. We could make this configurable, allowing users to opt for either:

1. The isolated per-session shada behavior
2. The traditional global shada behavior

With the default behavior being session-isolated ShaDa