CRIEW

This is the main documentation entry point for CRIEW. Use it for installation, configuration, sync and TUI workflow, patch handling, reply behavior, and local wiki maintenance.

Start here

• Install and Setup: Environment requirements, install paths, b4 resolution, and initial verification with criew doctor.
• Configuration: Default runtime paths, a working config example, the full supported config key set, and the behavior that depends on [imap], b4, and UI settings.
• Sync and TUI: Lore sync, IMAP sync, fixture-driven sync, and the main TUI navigation and background sync behavior.
• Patch and Reply: Patch-series actions, reply panel behavior, and the send-preview flow.
• Development: Repository validation, local wiki authoring commands, and the GitHub Pages publish path.
• Contribution: Issue workflow, branch and commit rules, pull request expectations, and conflict handling with rebase.

Project status

CRIEW is a Rust TUI for Linux kernel patch mail workflows. The current develop branch already covers the core local workflow:

• sync mail from lore.kernel.org
• sync a real IMAP INBOX through My Inbox
• browse threads and detect patch series
• apply or export patches through b4
• compose and send replies through git send-email

Current release tag: v0.0.2.

v0.0.1 is the first supported public baseline. From v0.0.1 onward, CRIEW supports only the CRIEW naming set: criew, ~/.criew/, criew-config.toml, criew.db, CRIEW_B4_PATH, and CRIEW_IMAP_PROXY. Courier-era names are intentionally unsupported.

Reference

• Keybindings: Current TUI keys by page and modal state, with suggested image slots for future screenshots.
• Repository README: Short English project entry page.
• Chinese README: Short Chinese project entry page.
• Configuration example: Canonical config keys, defaults, and comments.
• Architecture design: System layers, data model, and workflow boundaries.
• Reply format spec: Detailed reply construction and send behavior.
• CRIEW repository: Source, issues, workflows, and release tags.

Source of truth

• Operator workflow follows the wiki pages first.
• Config keys and defaults follow the configuration example and the runtime loader in the main repository.
• Reply behavior follows the reply format spec when a page gives only a high-level summary.
• Architecture and module boundaries follow the design document.

Built With

• email
• linux
• patch
• rust
• tui