The default behavior of tmux-sessionizer should allow you to switch between all tmux sessions

[emiara]

Currently:
Running tms without subcommands only creates sessions based on git repositories from configured directories. This means it only handles repo-related sessions—both existing and new ones.

The only command which is implemented for non repo/bookmark-sessions is the tms switch command(With --switch-filter-unknown false)

Issues with the Current Approach

1. Limited Session Switching

   $ tms sessions                # Lists all running tmux sessions ✅
   $ tms open-session {name}     # Fails for non-repo sessions     ❌
   $ tmux a -t {name}            # Works manually                  🙄

   It should be possible to open any session listed by tms sessions.

2. Bookmark Limitations
   Although bookmarks can achieve similar functionality, they force you to use a different directory for each session. This means you can’t have two sessions in the same directory (e.g., your home directory).

3. Real-World Use Cases Are Ignored

   • Many users run long-lived sessions like sysadmin, monitoring, or remote sessions.
   • Users also create temporary sessions for one-off tasks (system updates, configuration changes, etc.) that aren’t related to any git repo.

   These sessions are important enough that they shouldn’t require bookmarking.

Although the git repo integration is maybe the main pulling factor of this tool, a tmux_sessionizer should not be limited to that. The tool should support switching between all tmux sessions by default.
If not it should be renamed to repo_tmuxinizer!/s

[emiara]

I am unsure what would be a fitting flag for (enabl/disabl)ing this? That is, without crashing with the existing --switch-filter-unknown which controls this behavior for tms switch command only.

[junglerobba]

It should be possible to open any session listed by tms sessions.

I don't want to sound too dismissive, but isn't this already covered by the existing tms switch command, which by default includes all open sessions? My expectation would be that the regular tms command is mainly for creating new sessions (and therefore doesn't really need to list currently open sessions) and tms switch lists open sessions, including all tmux sessions outside of configured git repos.
At least I have hotkeys for both of these in tmux and use them depending on what I want.
But maybe there's a usecase I'm missing?

[emiara]

Fair enough. The tms switch command does provide the desired functionality. I think maybe I am just projecting my expectations about how I thought this tool would work.

My expectation would be that the regular tms command is mainly for creating new sessions (and therefore doesn't really need to list currently open sessions).

Yeah, it doesn't need too ofc., but it does list currently open sessions — if they are in a repo, that is. And bookmarks! Only standard tmux sessions are not included.

Maybe my use case is rare. I find myself just using the tms command, bound to <C-o>, over tms switch because we are using fuzzy finders either way, and I enjoy this tool removing the overhead of distinguishing between existing and non-existing sessions.

I also often have projects not managed by Git with long-running tmux sessions.

I guess what I am saying is that we have two commands for easily switching between sessions: tms and tms switch. However, we currently have no fully comprehensive command that allows fuzzy-finding all four types of sessions accessible by the tool:

1. Tmux sessions running in a Git repo
2. Tmux sessions not running in a Git repo
3. Tmux sessions creatable in a Git repo
4. Bookmarks

All I am saying is that an fzf-based tool should have an all subcommand. Of course, tms all would work fine if we don’t want to disrupt the current functionality, but I think it should be the default command with no specified arguments that already lists 3/4 types. The existing behavior could then be renamed to tms repos.

[junglerobba]

I guess I see your point. I don't want to make the final decision on this, but imo if we were to do something like this, we should probably combine the (admittedly awkwardly named) --switch-filter-unknown and your suggested new flag into one.