-
-
Notifications
You must be signed in to change notification settings - Fork 239
Paste compatibility issue in Windows Terminal: Slow insertion, per-char undo, and crashes on large pastes (bracketed paste workaround? #1218
Description
Pasting text from the clipboard (Ctrl+V) into Fresh 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 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 fresh editor crashes . The remaining lines are being dumped line-by-line into the terminal (with error messages per line).
- Paste (
-
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, Fresh 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 Fresh: micro, helix (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.
Fresh Version: 0.2.14
OS: Windows 11]
To Reproduce (in Windows Terminal):
- Copy a large text block (e.g., 100+ lines).
- Paste with Ctrl+V in Fresh.
- Observe slow insertion and per-char undo.
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.
Fresh is already great for instant large-file loading. Not being able to use copy / paste in Windows Terminal makes it almost unusable there. Happy to provide more tests or help with if needed.