Unable to move cursor in ruby REPL pry or irb

[jburns24]

Environment

Win32NT 10.0.18362.0 Microsoft Windows NT 10.0.18362.0

Windows Terminal Version: 0.3.2171.0

Other Software

ruby 2.6.3p62 (2019-04-16 revision 67580) [x64-mingw32]
gems
pry (0.12.2)
irb (1.0.0)
both ruby REPLs

Steps to reproduce

In windows terminal start the ruby REPL pry or irb

type fooar then press the left arrow key to move the cursor back.

Expected behavior

You should be able to use the arrow keys to move around.

Actual behavior

The cursor is stuck at the end of the line.

I tested this behavior in other REPLs such as node, and python and this was not an issue. I then tested this behavior in other shells cmd and powershell (not in windows terminal) and this behavior was not reproducible.

Did some further testing and noticed this issue is a problem both in powershell and command when I start them in windows terminal, but it is not an issue when I run wsl in windows terminal.

[thomthom]

I'm seeing the same thing. When I use classic cmd then irb works fine. But when I have a cmd tab in Windows Terminal then I'm unable to use Backspace to erase characters in irb, unable to move the cursor and unable to use up/down arrow to navigate the irb history.

[jimfoltz]

Just FYI - you can use GNU Readline shortcuts.

https://www.gnu.org/software/bash/manual/html_node/Readline-Interaction.html#Readline-Interaction

[ramsay-vibes]

In mit-scheme REPL I have experienced the same (at least similar) issue, per the following screenshot where the following was typed: (cadr '1 '(2 3 4)) followed by left-arrow, right-arrow, up-arrow, down-arrow.

Unfortunately, the same issue occurs in the Ubuntu 18.04 LTS shell. So, not sure if this is a console issue or not.

Windows Version: [10.0.18362.295]
Terminal Version: [0.4.2382.0]

[zadjii-msft]

This feels like it might be related to #2642

[DHowett-MSFT]

It looks like other REPLs are susceptible to this as well. I wonder what common library they're using!

When fixed, validate:

• R
• irb
• pry

[zanecodes]

This appears to be related to rprichard/winpty#99, which suffers from the same problem, for what appears to be the same reason.

After digging into the rb-readline gem's source, I was able to confirm this by running the following code, once in PowerShell:

PS C:\Users\Zane> irb
irb(main):001:0> RbReadline.rl_read_key # following this, I press the left arrow key
=> "\xE0K"

and once in Windows Terminal Preview:

PS C:\Users\Zane> irb
irb(main):001:0> RbReadline.rl_read_key # following this, I press the left arrow key
=> "\x00K"

We can see that rb-readline only binds the arrow key handlers to the scancode sequences with the ENHANCED_KEY flag set ("\xE0" in hex, or "\340" in octal), so it simply doesn't handle these key sequences when they're missing the ENHANCED_KEY flag (as they seem to be when dispatched by winpty, or in this case, Windows Terminal Preview).

This could be considered a bug in rb-readline, but it doesn't seem to be under very active development, and since it also appears to be an issue in a number of other REPLs that do not use rb-readline, the solution for Windows Terminal Preview would seem to be to dispatch these key events with the ENHANCED_KEY flag set.

For those wanting to work around this in irb right now, you can do so by adding the following to your ~\.irbrc file:

# Workaround for https://github.com/microsoft/terminal/issues/2520
{
  "\000H" => :rl_get_previous_history, # Up
  "\000P" => :rl_get_next_history, # Down
  "\000M" => :rl_forward_char,  # Right
  "\000K" => :rl_backward_char, # Left
  "\000G" => :rl_beg_of_line,   # Home
  "\000O" => :rl_end_of_line,   # End
  "\000s" => :rl_backward_word, # Ctrl-Left
  "\000t" => :rl_forward_word, # Ctrl-Right
  "\000S" => :rl_delete, # Delete
  "\000R" => :rl_overwrite_mode # Insert
}.each do |keyseq, method|
  RbReadline.rl_bind_keyseq_if_unbound(keyseq, method)
end

[DHowett-MSFT]

Ah! Thanks for looking into this. That makes this a /dupe of #2397.

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!