You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we think about making TruShell a fast, robust, general-purpose shell that can legitimately compete with Bash, I want to pitch a core architectural shift.
Instead of writing low-level terminal infrastructure, syntax parsing, and prompt formatting logic from scratch which can quickly trap an open-source project in an endless loop of edge cases. I propose we build TruShell as a high-performance orchestrator shell. The strategy is to outsource the heavy lifting to existing production-grade Rust crates built by core terminal organizations (like Nushell, Starship, and WezTerm), allowing us to keep our codebase remarkably lean and fast.
Here is the modular stack I’d like us to discuss:
UI & Line Editing: Drop in Nushell's reedline crate. This instantly gives TruShell multi-line editing, visual tab-completion dropdowns, and Fish-like history auto-suggestions out of the box without us managing raw cursor positions.
Text Tokenization: Use shlex to handle Bash-style quotes, whitespace splitting, and escapes cleanly.
Context & Telemetry: Follow the Starship playbook. Instead of executing slow, blocking shell child processes to fetch git status or system stats, we can run crates like gix (Gitoxide) and sysinfo concurrently across a thread pool using rayon. This keeps prompt rendering times at single-digit milliseconds.
Cross-Platform PTY Layer: Outsource process execution to WezTerm's portable-pty crate so interactive programs (vim, htop, etc.) render perfectly across Linux, macOS, and Windows without platform-specific bloat.
Grammar & Highlighting: Leverage tree-sitter for incremental parsing so we get rock-solid code block awareness and real-time syntax highlighting as users type.
By focusing TruShell on stitching these enterprise-grade modules together, we don't reinvent the wheel. We inherit the modern UX benefits of newer shells, match the execution parity of Bash, and keep our actual development focused on TruShell's unique core engine layout.
Would love to hear your thoughts on this approach. Are there any bottlenecks you see with these crates, or any other standalone micro-crates we should consider introducing into the core architecture?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hey everyone,
As we think about making TruShell a fast, robust, general-purpose shell that can legitimately compete with Bash, I want to pitch a core architectural shift.
Instead of writing low-level terminal infrastructure, syntax parsing, and prompt formatting logic from scratch which can quickly trap an open-source project in an endless loop of edge cases. I propose we build TruShell as a high-performance orchestrator shell. The strategy is to outsource the heavy lifting to existing production-grade Rust crates built by core terminal organizations (like Nushell, Starship, and WezTerm), allowing us to keep our codebase remarkably lean and fast.
Here is the modular stack I’d like us to discuss:
reedlinecrate. This instantly gives TruShell multi-line editing, visual tab-completion dropdowns, and Fish-like history auto-suggestions out of the box without us managing raw cursor positions.shlexto handle Bash-style quotes, whitespace splitting, and escapes cleanly.gix(Gitoxide) andsysinfoconcurrently across a thread pool usingrayon. This keeps prompt rendering times at single-digit milliseconds.portable-ptycrate so interactive programs (vim,htop, etc.) render perfectly across Linux, macOS, and Windows without platform-specific bloat.tree-sitterfor incremental parsing so we get rock-solid code block awareness and real-time syntax highlighting as users type.By focusing TruShell on stitching these enterprise-grade modules together, we don't reinvent the wheel. We inherit the modern UX benefits of newer shells, match the execution parity of Bash, and keep our actual development focused on TruShell's unique core engine layout.
Would love to hear your thoughts on this approach. Are there any bottlenecks you see with these crates, or any other standalone micro-crates we should consider introducing into the core architecture?
All reactions