| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
… and conversions The curses.ascii predicates and the ctrl() and unctrl() functions now accept a curses.complexchar, classifying it by its single character. ctrl() now returns a non-ASCII argument unchanged instead of masking it to a control character. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Documentation build overview2 files changed ± library/curses.ascii.html ± whatsnew/changelog.html |
Sorry, something went wrong.
|
It looks like this broke a few builds, notably Debian root, M1 macOS, and intel macOS. The latter two make me suspect that we're not installing curses on the GHA macOS builders :) |
Sorry, something went wrong.
|
Two of these buildbots are macOS with narrow curses build (which is hardly usable on UTF-8). See #154070. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
The curses.ascii predicates and the ctrl() and unctrl() functions now accept a curses.complexchar (the character-cell type added in gh-151757), classifying it by its single character. A complexchar that holds combining characters is not a single character and so matches no class.
ctrl() now returns a non-ASCII argument unchanged instead of masking it to a control character. There is no control character outside ASCII, and for many keys ctrl() on the real terminal is already a no-op (1, ', .) or emits irreproducible codes (KEY_BACKSPACE, KEY_RESIZE), so masking a non-ASCII code to a control character was meaningless.
ascii(), alt() and ismeta() are left unchanged: they remain meaningful only for 8-bit codes, as they already were for most non-ASCII characters.