Re: [h-e-w] issue with emacs and msvcrt getch(?)

[E. S.]

I think you're looking for "yes" to both questions, but I don't really
understand them, though that's probably because I don't really
understand how keystrokes make their way in to emacs.

I remember seeing a note somewhere about how python's getpass may put
the password prompt in the controlling command terminal if python is
running in IDLE*. Working along those lines I tried running emacs.exe
-Q from within a fresh cmd.exe but still had the same issue; my python
process in emacs hung until I killed it and typing away in to both
emacs (with point stuck where I left it in the python window) and the
cmd prompt did nothing.

I forgot to mention that I never even get the password prompt, which
in getpass is displayed with putch. It seems possible that if both
emacs and a subprocess are trying to read keystrokes that when only
one or the other is the consumer the other is left with nothing.
However, since the putch calls also fail to display anything, I think
this is less an issue of race conditions and more of something to do
with the low-level putch/getch/kbhit functions trying to communicate
with a console that either doesn't exist or isn't exposed by/connected
to emacs.

*I'm sticking with testing through python here because I think it's an
accessible and generic way of playing with this problem with little
overhead on top of the system api calls. Of course it may just so
happen that python and the db2 clp are two of only a few applications
that cause this behavior. ;)

On Wed, May 4, 2011 at 6:02 AM, Eli Zaretskii <address@hidden> wrote:
>> Date: Tue, 3 May 2011 19:54:06 -0400
>> From: "E. S." <address@hidden>
>>
>> A few months ago I tried running the db2 CLP from within emacs but it kept
>> hanging at the password prompt. I noticed similar behavior if, in python, I
>> used getpass.getpass(). That function works fine until I get to
>> msvcrt.getch(), which hangs in the python comint buffer (using
>> python-mode.el if anybody's interested). The getpass function loops like
>> this:
>>
>> while 1:
>>     c = msvcrt.getch()
>>     if c == '\r' or c == '\n':
>>         break
>>     ...
>>     else:
>>         pw = pw + c
>>
>> If I modify slightly and check just msvcrt.kbhit() in a loop to see if any
>> keystroke ever gets noticed, that function never returns true; I thought
>> that maybe it was just a getch thing. I can only guess that the db2 CLP is
>> also trying to make a low-level call to the windows api, but it's not
>> working correctly from within emacs (outside of emacs everything works
>> fine).
>
> Could this have something to do with the fact that Emacs has a
> separate input thread that wants to get keyboard inputs from the same
> console?  Could it be that Emacs and getch fight for the same inputs,
> and Emacs wins?
>