feat(panes): FocusLastPane action

[DawidPietrykowski]

This PR adds FocusLastPane action as described in #4142

The "last pane" is considered per-user per-tab per-mode. Which means that:

• In the case of multiple users, one user's switches don't affect the second user's last page
• Each tab has it's own record of the last pane
• Floating panes have a separate last pane context from the tiled panes

Tested quite extensively locally and I'm pretty sure that most of the cases are covered. At least I couldn't break it but there could of course be something I missed.

Some notes:

• When adding a new pane, the last pane is set from the current one for that user
• All actions that change focus purposefully, such as FocusPreviousPane, focus based on direction or mouse clicks save the last pane

Also added tests and keybinds (Alt \ for default and ; for tmux)

[imsnif]

Hey @DawidPietrykowski - thanks for putting this together. I have not tested this, but unless I missed something going over these changes, I think this falls into the usual trap we have with our architecture in regards to the CLI.

Zellij is a true multiplayer application, meaning each connected user has its own cursor and can be focused on different panes as well as different tabs. If two users are focused on the same pane in the same tab and one of them issues this command, Zellij does not have a good way of distinguishing which user should have its focus switched. With a keybinding we don't have this problem since those are user-aware (being Zellij entities).

I realize there are existing CLI actions that do this, but these are legacy and do not behave well in the above scenario. I would opt for fixing them before adding new ones with similar behavior.

The proper fix for this case (and many others), would be to add a mechanism that would detect the proper connected user to operate on in a robust way. This would be something like: find the last user to issue input in this pane while being focused on it and switch that user.

If you'd like to work on such a mechanism in a separate PR (optionally adding all the missing CLI actions to it as well), I'd be happy to review and accept that contribution and then we can move on to this one, which has an additional problem: we already have a last-focused mechanism, but that one is suffering from issues this one likely will in the future: it needs to be manually updated by each method that changes focus. Invariably over the years in a code-base this is "forgotten" and not all methods update it. It would be best to add a mechanism that does this implicitly so the developer does not need to remember to do it (might be that this solution handles it better, I have not looked deeply into it).

Let me know if you'd like to work on that mechanism and need pointers.

[DawidPietrykowski]

Hi @imsnif, thanks for taking a look at this. I can see your point, though adding such mechanism and making sure it covers as many edge cases as possible + modifying exiting code that changes panes to use a common interface feels like a bigger effort.

I'd consider working on it but I'd like to focus on the scrollbuffer performance first (from #4237 (comment)).

I suppose this PR could just wait for those changes to happen first, unless you're open to one last action before the refactor :)

Also, what specifically are you referencing here?

we already have a last-focused mechanism