[PATCH 1 of 3] windows: add a method to enable ANSI color code processing on Windows 10

[FUJIWARA Katsunori]

At Thu, 25 May 2017 00:57:06 +0900,
Yuya Nishihara wrote:
> 
> On Tue, 23 May 2017 23:35:24 +0900, FUJIWARA Katsunori wrote:
> > > +def enablevtmode():
> > > +    '''Enable virtual terminal mode for the associated console.  Return True if
> > > +    enabled, else False.'''
> > > +
> > > +    ENABLE_VIRTUAL_TERMINAL_PROCESSING = 0x4
> > > +
> > > +    # Query stderr, like termsize().  Either stdout or stderr will work.
> > > +    handle = _kernel32.GetStdHandle(_STD_ERROR_HANDLE) # don't close the handle
> > 
> > Current color.py implementation uses only STD_OUTPUT_HANDLE in order
> > to initialize for colorization, and redirection of stdout disables
> > colorization itself.
> > 
> > Therefore, GetConsoleMode() on STD_OUTPUT_HANDLE seems consistent with
> > color.py, at least now, even though win32.termsize() uses
> > STD_ERROR_HANDLE for safety at redirection of stdout.
> > 
> > BTW, I'm planning to examine both stdout/stderr for console
> > information on Windows (termsize, colorization, and so on) for strict
> > detection, because only stderr might be redirected at runtime. Of
> > course, it should be very rare case, though :-)
> 
> I was thinking if the use of STD_OUTPUT_HANDLE in color.py could be replaced by
> get_osfhandle(ui.fout.fileno()). The current win32 color implementation looks
> really ugly.

I'll do so in the future, if STD_*_HANDLE definitions still exist at
that time ! :-)

> > Is there any reason to place this implementation in win32.py, and to
> > use it via util.py proxy ?
> > 
> > color.py already has win32 specific code path, and it seems better to
> > place this implementation in color.py, IMHO. This can centralize
> > colorization specific logic into color.py. Introducing empty
> > enablevtmode() into posix.py seems redundant, too.
> 
> I'd rather move all win32 API calls to win32.py. Perhaps it's okay to import
> win32.py directly. I think they are in color.py because it was an extension.

Putting both of all win32 API calls at the end of color.py, and new
ANSI color handling code into win32.py seems good.

I dislike only splitting color related win32 API calls into color.py
and win32.py.

-- 
----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp