[FEATURE] Properly support tab-scoped sessions

[caenrique]

Is your feature request related to a problem? Please describe.
I usually use tabs as different projects, or specific UI layouts (eg: diffview, neogit, etc) and for that I remove the tabpages from sessionoptions, but then closing the tab leaves me with a lot of buffers related to that session open, which could be closed.
I know that plugins like https://github.com/xolox/vim-session#tab-scoped-sessions implement this feature, so I just thought that it would be very nice to have that as well :)

[rmagatti]

Hey @caenrique I think this technically already works? You'd need to remove tabpages from your sessionoptions that way a session would only work for the particular tab you are in. Exactly like they mention it in the link you linked.

[caenrique]

Ok, I'll try to be more precise:

I am using sessionoptions without tabpages and the behaviour I want from this plugin is:

• Keep track of the buffers associated to a session and close them when the session is closed, if it was a tab-specific session

This is not implemented right now, and even though tab sessions work in a basic level, it's kind of inconvenient to use as is. This would be awsome.

Some other related things:

• I opened an issue at Feature: Open session on new tab session-lens#19 which would make this use case also more convenient.
• I also noticed that the command RestoreSession which accepts a path to a session file, doesn't autocomplete, so I have a modification with -complete=file. I can open a PR or a new issue for that if necessary. This way works, but it would also be more convenient if we would have a command like RestoreSessionByName and we could autocomplete just by name, and not by path

I am willing to help implement some things if necessary.
Anyway, thanks for your time :)

[rmagatti]

Keep track of the buffers associated to a session and close them when the session is closed

I'm a bit unclear on what you mean by this; sessions are really just point in time snapshots of your current nvim state, keeping track of buffers being open and somehow associating them with particular sessions would make things much more complicated, plus one would have to somehow add handling for when one loads up another session from within another one.

Overall the reason the behaviour you want is difficult to achieve is because different tab pages don't really have their own state, a session is a Neovim wide thing -- like you said, not saving tab pages is somewhat of a primitive way of achieving per tab sessions, but it won't be perfect based on how tabs, state and Neovim's mksession actually work.

I also noticed that the command RestoreSession which accepts a path to a session file, doesn't autocomplete, so I have a modification with -complete=file. I can open a PR or a new issue for that if necessary. This way works, but it would also be more convenient if we would have a command like RestoreSessionByName and we could autocomplete just by name, and not by path

This one is perfectly doable I think, there's already an example of how that's done currently in the code I'd be glad to review a PR on this!

[rmagatti]

@caenrique so I just learned that Neovim has :h tcd for setting a working directory locally for a tabpage.

This is promising as it means it would be somewhat easier to support tab scoped sessions.
I still don't have a clear implementation plan in mind but progress is progress :)

[TC72]

I posted #189 as my use case is different. I have a single session for my project, but have lots of tabs open, each with their own working directory for sub folders inside my project. Because I work on web sites, it could be templates, sass files and javascript for example.

But after reading this issue again even though the use cases are different the underlying issue and solution might be the same.

As I posted there it's possible to use :tcd to give a tab it's own working directory, but also :lcd which gives a window it's own working directory, when working with splits.

The way to get the setting for each is like this:

vim.fn.getcwd() - gets the local cwd, :lcd
vim.fn.getcwd(-1) - gets the tab cwd, :tcd
vim.fn.getcwd(-1,-1) - gets the global cwd, :cd

in all those cases if a more specific cwd hasn't been set then the function will return the next one up.
So if you've never used :tcd or :lcd then using vim.fn.getcwd() will return the global cwd as set with :cd.

For that reason changing the code in Lib.escaped_session_name_from_cwd() to use vim.fn.getcwd( -1,-1) would make no difference for people who don't use :lcd or :tcd but would fix this issue for people who do.

It would still be nice to have this as an option but I'm going to fork the project and try out this "fix" for myself and see if there are any unwanted side effects.

[TC72]

Here is my fork with just getcwd() changed to getcwd(-1,-1) in Lib.escaped_session_name_from_cwd().
It now works exactly as I'd want.
https://github.com/TC72/auto-session

This isn't in a state for me to ask you to pull it, it's a change in behaviour which might not be what some people want.
My feeling is this wouldn't break people's workflows but I can't be 100% on that.
If it would cause issues then this would need to be added as an option so people can choose how getcwd() works.

Also, I'm only changing getcwd() in one place right now, but it's used in other places.
I guess it'd just be the same code in each case.

auto-session.lua - suppress_session()
auto-session.lua - is_allowed_di()
auto-session-library.lua - legacy_session_name_from_cwd()

It's also used in several places in auto-session-autocmds.lua, in all cases it's for logging debug messages.
And finally in the README.md it's used in an example of how to update the directory of a session in nvim-tree.

@caenrique do you want to try this fork to see if it fixes your issue?

[caenrique]

Hey! Sure I'll give it a try this afternoon :)

[TC72]

Hey! Sure I'll give it a try this afternoon :)

Hey @caenrique, did you ever get a chance to try this?

[caenrique]

Hey, Sorry that I didn't answer back 😅
Yes, I tried this, and no, it doesn't fix mi issue, but that's ok.
I've realized that what I wanted to do is too involved anyway