[Feature Request] Session Restoration Strategies

[igorlfs]

Hello,

Great work with the plugin! Thanks for keeping it alive!

Currently, when restoring a (vim) session that contains diffview buffers, they are restored (as buffers do), but they are empty, and the usual diffview commands are unable to interact with them (e.g., if I were doing a :DiffviewOpen before saving the session, I can't use :DiffviewClose after restoring). This sucks, so I try to avoid saving sessions with diffview buffers.

I have some ideas of what the ideal workflow would be. The first one is simpler: using a SessionLoadPost autocmd to clean up the buffers. I happen to be a plugin author, and I'm using exactly this strategy with my plugin (the hook has to be eagerly loaded because a session might be restored before the plugin is "fully" loaded). IMO, wiping out the buffers is already a solid improvement. However, if you want to take this a step further, I have a second proposal.

Instead of deleting the buffers, their names could be parsed to try and recreate the "full" state (I have no idea if diffview's URIs are powerful enough to achieve this - and even if they are, it might be too complex, etc.). Would love to hear your thoughts.

I'm not sure how much of a session enthusiast you are, but oftentimes these "strategies" are delegated to session plugins, which is bad UX, IMO. For instance, last year I opened a PR to a session plugin to support yet another plugin, using an approach similar to the "cleanup on SessionLoadPost".

[dlyongemallo]

@igorlfs Can you please give #219 a try? This just does the wiping out of the diffview buffers using SessionLoadPost as you suggested. I couldn't get rid of the --No lines in buffer-- notifications on restoring the session, though.

[dlyongemallo]

I have no idea if diffview's URIs are powerful enough to achieve this

The URI doesn't capture enough information to reconstruct the state. I think what we could do is record the original command with arguments when a view is created, and save this to a file next to the session file (on SessionWritePost). Then the buffers can be restored using the original commands (on SessionLoadPost), instead of wiping them as #219 does.

[igorlfs]

The URI doesn't capture enoguh information to reconstruct the state.

:(

and save this to a file next to the session file

Alternatively, it's possible to save some data directly into the session file. If sessionoptions includes 'globals':

global variables that start with an uppercase letter and contain at least one lowercase letter. Only String and Number types are stored

For instance, nvim-dap-view leverages this to restore some structured data (watched expressions and their values).

The setup is a bit awkward (the need to encode as JSON, the reliance on a non-default flag), but I think it's the most solid approach, considering vim's limitations. A Lua rewrite of sessions is planned, but I think it'll take some time for someone to actually start working on it.

If you feel this alternative is too fragile, I'm open to starting a new discussion (in core) to establish some "best practices" for plugins to fully handle sessions (as in, a lua-plugin-sessions help tag), considering the existing limitations. I'm leaning more towards that (rather than having a "special case" (external file) here) because my end goal is making every plugin I'm using play nice with sessions!

[dlyongemallo]

I think SessionWritePre (which you mentioned in #219 (comment)) is exactly what is needed here. Without it, it's impossible to write the changes to a global between the user asking the plugin to save a session and the session file being written. I don't think the nvim-dap-view approach works here, because the payload is larger and more fragile. Writing to a sidecar file in SessionWritePost bypasses this problem, at the expense of introducing an additional file.

[igorlfs]

Without it, it's impossible to write the changes to a global between the user asking the plugin to save a session and the session file being written.

I see. Thanks for looking into it. I think the "wiping out" approach is already a solid improvement.

[dlyongemallo]

@igorlfs I've implemented session restoration with a sidecar file as described above in PR #235. Can you please try it?