natsukium/felis-tui
Watch
1
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

chore(tui): follow felis to the v0.1.0 release #5

Merged
natsukium merged 3 commits from follow-felis-v0.1.0 into main 2026-09-26 20:53:19 +09:00
Conversation 0 Commits 3 Files changed 8 +162 -123
natsukium commented 2026-09-26 19:12:44 +09:00
Owner
Copy link

Pins every felis crate to the v0.1.0 release tag on https://github.com/felis-terminal/felis (not on crates.io). The old pin was 105b0899.

Closes #3. That issue asked for a follow to 6da5620d, and v0.1.0 contains that commit.

What broke

  • felis_client_core::key_encode is gone. felis moved key encoding into the daemon, which owns the keyboard modes. felis-tui now translates each crossterm key into a felis_protocol KeyEvent and sends InputMsg::Key. It no longer encodes bytes from its shadow copy of the modes. The literal-prefix byte is still sent as raw KeyBytes.
  • env_base::fill_for_local became env_base::fill_for_carrier.
  • The README's key-encoding sentence and the felis link are updated to match.

The verify script touched the real daemon (separate commit)

scripts/pty_verify.py tried to isolate its daemon with a fresh XDG_RUNTIME_DIR and removed FELIS_SOCKET. felis's default socket is /tmp/felis.<uid>/daemon.sock, derived from the uid alone, so each run attached to the user's real daemon and created sessions in it.

The script now starts its own felis-daemon serve --socket /tmp/felis_tui_verify_*/daemon.sock, points felis-tui at it through FELIS_SOCKET, and stops only the process it started. It refuses to run without a daemon binary (second argument or $FELIS_DAEMON).

Verification

  • cargo fmt --all --check, cargo clippy --all-targets --all-features -- -D warnings, cargo test --all-features (24 passed), cargo deny check: all pass.
  • scripts/pty_verify.py target/debug <v0.1.0>/bin/felis-daemon: all 15 checks pass against a v0.1.0 daemon (typed commands, splits, truecolor, OSC 8, curly underline, OSC 66, Kitty images and placeholders). Typing now goes through InputMsg::Key, so the echoed marker also exercises the new key path. I confirmed with pgrep -x felis-daemon before and after the run that the user's daemon on /tmp/felis.<uid>/daemon.sock was neither touched nor signalled.
Pins every felis crate to the `v0.1.0` release tag on https://github.com/felis-terminal/felis (not on crates.io). The old pin was `105b0899`. Closes #3. That issue asked for a follow to `6da5620d`, and v0.1.0 contains that commit. ## What broke - **`felis_client_core::key_encode` is gone.** felis moved key encoding into the daemon, which owns the keyboard modes. felis-tui now translates each crossterm key into a `felis_protocol` `KeyEvent` and sends `InputMsg::Key`. It no longer encodes bytes from its shadow copy of the modes. The literal-prefix byte is still sent as raw `KeyBytes`. - **`env_base::fill_for_local` became `env_base::fill_for_carrier`.** - The README's key-encoding sentence and the felis link are updated to match. ## The verify script touched the real daemon (separate commit) `scripts/pty_verify.py` tried to isolate its daemon with a fresh `XDG_RUNTIME_DIR` and removed `FELIS_SOCKET`. felis's default socket is `/tmp/felis.<uid>/daemon.sock`, derived from the uid alone, so each run attached to the user's real daemon and created sessions in it. The script now starts its own `felis-daemon serve --socket /tmp/felis_tui_verify_*/daemon.sock`, points felis-tui at it through `FELIS_SOCKET`, and stops only the process it started. It refuses to run without a daemon binary (second argument or `$FELIS_DAEMON`). ## Verification - `cargo fmt --all --check`, `cargo clippy --all-targets --all-features -- -D warnings`, `cargo test --all-features` (24 passed), `cargo deny check`: all pass. - `scripts/pty_verify.py target/debug <v0.1.0>/bin/felis-daemon`: all 15 checks pass against a v0.1.0 daemon (typed commands, splits, truecolor, OSC 8, curly underline, OSC 66, Kitty images and placeholders). Typing now goes through `InputMsg::Key`, so the echoed marker also exercises the new key path. I confirmed with `pgrep -x felis-daemon` before and after the run that the user's daemon on `/tmp/felis.<uid>/daemon.sock` was neither touched nor signalled. 
The script isolated its daemon with a fresh XDG_RUNTIME_DIR and cleared
FELIS_SOCKET, but felis derives its default socket from the uid alone
(/tmp/felis.<uid>/daemon.sock) and reads no runtime-dir variable. A run
therefore attached felis-tui to the user's real daemon, created
sessions in it, and could autospawn over it.

The script now starts felis-daemon on a socket in its own temporary
directory, points felis-tui at it through FELIS_SOCKET, and stops the
process it started. It refuses to run without a daemon binary rather
than fall back to the default socket; felis-tui's build does not
produce one, so the binary is a second argument or $FELIS_DAEMON. The
directory lives under /tmp because a long $TMPDIR pushes the socket
path past the sockaddr_un limit.
chore(tui): follow felis to the v0.1.0 release
Some checks failed
ci / cargo fmt / clippy / test / deny (pull_request) Has been cancelled
Details
d492cae755
 
felis is now published as a tagged release on GitHub rather than as
revisions of the private repository, and its crates are not on
crates.io, so every felis crate is pinned to the v0.1.0 tag of
https://github.com/felis-terminal/felis. This supersedes the pending
follow to 6da5620d: v0.1.0 contains it.

Between the old pin and v0.1.0 felis moved key encoding into the
daemon, which owns the keyboard modes, and removed
felis_client_core::key_encode. felis-tui now sends each keystroke as an
InputMsg::Key event instead of bytes it encoded from its shadow copy of
the modes, so it can no longer encode against a mode the daemon has
already left. The literal prefix byte stays a raw KeyBytes send, since
it is already PTY input. env_base::fill_for_local became
fill_for_carrier, which takes the carrier the create travels over.

Closes #3
ci(tui): run on the x86_64-linux runner label
All checks were successful
ci / cargo fmt / clippy / test / deny (pull_request) Successful in 24s
Details
cd49780d6e
 
The Forgejo runners were re-registered with labels named after Nix
systems (nix -> x86_64-linux, macos -> aarch64-darwin), so jobs asking
for the old labels sit in the queue with no runner to pick them up.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
natsukium/felis-tui!5
No description provided.