[PATCH] hgext/win32chcp: switches the console into an encoding actually used (issue2926)

[Matt Mackall]

On Sat, 2011-07-30 at 04:52 +0700, Andrei Polushin wrote:
> 30.07.2011 1:43, Matt Mackall wrote:
> > On Sat, 2011-07-30 at 00:25 +0700, Andrei Polushin wrote:
> >> One problem still remains: `hg log | more' doesn't produce readable output on
> >> OEM console, because `more' resets the encoding itself, and it happens at an
> >> arbitrary time.
> > 
> > I'm skeptical of this theory. [...]
> > I think it's much more likely to be a race of some form. What I suspect
> > happens here is that there are three processes involved:
> > 
> > hg                more              console window
> >                                     start hg
> >                                     start more
> > set codepage
> > (send message to console)
> > start writing text
> >                   start reading text
> >                   start printing
> >                   (write directly to screen)
> >                                     receives chcp
> >                                     screws up display
> > 
> > I think introducing some delays in various places would test this
> > theory.
> 
> Your scenario seems to be wrong, because I'm getting some readable text at
> the beginning, while all further characters are unreadable.

Indeed.

> But you are right in a sense that it's a race condition. When I remove
> atexit.register(restoreconsoleencoding), it starts working just fine,
> I see readable characters until the end.

Yeah, that's a much more straightforward explanation of what's
happening.

> But the console codepage still needs to be restored somehow. It should be
> restored when `more' terminates, because `hg' terminates too early, while
> `more' is still running.

Hmmm, that's tricky.

Presumably redirection here is implemented with CreatePipe, which is a
special case of CreateNamedPipe, and we can maybe use something like

http://msdn.microsoft.com/en-us/library/aa365440%28v=VS.85%29.aspx

to watch for the process on the other end of the pipe to exit if stdout
isn't a "tty", which definitely adds to the overall 'hack level' here.

And, sadly, won't work for 'hg | sort | more'.

It's still unclear to me whether characters that are currently displayed
in a console are stored in a Unicode buffer (and thus would be stable
across chcp calls) or are stored in a byte buffer (and thus would all
get remapped across chcp calls) or whether some other mysterious method
is at play.

-- 
Mathematics is the supreme nostalgia of our time.