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

[Yuya Nishihara]

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.

> 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.