Input buffer doesn't show up in Windows terminal

[philiplinden]

[philiplinden]

Here's what gpt-5 said. Stashing it here to kickstart investigation when i come back to this

Got it — thanks for the screenshots. I see what’s happening:

✅ Observed Behavior

• Linux (EndeavourOS, Zsh, VSCode terminal, cargo run)

  • You can type into the REPL (hello from the buffer).
  • Input echoes correctly, but unrecognized commands trigger the parser error as expected.

• Windows (Win11, PowerShell, Windows Terminal, cargo run)

  • You also see the REPL intro.
  • Typing input (hello from the buffer) is not parsed properly. It’s treated as a single command buffer, then rejected.

---

🚧 Likely Root Causes

Differences between Linux and Windows terminals + Crossterm input handling:

1. Line Endings

   • Linux: newline = \n.
   • Windows: newline = \r\n.
   • If your parser splits only on \n, Windows input may appear as "hello from the buffer\r", making it fail.

2. Crossterm Raw Mode Differences

   • On Windows, Crossterm sometimes delivers input events differently (e.g., KeyCode::Enter comes with a \r).
   • If you’re reading via stdin().read_line() instead of event polling, you’ll get platform-specific behavior.

3. Buffer Flushing / Echo

   • PowerShell and Windows Terminal may buffer text differently than a Unix PTY.
   • On Linux, TTY input is line-buffered by the shell. On Windows, Crossterm needs explicit flushing.

4. Terminal Encoding

   • Windows console historically uses UTF-16 / codepages.
   • If Ratatui expects UTF-8 directly, you might see mismatches.

---

🔍 How to Trace the Difference

To confirm which of the above is hitting you:

1. Debug-print raw input events:

   use crossterm::event::{read, Event};
   
   fn main() {
       loop {
           let ev = read().unwrap();
           println!("{:?}", ev);
       }
   }

   Run this on both Linux and Windows, type the same input, and compare the event sequences.
   Look for KeyCode::Enter vs \r\n differences.

2. Log buffer contents before parsing

   println!("{:?}", buffer.as_bytes());

   If you see \r before \n on Windows, you’ve found the culprit.

3. Force normalize line endings
   Before parsing:

   let line = line.trim_end_matches(&['\r', '\n'][..]);

---

✅ Next Step Fix

• Normalize line endings (\r\n → \n) before feeding text into your parser.
• Or better, use Crossterm’s Event::Key events in raw mode rather than stdin().read_line(), since that avoids newline issues entirely.

---

👉 Do you want me to sketch a minimal Crossterm+Ratatui input loop that works consistently on both Linux and Windows, so you can drop it into your REPL prototype?

[philiplinden]

On windows: When I enable RatatuiPlugins in conjunction with the REPL (and it spawns an alternate screen) the input buffer is shown as I type.

One major difference between the Ratatui default context and ours is that Ratatui enables Kitty protocol. Maybe this is the difference?