Xref: utzoo comp.emacs:7078 gnu.emacs:1817 gnu.emacs.bug:1271
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!rutgers!att!dptg!mtune!dwp
From: dwp@mtune.ATT.COM (David Preisler)
Newsgroups: comp.emacs,gnu.emacs,gnu.emacs.bug
Subject: Problem with GNU Emacs hanging solved
Message-ID: <8131@mtune.ATT.COM>
Date: 28 Oct 89 01:01:27 GMT
Organization: AT&T ISL Middletown NJ USA
Lines: 45
Keywords: GNU Emacs 18.54  3b2 System V


Problem:
/-----
|
|  On a 3b2 700 under sVr3 I've got GNU Emacs 18.54 built [ HAVE_PTY defined ],
| but I find that it does not work properly through a DataKit VC.  I do find
| however, that when run through a direct port it appears to work properly.
|
| Symptoms:  The screen opens up correctly, but typed chars do not appear on 
| the screen.  Ctrl chars are also generally ignored.  Emacs will beep at ^g 
| and ^z, and occasionally it will produce the unsupported operation message 
| ( autosave, abort- core dump ).
|
|
\-----



SOLUTION:

+------
|
| Date: Fri, 27 Oct 89 19:52:41 EDT
| From: Jonathan Simon Kay <@JHMAIL.HCF.JHU.EDU:kay@JHUNIX.BITNET>
| Subject: Emacs pty problems
| To: dwp@mtune.ATT.COM
|
|     
| Simple.  It's a bug in the pty device driver.  Seems the master end of
| the ptys don't support nonblocking I/O.  So emacs is blocked - it only
| responds to characters bound to signals in the tty (that's why ^G
| produces a response).  The easiest fix is to give up on ptys.  If you
| really want 'em, I'll send you my workaround code.  What it does is
| starts up a whole new process that does the waiting instead of emacs
| and sends what it gets to emacs via a pipe, which does support
| nonblocking I/O.  Very inefficient and kinda slow, but it does work.
|     
|     
|                                        Jon Kay
+-----     

Thanks,
david

The Distributed Programming Tools Group: "Don't Panic!"