Srihari Sriraman shared in

Public

Analyzed multiline paste issue and edge casesPublic

Agent

Model

Claude Opus 4.5 (latest)

Started

Jan 16, 11:01 PM

Messages32

Downloads0

Summary

In Progress

Understand
Reviewed code and tests related to paste handling.
Understand
Understand
Analyzed terminal bracketed paste mode behavior.
Understand
Understand
Summarized root cause of multiline paste bug.
Understand
Understand
Considered edge cases and brittleness concerns.
Understand

Analyze GitHub issue(s): https://github.com/badlogic/pi-mono/issues/767 read full comments

For each issue:

Read the issue in full, including all comments and linked issues/PRs.
For bugs:
- Ignore any root cause analysis in the issue (likely wrong)
- Read all related code files in full (no truncation)
- Trace the code path and identify the actual root cause
- Propose a fix
For feature requests:
- Read all related code files in full (no truncation)
- Propose the most concise implementation approach
- List affected files and changes needed

Do NOT implement unless explicitly asked. Analyze and propose only.

Let me look at the input handling code in the TUI package to understand how bracketed paste mode works:

Now let me look at the editor component to see how it handles paste events and enter key:

Let me look at how the terminal handles bracketed paste mode:

Now let me look at the tests for paste handling:

Now I have a complete picture. Let me summarize the analysis:

Analysis of Issue #767: Multiline paste on Windows triggers prompt submission

Bug Summary

When using pi on Git for Windows bash in Windows Terminal, pasting multiline text triggers prompt submission instead of inserting all lines.

Root Cause

Git for Windows bash (mintty) doesn't support or properly enable bracketed paste mode in some configurations.

How bracketed paste works:

Pi enables bracketed paste by writing \x1b[?2004h to stdout (in terminal.ts:start())
When the user pastes, a supporting terminal wraps the content in markers:
- \x1b[200~ (start) + pasted content + \x1b[201~ (end)
StdinBuffer detects these markers and emits a paste event
The Editor handles paste events specially, inserting all content without treating newlines as submit

What fails without bracketed paste support:

Terminal sends raw pasted content character-by-character
StdinBuffer splits input into individual sequences
\r (carriage return) is emitted as a single character

Editor's handleInput() matches \r as "enter" (submit action):

First line submits, remaining lines stay in editor

The user's test confirms this:

Git Bash for Windows: 6f 6e 65 0d 74 77 6f ("one\rtwo" with no markers)
WSL: 1b 5b 32 30 30 7e 6f 6e 65 0d 74 77 6f 1b 5b 32 30 31 7e (same content wrapped in bracketed paste markers)

Why Owner Can't Reproduce

Likely differences in:

Windows Terminal version
Git for Windows / mintty version
ConPTY settings
Terminal profile configuration

Newer versions may properly support bracketed paste via ConPTY.

Proposed Fix

Detect "implicit paste" in StdinBuffer.process() when:

A single stdin data event contains multiple characters
The content contains \r or \n
No bracketed paste markers are present

Changes to packages/tui/src/stdin-buffer.ts:

typescript

public process(data: string | Buffer): void {    // ... existing timeout clearing and string conversion ...
    // After converting to string, before existing logic:        // Detect implicit paste: multi-character input with newlines but no bracketed paste markers    // This handles terminals that don't support bracketed paste mode (e.g., some Git Bash configurations)    if (!this.pasteMode &&         str.length > 1 &&         (str.includes('\r') || str.includes('\n')) &&        !str.includes(BRACKETED_PASTE_START) &&         !str.includes(BRACKETED_PASTE_END)) {        // Emit as paste event to avoid treating newlines as submit        this.emit("paste", str);        return;    }
    // ... rest of existing logic ...}

Edge cases to consider:

Single \r from Enter key: length === 1, so won't trigger
Escape sequences with \r: rare, and typically don't arrive with other content in the same data event
Batched Kitty protocol events: don't contain \r or \n in the payload

Files Affected

packages/tui/src/stdin-buffer.ts (primary fix)
packages/tui/test/stdin-buffer.test.ts (add test case)
packages/tui/CHANGELOG.md (document fix)

Alternative Approaches

Document as unsupported: Note that Git for Windows bash may have paste issues and recommend WSL
Timing-based detection: Treat rapid character arrivals as paste (more fragile)
Check if bracketed paste is actually enabled: Query terminal and disable paste-specific handling if not supported (complex)

The proposed fix is the most robust and least intrusive.

isn't that brittle? think of edge cases

You're right, let me think through the edge cases:

False positives (would incorrectly treat as paste):

SSH/slow connections: Batched keystrokes like "abc\r" arriving together when user types then presses Enter
Fast typing + Enter: User types quickly, "hello\r" arrives in one data event
Programmatic stdin writes: Tests or automation sending multi-character input
Terminal response sequences: Some terminal queries return multi-byte responses

False negatives (would miss actual pastes):

Small pastes: Pasting just "a\nb" (4 chars) might not meet a size threshold
Paste arriving in chunks: Slow terminal might split paste across multiple data events

The fundamental problem: We cannot reliably distinguish between:

User pasting "one\rtwo"
User typing "one" then pressing Enter

If they arrive in the same data event, they're byte-identical.

Better assessment:

The owner cannot reproduce on the same claimed setup (Win 11, Git Bash, Windows Terminal). This suggests:

Version differences in Git for Windows, mintty, or Windows Terminal
User-specific terminal configuration disabling bracketed paste
ConPTY settings difference

Recommended approach:

Request more information on the issue:
- Exact Git for Windows version (git --version)
- Windows Terminal version
- Output of echo $TERM and echo $TERM_PROGRAM
- Any custom .bashrc or .minttyrc configuration
Document the workaround: Users can use Shift+Enter or Alt+Enter to insert newlines manually, which works regardless of bracketed paste support.
Document as known limitation: Some terminal configurations don't support bracketed paste. Recommend WSL or native Windows Terminal with PowerShell as alternatives.

Implementing a heuristic that could break normal Enter-to-submit behavior for everyone seems worse than the original issue affecting a subset of users with unusual terminal configurations.