REPL: Query libuv for virtual terminal support
#57132
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
topolarity
force-pushed
the
ct/REPL-ConsoleMode
branch
from
7e36b17 to
468be4f
Compare
topolarity
force-pushed
the
ct/REPL-ConsoleMode
branch
from
468be4f to
44a6644
Compare
topolarity
changed the title
ConsoleMode flags on Windows
topolarity
changed the title
libuv for virtual terminal support
topolarity
force-pushed
the
ct/REPL-ConsoleMode
branch
2 times, most recently
from
5ef9f00 to
37e0f88
Compare
topolarity
force-pushed
the
ct/REPL-ConsoleMode
branch
from
37e0f88 to
eaee38c
Compare
giordano
added
system:windows
topolarity
force-pushed
the
ct/REPL-ConsoleMode
branch
from
eaee38c to
3468c0e
Compare
vtjnash
reviewed
Jan 24, 2025
The query-and-restore logic here was pretty flawed:
- it had no way to guarantee when the "default" mode is available to
query, so it could easily save a "bad" mode
- it did not ensure / check whether the "default" mode is compatible
with the output generated by REPL (esp. ASCII escape codes / color)
- it persisted the "default" mode from pre-compilation to runtime,
causing JuliaLang#56073
`ENABLE_VIRTUAL_TERMINAL_PROCESSING` is the only flag that we're
agnostic about. It was added relatively recently (Windows 10 version
1511), and `libuv` has support to emulate its behavior when it's not
available natively.
Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and
ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control
sequences unconditionally.
Resolves JuliaLang#56073.
topolarity
force-pushed
the
ct/REPL-ConsoleMode
branch
from
3468c0e to
12e6584
Compare
|
This might technically be a minor abuse of the libuv API, which was apparently intended for the opposite case, where the terminal does not appear to support The alternative would be to do what libuv does and try to see if the feature flag "sticks" after a |
|
@vtjnash any concerns here before I merge? |
vtjnash
approved these changes
Feb 3, 2025
|
Removing label since this was merged before branching. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The query-and-restore logic here was pretty flawed:
With this PR,
ENABLE_VIRTUAL_TERMINAL_PROCESSINGis the only flag that we're agnostic about. It was added relatively recently (Windows 10 version 1511), andlibuvhas support to emulate its behavior when it's not available natively. We querylibuvdirectly to ask whether it is expecting to emulate, rather than measuring the console mode at some random point in time.Otherwise this PR resets ENABLE_PROCESSED_OUTPUT and ENABLE_WRAP_AT_EOL_OUTPUT always, since we output ASCII control sequences unconditionally.
Resolves #56073.