[PATCH] setup: use unbuffered I/O in py2exe

[Sergei Nosov]

Thx for pointing this out, Matt.

AFAIK, Emacs on Windows really does "only pretend to be a console".

I'll look into the issue from that point.
--
Best regards,
       Sergei Nosov


On Fri, Aug 3, 2012 at 11:11 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2012-08-02 at 17:30 +0400, Sergei Nosov wrote:
>> # HG changeset patch
>> # User Sergei Nosov <sergei.nosov at gmail.com>
>> # Date 1343913078 -14400
>> # Node ID 57f6129f1be240151236886fca26e5106ff01c11
>> # Parent  23b247234454c945ff0b907dd6195a385c134468
>> setup: use unbuffered I/O in py2exe
>
>> If used in custom shell (e.g. GNU Emacs shell) output of any command
>> was printed AFTER the command execution. Now it's printed DURING the
>> command execution.
>
> This is definitely not the right fix: I/O buffering is a good thing,
> generally.
>
> It's standard behavior for apps to use unbuffered I/O when run on a
> console/tty/pty and to automatically enable buffering when writing to
> files or pipes. So either Emacs on Windows is pretending to be a console
> but redirecting I/O through pipes or it's somehow foiling Python's
> console detection. In either case, it's almost certainly breaking other
> Mercurial assumptions too.
>
> I'm pretty sure the problem is with the MSYS Posix emulation layer,
> which apparently doesn't really support pty devices, which are key to
> properly implementing things like Emacs' shell. Googling for things like
> "msys pty broken" gives things like this:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=27414138
>
> This puts this issue solidly in the realm of "not our problem".
>
> You should instead try to arrange that PYTHONUNBUFFERED is set in your
> "shell".
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>