Home

CRIEW Wiki

This wiki 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

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.