Supporing a subset of ANSI escape code on Windows
Are there those who need this?
#3 Updated by Luis Lavena almost 2 years ago
usa (Usaku NAKAMURA) wrote:
Are there those who need this?
A lot of libraries uses ANSI without offering non-colored (non-ANSI) alternatives.
Windows users needed to depend on win32console (back in 1.8x) and now external tools like ANSICON to workaround that but facing side-effects of it.
Having a basic subset of ANSI supported on Windows will be really helpful to reduce such issues.
What you see as drawback from this approach? It is considering redirected handles? (so ANSI is written properly?)
#6 Updated by Luis Lavena almost 2 years ago
vo.x (Vit Ondruch) wrote:
Seems like case for extension gem. But we'd been there already and it was failure. Not sure why this should be reintroduced and even directly into the Ruby. Let's keep focus on correct Ruby functionality and ANSI escape characters leave to terminals.
There is no single terminal on Windows that properly captures ANSI codes from executing programs. Terminal emulations like mintty do not work properly when mixing file descriptor between native Windows and posix-emulated ones (msys/cygwin)
External tools like ANSICON while solved the coloring issue introduced other issues, like hooking up Command Processor AutoRun which resulted in failure to spawn child processes or commands that dependent on cmd.exe
There is no easy way to provide this as an extension since the particular function that provides this is an internal part of Ruby replacement of IO management on Windows.
While working with RubyInstaller I've received several complains about these issues, the old win32console issues too and from time to time comparison with Node JS out-of-the-box ANSI coloring in the default terminal (cmd.exe)
I haven't had the time to analyze the impact (e.g. performance) on this, but based on previous experience with external tools and gems, I do think the impact on having this out-of-the-box is valuable.
In relation to "focus on correct Ruby functionality" I've worked on a rewrite of File.expand_path and the internal counterpart that cut Ruby startup time half the current versions.
Does that qualifies for correct Ruby functionality?
#8 Updated by Luis Lavena almost 2 years ago
nobu (Nobuyoshi Nakada) wrote:
Thank you Nobu,
I've run some naive tests against it, simulating a big and fast test suite and using minitest/pride to report colorful output:
The tests were performed from a RAMdisk where Ruby and the dependencies were installed. The numbers were taken after several runs (warm up cache)
From the report:
DEFAULT - No Pride or ANSI coloring was enabled.
PRIDE - minitest/pride enabled, causing ANSI sequences be shown in the terminal
ANSICON - pride enabled and running from a second (child) cmd.exe with ANSICON performing the ANSI processing
ANSI with patch - the latest patch provided by Nobu.
Results of both normal and redirected output were measured.
#10 Updated by Luis Lavena almost 2 years ago
Apply plans to apply this?
I've been using it locally with good results. Tools like Spinach, MiniTest and even Bundler worked as expected (with colors)
Here I did a naive attempt to benchmark the impact of this change:
And seems the overhead is way lower than using external tools like ANSICON.
#11 Updated by Nobuyoshi Nakada almost 2 years ago
- Status changed from Assigned to Closed
- % Done changed from 0 to 100
This issue was solved with changeset r35907.
Usaku, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.
win32: VT100 escape
- win32/win32.c (constat_apply): apply VT100 functions. [Feature #6418]
- win32/win32.c (constat_parse): parse some VT100 escape sequence.