zellij-org/zellij v0.38.0

Release v0.38.0

on GitHub

Zellij now includes a built-in session-manager. It is implemented as a plugin and so all of its API is available to plugin authors as well.
The session-manager can switch between sessions, focus a specific tab or pane in the current or in another session, create new sessions and fuzzy-find sessions/tabs/panes by their names.

By default, the session-manager can be started from the SESSION mode, the default key-binding sequence being Ctrl o + w.

If you have a custom keybindings configuration, please see the "Updating a custom keybindings configuration" section below.

If you have a custom keybindings configuration, please see the "Updating a custom keybindings configuration" section below.

You'll need to either:

1. Remove the clear-defaults=true part in order to get these keybindings "merged" with your custom keybindings.
2. Manually add the following sections to your configuration: session-manager, break-tab

One can now start plugins with a custom key/value configuration, either from layouts:

    pane {
        plugin location="file:/path/to/my/plugin.wasm" {
            some_key "some_value"
            another_key 1
        }
    }

Or from the cli:

zellij action launch-or-focus-plugin --configuration "some_key=some_value,another_key=1"

The LaunchOrFocusPlugin keybind (and launch-or-focus-plugin cli command) now include a move_to_focused_tab attribute. If true, when focusing the plugin it will always start in the user's focused tab. This is useful for UI pop-up windows (such as the session-manager) to not move the user's focus from the tab they're in.

Zellij plugins have always communicated with the host system (Zellij itself) by serializing/deserializing complex structures over STDIN/STDOUT. This caused problems both for other SDK writers who had to reverse engineer the serialization and for plugin upgrading. Starting this version, Zellij uses Ptorocol Buffers in order to communicate across the wasm boundary.

This means that plugins now should not break in future versions unless there's an API behavior change, which we as maintainers make an effort to do only very rarely.