Paste compatibility issue in Windows Terminal: Slow char-by-char insertion, per-character undo, and crashes on large pastes (bracketed paste related? #4037
Description
Description
Pasting text from the clipboard (Ctrl+V) into micro behaves inconsistently across Windows terminal emulators, with poor performance specifically in Windows Terminal and Cmder:
-
Affected terminals (poor behavior): Windows Terminal, Cmder
- Paste (CTRL-V) inserts slowly, character by character (visible "flowing" effect).
- Undo (Ctrl-Z) removes only one character at a time → requires repeated presses (or holding the key) to undo the full paste.
- For very large pastes (e.g., >70 lines of code): Insertion stops around line ~70 or later, long freeze, then micro crashes. The remaining lines are dumped line-by-line into the terminal (with error messages per line).
-
Unaffected terminals (good behavior): conhost.exe (default Windows Console), WezTerm, Tabby, Contour
- Paste is instant (text appears as a whole block).
- Ctrl+Z undoes the entire paste in one step.
This seems related to how bracketed paste mode (OSC 2004) is handled by Windows Terminal and Cmder. In well-behaved terminals, micro receives the paste as a single bulk operation. In Windows Terminal/Cmder, it arrives as individual keystrokes, resulting in poor performance, per-character undo, and overload/crash risk on large pastes.
Further research on similar editors
I've tested other CLI editors in Windows Terminal:
- Works well (instant paste, single-step undo): Microsoft's new
edit.exe(also written in Rust), nano, vim, nvim (minor delay but text intact and undo in one step). - Similar issues to micro: helix, fresh (slow/char-by-char insertion, per-char undo).
Relevant Microsoft Terminal issue: Feature request: Pasting with OSC 52 (for e.g. terminal-based editors) #9479
Key comment in my opinion: microsoft/terminal#9479 (comment)
"Edit uses the much less controversial 'write to clipboard' part of OSC 52. When you paste into edit from outside, it requests bracketed paste (so it knows when the paste begins and ends,) but it does not read the clipboard directly"
This suggests Windows Terminal deliberately avoids direct clipboard reading via OSC 52, and editors like edit.exe work around it by requesting bracketed paste markers without direct clipboard access.
To Reproduce (in Windows Terminal):
- Copy a large text block (e.g., 500+ lines).
- Paste with Ctrl+V in micro.
- Observe slow insertion and per-char undo.
- For crash: Use even larger text → freeze, crash, terminal dump.
Suggested solution
To improve compatibility with Windows Terminal (a popular choice), consider adopting the approach used by edit.exe:
- Request bracketed paste mode to detect start/end of paste events.
- Avoid direct clipboard reading if it's causing conflicts.
- This could allow treating pastes as bulk operations even in problematic terminals → instant insertion, single undo step, and no crashes.
Alternatively:
- Add a setting to disable/enable bracketed paste or force event batching.
Micro is already a fantastic lightweight editor with great defaults. Not being able to reliably use copy/paste in Windows Terminal makes it almost unusable there for any serious editing involving external text. Happy to provide more tests, logs, or help if needed. Thanks!
Environment
micro - Version: 2.0.15
- OS: Windows 11
- Terminal: Windows Terminal