gh-124096: Enable REPL virtual terminal support on Windows #124119
Conversation
y5c4l3
requested review from
pablogsal,
lysnikolaou and
ambv
as code owners
|
All commit authors signed the Contributor License Agreement. |
y5c4l3
force-pushed
the
windows-vt
branch
2 times, most recently
from
42a48dc to
13bb26f
Compare
|
I'm just testing that indentation works when I paste code? That seems fine. As a side note, my Ctrl+Left and Ctrl+Right shortcuts (skip word) are broken now (possibly ever since the repl went in), and there's way too much ctypes for my liking in here - we should prioritise moving those to |
It can be fixed by adding two entries in the keymap. I'll later check whether there are other sequences that I missed before and commit as soon. |
y5c4l3
force-pushed
the
windows-vt
branch
5 times, most recently
from
3c1502a to
718110f
Compare
Signed-off-by: y5c4l3 <[email protected]>
To support virtual terminal mode in Windows PYREPL, we need a scanner to read over the supported escaped VT sequences. Signed-off-by: y5c4l3 <[email protected]>
Windows REPL input was using virtual key mode, which does not support terminal escape sequences. This patch calls `SetConsoleMode` properly when initializing and send sequences to enable bracketed-paste modes to support verbatim copy-and-paste. Signed-off-by: y5c4l3 <[email protected]>
|
@pablogsal @ambv @zooba
|
|
I just wanted to ask if there is something that I could do to help get this PR merged? It is currently not possible to paste a code snippet containing indentation into the REPL on Windows. I think this is a pretty serious limitation, because many tools (e.g. Visual Studio Code) rely on this mechanism to run selected code portions. I was hoping that this fix would make it into 3.13.1, but unfortunately this was not the case. Currently, this forces people on 3.13 to either disable the new REPL experience or switch to 3.12, both of which are very suboptimal workarounds (because the new REPL is great!). |
|
I second the need to get this merged as I am also impacted by the issue. |
|
Would this PR also work for VSCode's integrated terminal? There's a comment here: |
We need someone with windows knowledge to validate the PR. Unfortunately I don't have a windows machine or enough knowledge of the platform to validate the correctness. So if you can review the PR or get some windows expert to do we probably can continue landing it |
Lib/_pyrepl/windows_console.py
Outdated
|
|
||
| # Should make educated guess to determine the terminal type. | ||
| # Currently enable bracketed-paste only if it's Windows Terminal. | ||
| if 'WT_SESSION' in os.environ: |
There was a problem hiding this comment.
Hi! Maintainer of Windows Terminal (and/or Windows Console) here 🙂
In the general case, this is a fragile way to detect support. When Windows Terminal is used as the "default console host", it doesn't have a chance to inject its environment variables; this means that any sessions spawned outside of Terminal but which get launched into it will not try to enable bracketed paste.
It looks like the only thing this PR does with __vt_bracketed_paste is check whether it should enable it, and that it doesn't gate any other behavior.
Fortunately, bracketed paste is safe to enable on all console hosts on Windows that support VIRTUAL_TERMINAL_INPUT--even if they do not appear to support it. It'll just no-op when it's not available.
If you really want to check (later!) whether it got enabled, you can request a private mode report with DECRQM (\e[?2004$p); it will return \e[?2004;X$y where X is 1 if it is set and 2 if it is cleared. If it doesn't reply, the console host is too old to support mode queries.
You could also wait to see the first \e[200~ to determine whether it had been turned on for a given paste.
I've tapped in somebody from my team (Windows Terminal/Console) to have a look at this. Thanks! |
There was a problem hiding this comment.
Yea, I don't have any notes beyond the WT_SESSION thing that Dustin called out. That environment variable sucks. Terminal feature detection generally sucks, but that variable especially so.
If you blindly enable bracketed paste when VT input is supported, the worst thing that will happen is it works the same as it already does 😅
|
@y5c4l3, I hope you don't mind if I take over this PR, resolve the conflict and do the requested changes. (It looks like you're not active on GitHub right now.) |
There was a problem hiding this comment.
I've made the change to enable bracketed mode (if VT is supported).
I've tested on Windows 10 on Command Prompt (PS & cmd), VS Code embedded terminal (PS & cmd), and conhost.exe. Bracketed paste works on the first two (there is no confirmation dialog when pasting in multiple lines and the text is not auto-indented; pasting ends the F3 paste mode). On conhost.exe, bracketed paste works as before (dialog appears, text is auto-indented; F3 needs to be ended with another F3).
Ctrl+arrows, PgUp/PgDn, Alt+. still work.
(I found other behaviour that's surprising to me, including a bug, but no unintended changes to the status quo.)
|
I just wanted to thank everyone for helping get this PR merged! You are awesome! ❤️ |
| b'\x1b[17~]': 'f6', | ||
| b'\x1b[18~]': 'f7', | ||
| b'\x1b[19~]': 'f8', | ||
| b'\x1b[20~]': 'f9', | ||
| b'\x1b[21~]': 'f10', | ||
| b'\x1b[23~]': 'f11', | ||
| b'\x1b[24~]': 'f12', |
There was a problem hiding this comment.
I may not fully understand what's going on here, but I believe these encodings are incorrect due to the stray ].
| b'\x1b[17~]': 'f6', | |
| b'\x1b[18~]': 'f7', | |
| b'\x1b[19~]': 'f8', | |
| b'\x1b[20~]': 'f9', | |
| b'\x1b[21~]': 'f10', | |
| b'\x1b[23~]': 'f11', | |
| b'\x1b[24~]': 'f12', | |
| b'\x1b[17~': 'f6', | |
| b'\x1b[18~': 'f7', | |
| b'\x1b[19~': 'f8', | |
| b'\x1b[20~': 'f9', | |
| b'\x1b[21~': 'f10', | |
| b'\x1b[23~': 'f11', | |
| b'\x1b[24~': 'f12', |
Verified empirically with showkey -a; F6 and F12 pictured:
Issue: #124096