Could the Yazelix tab-activity changes be upstreamed to avoid maintaining a fork?

[TyceHerrman]

Hi @luccahuguet,

Would you be open to upstreaming—or supporting someone else upstreaming—the three commits on yazelix-tab-activity-pipe, so Yazelix could eventually use official dj95/zjstatus instead of maintaining a fork?

I tested replaying the commits onto upstream v0.24.0. The rebase succeeded with two small conflict resolutions while preserving upstream’s focused-CWD support, newer command-lock implementation, and public invalidate_command_result API.

The resulting custom delta is limited to:

• Cargo.toml
• Cargo.lock
• src/pipe.rs
• src/widgets/tabs.rs

The version remains 0.24.0, zellij-tile remains 0.44.3, and the tests and warning-failing Clippy checks pass.

The functionality also seems potentially useful outside Yazelix: the pipe name and markers are configurable, any producer could send the schema-v1 activity messages, and the multiline/embedded-:: parsing fixes are generally applicable. Yazelix could continue owning its orchestrator and defaults while upstream owns the generic consumer.

I couldn’t find an exact upstream issue or PR. PR #228 explored a related per-pane status protocol but was closed as targeting the wrong repository, while PR #259 added native bell indicators without covering external busy/alert activity.

Is there a design or historical reason these changes need to remain Yazelix-specific? If not, would proposing them upstream—perhaps as a pipe-parsing PR followed by the tab-activity feature—now make sense?

[luccahuguet]

hey Tyce,

I'll properly answer this later, with more time

but we should def dig into this

also, here are a couple of things we still have to do:

• fix a couple of things in ratconfig
• humanize the readme
• investigate this issue (upstreaming to zjstatus)
• decide if the setting 'close sidebar on file open' is useful
• decide the v1 gate
• explore the https://github.com/marktoda/zj-radar sidebar
• create a fork policy to keep them up to date