Skip to content

Conversation

@murataslan1
Copy link

Description

When stdin is closed (EOF), prompt() was outputting an extra newline compared to confirm() and alert(). This inconsistency was caused by rustyline's internal terminal handling.

Root Cause

  • prompt() uses op_read_line_prompt() which internally uses rustyline's Editor::readline_with_initial
  • confirm() and alert() use readLineFromStdinSync() which is a manual byte-by-byte read
  • When rustyline receives EOF, it outputs a newline as part of its terminal restoration

Fix

This PR adds an ANSI escape sequence (\x1b[1A) to move the cursor up after EOF is received, counteracting the unwanted newline that rustyline outputs.

Testing

# Before fix - note the newline after 'Prompt'
$ echo '' | deno eval 'prompt()'
Prompt 
$

# After fix - no extra newline (matches confirm behavior)
$ echo '' | deno eval 'prompt()'
Prompt $

Fixes #22956

Copilot AI review requested due to automatic review settings January 1, 2026 20:51
@CLAassistant
Copy link

CLAassistant commented Jan 1, 2026

CLA assistant check
All committers have signed the CLA.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes an inconsistency where prompt() outputs an extra newline after EOF compared to confirm() and alert(). The fix adds an ANSI escape sequence to move the cursor up one line to counteract the newline that rustyline outputs during EOF handling.

  • Adds cursor positioning logic to handle rustyline's EOF behavior
  • Maintains consistency with confirm() and alert() terminal output
  • Includes documentation comment linking to the related issue

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

// Move cursor up to counteract the newline that rustyline outputs on EOF.
// This makes prompt() behave consistently with confirm() and alert().
// See: https://github.com/denoland/deno/issues/22956
eprint!("\x1b[1A\x1b[{}C", editor.helper().map_or(0, |_| 0));
Copy link

Copilot AI Jan 1, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The expression editor.helper().map_or(0, |_| 0) always evaluates to 0 because the closure ignores its argument and returns 0 regardless of whether the helper exists. This makes the horizontal cursor movement sequence \x1b[0C effectively a no-op. If the horizontal positioning is not needed, consider removing it entirely and using just eprint!("\x1b[1A"). If it is needed, the logic should be corrected to calculate the appropriate column position.

Suggested change
eprint!("\x1b[1A\x1b[{}C", editor.helper().map_or(0, |_| 0));
eprint!("\x1b[1A");

Copilot uses AI. Check for mistakes.
@murataslan1 murataslan1 force-pushed the fix/prompt-newline-on-eof branch 2 times, most recently from 5b1d6d0 to b421b4c Compare January 1, 2026 21:05
When stdin is closed (EOF), prompt() was outputting an extra newline
compared to confirm() and alert(). This inconsistency was caused by
rustyline's internal terminal handling.

This fix adds an ANSI escape sequence to move the cursor up after
EOF is received, counteracting the unwanted newline.

Fixes denoland#22956
@murataslan1 murataslan1 force-pushed the fix/prompt-newline-on-eof branch from b421b4c to bd58e71 Compare January 1, 2026 22:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Closing stdin causes prompt() to output a newline, in contrast to confirm()

2 participants