5bce369c4d
New style guide: # Headers, primary, and secondary text - **Headers:** Use `bold`. For markdown with various header levels, leave in the `#` signs. - **Primary text:** Default. - **Secondary text:** Use `dim`. # Foreground colors - **Default:** Most of the time, just use the default foreground color. `reset` can help get it back. - **Selection:** Use ANSI `blue`. (Ed & AE want to make this cyan too, but we'll do that in a followup since it's riskier in different themes.) - **User input tips and status indicators:** Use ANSI `cyan`. - **Success and additions:** Use ANSI `green`. - **Errors, failures and deletions:** Use ANSI `red`. - **Codex:** Use ANSI `magenta`. # Avoid - Avoid custom colors because there's no guarantee that they'll contrast well or look good on various terminal color themes. - Avoid ANSI `black`, `white`, `yellow` as foreground colors because the terminal theme will do a better job. (Use `reset` if you need to in order to get those.) The exception is if you need contrast rendering over a manually colored background. (There are some rules to try to catch this in `clippy.toml`.) # Testing Tested in a variety of light and dark color themes in Terminal, iTerm2, and Ghostty.
2.6 KiB
2.6 KiB
Rust/codex-rs
In the codex-rs folder where the rust code lives:
- Crate names are prefixed with
codex-. For examole, thecorefolder's crate is namedcodex-core - When using format! and you can inline variables into {}, always do that.
- Never add or modify any code related to
CODEX_SANDBOX_NETWORK_DISABLED_ENV_VARorCODEX_SANDBOX_ENV_VAR.- You operate in a sandbox where
CODEX_SANDBOX_NETWORK_DISABLED=1will be set whenever you use theshelltool. Any existing code that usesCODEX_SANDBOX_NETWORK_DISABLED_ENV_VARwas authored with this fact in mind. It is often used to early exit out of tests that the author knew you would not be able to run given your sandbox limitations. - Similarly, when you spawn a process using Seatbelt (
/usr/bin/sandbox-exec),CODEX_SANDBOX=seatbeltwill be set on the child process. Integration tests that want to run Seatbelt themselves cannot be run under Seatbelt, so checks forCODEX_SANDBOX=seatbeltare also often used to early exit out of tests, as appropriate.
- You operate in a sandbox where
Before finalizing a change to codex-rs, run just fmt (in codex-rs directory) to format the code and just fix (in codex-rs directory) to fix any linter issues in the code. Additionally, run the tests:
- Run the test for the specific project that was changed. For example, if changes were made in
codex-rs/tui, runcargo test -p codex-tui. - Once those pass, if any changes were made in common, core, or protocol, run the complete test suite with
cargo test --all-features.
TUI style conventions
See codex-rs/tui/styles.md.
TUI code conventions
- Use concise styling helpers from ratatui’s Stylize trait.
- Basic spans: use "text".into()
- Styled spans: use "text".red(), "text".green(), "text".magenta(), "text".dim(), etc.
- Prefer these over constructing styles with
Span::styledandStyledirectly. - Example: patch summary file lines
- Desired: vec![" └ ".into(), "M".red(), " ".dim(), "tui/src/app.rs".dim()]
Snapshot tests
This repo uses snapshot tests (via insta), especially in codex-rs/tui, to validate rendered output. When UI or text output changes intentionally, update the snapshots as follows:
- Run tests to generate any updated snapshots:
cargo test -p codex-tui
- Check what’s pending:
cargo insta pending-snapshots -p codex-tui
- Review changes by reading the generated
*.snap.newfiles directly in the repo, or preview a specific file:cargo insta show -p codex-tui path/to/file.snap.new
- Only if you intend to accept all new snapshots in this crate, run:
cargo insta accept -p codex-tui
If you don’t have the tool:
cargo install cargo-insta