feat(attach): Support `--first` option for `attach` sub-command to let zellij choose the alphabetically first session; resolve#823
fix(attach-first): Fix `--first` option to choose the first created session in the existent sessions
feat(attach): Support `--index` option to choose the session indexed by provided number like -t option of tmux
feat(attach): Support listing active sessions with index when a provided number is not found in the active sessions
feat(attach): Support listing active sessions with index when a provided number is not found in the active sessions
feat: Add anyhow to uniformly treat error types and avoid panics
* feat(sessions): mirrored sessions
* fix(tests): input units
* style(fmt): make rustfmt happy
* fix(tests): make mirrored sessions e2e test more robust
* refactor(sessions): remove force attach
* style(fmt): rustfmtify
* docs(changelog): update change
* fix(e2e): retry on all errors
fixes#688
- the `options` subcommand of `attach` functions the same,
as the `options` subcommand of creating the normal session,
but not every option will have an effect on reattaching,
for example the `default_mode` setting would make no sense
to switch.
In the future it would make sense to be able to hot swap some
of the options on reattach, but we are not able to do that yet,
for example the `default_shell` one.
Eg:
```
zellij attach <session-name> options --theme <theme>
```
Simplify deserialzation for layouts, config and config options.
Move the logic responsible to `Setup::from_options()` in order
to be able to parse `main.rs` as well as adding new command easier.
fixes#603, fixes#349
* The layout has now a unique `tabs` section,
that can be used, like the `parts` section,
everything that is not inside the tabs section
is assumed to be present on every single tab
that is opened.
This is a BREAKING CHANGE for people that use
custom `layouts` already, since the `tabs` section
is not optional - for clarity and intentionality reasons.
The functionality to specify multiple tabs is already there,
but is still gated behind a panic, until #621 is fixed.
So for now one tab can be specified to load on startup.
* The `NewTab` action can optionally be bound to open
a layout that is assumed to be in the new `tabs` section
This is a BREAKING CHANGE for people that have the
`NewTab` action already bound in the config file:
```
- action: [NewTab, ]
key: [F: 5,]
```
must now be specified as:
```
- action: [NewTab: ,]
key: [F: 5,]
```
Optionally a layout that should be opened on the new tab can be
specified:
```
- action: [NewTab: {
direction: Vertical,
parts: [ {direction: Horizontal, split_size: {Percent: 50}}, {direction: Horizontal, run: {command: {cmd: "htop"}}},],
key: [F: 6,]
```
or:
```
- action: [NewTab: {direction: Vertical, run: {command: {cmd: "htop"} }},]
key: [F: 7,]
```
or
```
- action: [NewTab: {
direction: Vertical,
parts: [ {direction: Vertical, split_size: {Percent: 25},run: {plugin: "strider" }}, {direction: Horizontal}],}, MoveFocus: Left,]
key: [F: 8,]
```
Adds the ability to dump the default layouts to
stdout, similar to the `zellij setup --dump-config`,
but now it needs the name of a currently existing
layout:
- default
- strider
- disable-status
`zellij setup --dump-layout [LAYOUT]`
We add log4rs create for logging across Zellij. Additionally, we capture
`stderr` output from plugins and log it the same log file as other
Zellij logs.
* default layouts won't be installed by anymore,
instead they will be directly loaded
* `layout-dir` is now a subdirectory of the
`config-dir` by default, instead of the `data-dir`
POSSIBLE BREAKING CHANGE:
In case of having custom layouts in the previous
`layout-dir` one can switch either the layouts to
the new dir, or set the `layout-dir` to be the current
`layout-dir`
* it is possible to change the location of the `layout-dir`:
- `zellij options --layout-dir [LAYOUR_DIR]`
- `layout_dir: [LAYOUT_DIR]`
* The setup subcommand was exiting the programm no matter what
even if the `clean` flag was provided.
Now it returns to the
main function on encountering the clean flag.
* The check option communicates default and config options to the user
as well as optional compile time features
* Move generate-completion from a subcommand to a flag in the setup
subcommand
