-
-
Notifications
You must be signed in to change notification settings - Fork 302
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Many CSI sequences are ignored (discarded) in a prompt #1836
Comments
FWIW, the relevant code is ui.StylingFromSGR that is invoked by ui.ParseSGREscapedText Notice that quite a few of the SGR parameters documented at Wikipedia ANSI SGR parameters, including 21, are not handled by that function. Some of the known SGR parameters can be ignored because they are unlikely to ever be relevant for Elvish; e.g., SGR parameter 21 (the focus of this issue) is interesting in that its official meaning (double-underline) is different from its de-facto meaning (disable bold intensity). But there is a more general issue since none of the negative SGR parameters are currently supported. For example, Lines 91 to 96 in ce19c91
Here is an example:
Someone just needs to write the code and add appropriate unit tests. It might also be useful if a command similar to |
What happened, and what did you expect to happen?
We know that Elvish parses CSI sequences in a prompt into
Text
objects instead of writing raw output. It's cool, though introducing a defect. There are many CSI sequences (e.g., a\x1b[21m
sequence that typically means disabling bold intensity text style on several terminals) being ignored (discarded) during the parsing viaui.ParseSGREscapedText
. However, prompt engines like Oh My Posh, depend on utilizing these control sequences to construct flexible and awesome prompts. The drawback leads to incomplete or unexpected styled text rendered on a terminal.Output of "elvish -version"
0.21.0+official
Code of Conduct
The text was updated successfully, but these errors were encountered: