Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.4k
gh-111201: Support pyrepl on Windows#119559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Fix scrolling into input that has scrolled out of the buffer
zadjii-msft left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Hey so sorry for coming out of nowhere to leave notes on this. I'm super excited to see this land! I took a spin through this PR just to see if I could find anything egregious in here from a Windows Console standpoint, and nothing really popped out.
I obviously don't really know the pyrepl codebase closely, so my review probably isn't the most valuable. I left my own notes-to-self with a "📝:", mostly just for things I found confusing. Definitely feel free to ignore those.
overall I'd say: I'm super glad y'all aren't going to be usingCOOKED_READ
in the console anymore 🎉
info = CONSOLE_SCREEN_BUFFER_INFO() | ||
if not GetConsoleScreenBufferInfo(OutHandle, info): | ||
raise WinError(GetLastError()) | ||
return info.dwCursorPosition.X, info.dwCursorPosition.Y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
📝: This is relative to the origin of the buffer, not of the viewport. is this supposed to be viewport relative in the unix version?
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
return Event(evt="key", data=key, raw=rec.Event.KeyEvent.uChar.UnicodeChar) | ||
def push_char(self, char: int | bytes) -> None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I suppose I don't totally understand how this is supposed to be used, but there isWriteConsoleInput
whichsounds similar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This is specifically aboutpush_char
? I don't think it's actually used but it does seem to technically be public API surface. The unix version calls this on inputted chars.
self.__posxy = 0, 0 | ||
self.__gone_tall = 0 | ||
self.__offset = 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
📝: the unix version also:
- enables bracketed paste
- does a
smkx
(\x1b[?1h
) - gets the original size (to restore on exit?)
I'm pretty sure the console supported?1h
back to RS1, and bracketed paste as ofmicrosoft/terminal#15155 (not sure exactly where in Windows 11 that gets enabled)
You're probably fine continuing to not do them here, but they could maybe get added later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
fwiw, this REPL is only activated on builds >= 10586
https://github.com/python/cpython/pull/119559/files#diff-45ae56fc192319dbdbe6aca3aa4c7abd31a4a5a38b775805249ba765c9476976R8
Thanks for your notes@zadjii-msft! One problem we are still having I think is that resizing the terminal when there are wide Unicode characters such as emojis in many lines doesn't work (the characters don't get resposition after a resize makes the lines warp around and back to normal). This looks like it's a windows only problem because the unix terminal handles that correctly. I think@ambv or@DinoV may be able to provide more information. |
Unicode input and emojis work now. Amazing progress! I'm landing this, we can add further improvements like bracketed paste in future updates. Thanks,@DinoV! ✨ 🍰 ✨ |
bedevere-bot commentedMay 31, 2024
|
Buildbot failure related. Fixing now. |
(cherry picked from commit0d07182)Co-authored-by: Dino Viehland <dinoviehland@gmail.com>Co-authored-by: Anthony Shaw <anthony.p.shaw@gmail.com>Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit0d07182)Co-authored-by: Dino Viehland <dinoviehland@gmail.com>Co-authored-by: Anthony Shaw <anthony.p.shaw@gmail.com>Co-authored-by: Łukasz Langa <lukasz@langa.pl>
GH-119850 is a backport of this pull request to the3.13 branch. |
zadjii-msft commentedMay 31, 2024 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
Oh that for sure sounds like aus bug. We've been making pretty dramatic improvements to the unicode / emoji support over the last couple years, so I'm guessing you're seeing different behavior even depending on what version of Windows & the Terminal you're running. If you've got specific bugs on your tracker for those, point me at 'em, and I can get the team to double check them EDIT: derp I only read one mail, then replied to it before I saw#119559 (comment). |
if sys.platform != "win32": | ||
CAN_USE_PYREPL = True | ||
else: | ||
CAN_USE_PYREPL = sys.getwindowsversion().build >= 10586 # Windows 10 TH2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This merged as-is which is OK, but I wanted to chip in...
There is aminimal risk of cutting out terminals that would support pyrepl on earlier versions of Windows. The "most correct" (also most soapboxy, sorry!) way to determine support for this is to just try to setENABLE_VIRTUAL_TERMINAL_PROCESSING
and only fall back to basic console APIs if it fails. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@DHowett sounds like an improvement we can still make! Care to PR this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I can try - at the very least, it would be a great opportunity for me to learn how to build and deploy Python 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
@DHowett see here and let me know if anything's missing:
https://devguide.python.org/getting-started/setup-building/#windows
Co-authored-by: Anthony Shaw <anthony.p.shaw@gmail.com>Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Co-authored-by: Anthony Shaw <anthony.p.shaw@gmail.com>Co-authored-by: Łukasz Langa <lukasz@langa.pl>
Uh oh!
There was an error while loading.Please reload this page.
This adds Windows support for the new pyrepl.
Support is a mix of vt100 codes, enabling the vt100 codes on the Windows console, and Windows console APIs.
Minimum version required in Windows 10.
📚 Documentation preview 📚:https://cpython-previews--119559.org.readthedocs.build/