| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Fix scrolling into input that has scrolled out of the buffer
There was a problem hiding this comment.
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 using COOKED_READ in the console anymore 🎉
Sorry, something went wrong.
| 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.
📝: This is relative to the origin of the buffer, not of the viewport. is this supposed to be viewport relative in the unix version?
Sorry, something went wrong.
|
|
||
| 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.
I suppose I don't totally understand how this is supposed to be used, but there is WriteConsoleInput which sounds similar
Sorry, something went wrong.
There was a problem hiding this comment.
This is specifically about push_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.
Sorry, something went wrong.
|
|
||
| self.__posxy = 0, 0 | ||
| self.__gone_tall = 0 | ||
| self.__offset = 0 |
There was a problem hiding this comment.
📝: the unix version also:
I'm pretty sure the console supported ?1h back to RS1, and bracketed paste as of microsoft/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.
Sorry, something went wrong.
There was a problem hiding this comment.
fwiw, this REPL is only activated on builds >= 10586
https://github.com/python/cpython/pull/119559/files#diff-45ae56fc192319dbdbe6aca3aa4c7abd31a4a5a38b775805249ba765c9476976R8
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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! ✨ 🍰 ✨ |
Sorry, something went wrong.
⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️Hi! The buildbot AMD64 FreeBSD14 3.x has failed when building commit 0d07182. What do you need to do:
You can take a look at the buildbot page here: https://buildbot.python.org/all/#builders/1232/builds/2462 Failed tests:
Summary of the results of the build (if available): == Click to see traceback logsTraceback (most recent call last):
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/libregrtest/single.py", line 181, in _runtest_env_changed_exc
_load_run_test(result, runtests)
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/libregrtest/single.py", line 138, in _load_run_test
regrtest_runner(result, test_func, runtests)
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/libregrtest/single.py", line 91, in regrtest_runner
test_result = test_func()
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/libregrtest/single.py", line 135, in test_func
return run_unittest(test_mod)
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/libregrtest/single.py", line 35, in run_unittest
raise Exception("errors while loading tests")
Exception: errors while loading tests
Traceback (most recent call last):
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/unittest/loader.py", line 396, in _find_test_path
module = self._get_module_from_name(name)
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/unittest/loader.py", line 339, in _get_module_from_name
__import__(name)
~~~~~~~~~~^^^^^^
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/test/test_pyrepl/test_windows_console.py", line 5, in <module>
from _pyrepl.windows_console import (
...<5 lines>...
)
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/_pyrepl/windows_console.py", line 30, in <module>
import ctypes
File "/home/buildbot/buildarea/3.x.opsec-fbsd14/build/Lib/ctypes/__init__.py", line 8, in <module>
from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
|
Sorry, something went wrong.
|
Buildbot failure related. Fixing now. |
Sorry, something went wrong.
(cherry picked from commit 0d07182) 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 commit 0d07182) 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 the 3.13 branch. |
Sorry, something went wrong.
Oh that for sure sounds like a us 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). |
Sorry, something went wrong.
| 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.
This merged as-is which is OK, but I wanted to chip in...
There is a minimal 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 set ENABLE_VIRTUAL_TERMINAL_PROCESSING and only fall back to basic console APIs if it fails. :)
Sorry, something went wrong.
There was a problem hiding this comment.
@DHowett sounds like an improvement we can still make! Care to PR this?
Sorry, something went wrong.
There was a problem hiding this comment.
I can try - at the very least, it would be a great opportunity for me to learn how to build and deploy Python 🙂
Sorry, something went wrong.
There was a problem hiding this comment.
@DHowett see here and let me know if anything's missing:
https://devguide.python.org/getting-started/setup-building/#windows
Sorry, something went wrong.
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>
| Back | FazBrowse Home | New Git URL |
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/