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 <e...@gnu.org> wrote: >> Date: Tue, 3 May 2011 19:54:06 -0400 >> From: "E. S." <yields.falseh...@gmail.com> >> >> 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? >
