tear_core/lib.rs
1//! `tear-core` — runtime logic for the tear multiplexer.
2//!
3//! Houses the session/window/pane state machine, PTY ownership
4//! (`portable-pty`), the layout engine, and the [`InProcess`]
5//! implementation of [`tear_types::MultiplexerControl`].
6//!
7//! ## Why this matters for the mado integration
8//!
9//! `mado` currently owns its own `pane.rs`/`tab.rs` with private
10//! state machines. At M5 those modules rebase onto
11//! `tear-core::InProcess` — both apps then share one source of
12//! truth for pane semantics. This crate's `InProcess` impl is the
13//! gravitational center the eventual rebase lands on.
14//!
15//! No daemon — those live in `tear-daemon`. Daemon-side composition
16//! wraps `InProcess` rather than reimplementing.
17
18#![forbid(unsafe_code)]
19
20pub mod blocks;
21#[cfg(feature = "engate")]
22pub mod engate_producer;
23pub mod inproc;
24pub mod pane_grid;
25pub mod pty;
26pub mod reap;
27pub mod recording;
28pub mod registry;
29
30/// Terminal-conformance rows against the `espelho` contract.
31///
32/// Lives in `src/` rather than `tests/` deliberately: it constructs and
33/// feeds a [`PaneGrid`] directly, and those verbs are `pub(crate)` so that
34/// no consumer outside this crate can mint a second authoritative grid (see
35/// the authority note on [`pane_grid::PaneGrid`]). An integration test links
36/// the crate as an external consumer and would therefore be denied the same
37/// access mado is — correctly. Being a unit test is what lets it keep
38/// testing the sealed surface.
39#[cfg(test)]
40mod espelho_conformance;
41
42pub use blocks::{Block, BlockExtractor};
43pub use inproc::InProcess;
44pub use reap::AllPanesExited;
45pub use pane_grid::{Cell, PaneGrid, PaneSnapshot};
46pub use recording::{PaneEvent, PaneRecording};