Crate Overview

The public documentation focuses on three library crates. Each crate owns a different part of the terminal problem. Choose the lowest layer that manages the lifecycle your application does not want to manage itself.

tastty-driver
    active session control: wait, snapshot, inspect, signal

tastty
    managed PTY sessions: spawn, send, resize, exit

tastty-core
    parser-only terminal protocol state

tastty-core#

Use tastty-core when your application owns I/O. It gives you a VT parser, a virtual screen buffer, keyboard and mouse encoders, byte frame helpers, host profile configuration, and typed host replies. It does not open a PTY, spawn a process, run a reader thread, or decide where response bytes are written.

Good fits:

• replaying recorded terminal bytes into a Screen;
• embedding parser and screen state behind a custom transport;
• encoding keys, mouse events, bracketed paste, focus reports, or host replies;
• testing protocol behavior without spawning a child process.

Start in rustdoc with Parser, Screen, KeyEncoder, MouseEncoder, frame, HostProfile, and HostReply.

tastty#

Use tastty when you want a live child process in a PTY but do not want to wire the PTY, parser, input encoders, and exit handling yourself. It manages spawn, reader and writer threads, parser updates, input delivery, resize, shutdown, and exit status. With the default feature set, it can also render the screen as a ratatui widget.

Good fits:

• embedding a shell or terminal application inside a Rust application;
• reading current screen state from a managed session;
• sending raw bytes, typed keys, mouse events, paste frames, and focus reports;
• resizing the PTY and virtual screen together.

Start in rustdoc with Terminal, SessionOptions, CommandBuilder, TerminalSnapshot, and the re-exported protocol types from tastty-core.

tastty-driver#

Use tastty-driver when your code is actively controlling a terminal session rather than merely embedding one. It wraps a managed tastty session and exposes operations that match automation workflows: spawn, send, wait, snapshot, inspect, signal, terminate, and kill.

Good fits:

• waiting for text, regex matches, cursor positions, exits, or stable screens;
• taking plain-text, cell, style, scrollback, and metadata snapshots;
• sending mixed text, key, and raw-byte input sequences;
• applying process or process-group control through one session handle.

Start in rustdoc with Builder, Session, WaitCondition, Snapshot, InspectSnapshot, ScrollbackSnapshot, parse_input, InputSegment, Signal, and IoObserver.

Choosing a layer#

It is fine for application code to depend on a higher layer and still use lower-level re-exported types. Prefer a direct tastty-core dependency when you do not need PTY lifecycle at all; prefer tastty-driver only when waits, snapshots, inspection, or process control are part of the job.