dko@calmasd.GE.COM (Dan O'Neill) (03/23/88)
On terminals, whose physical connection is to a DEC LAT box and then to our Pyramid system, GNU Emacs will not start up. However, emacs runs correctly over any other type of connection. Emacs is started in a normal fashion and the LAT returns several control-G's, followed by the question "Auto-save (y or n)?", and finally the question "Core dump (yes or no)?". We have been able to determine that the control-G's are being sent out by the LAT to the terminal as an indication of "data overrun" or "buffer full". This is not a flow control problem with the terminal that (set-input-mode xx xx) will handle, but rather something to do with cbreak vs. raw mode. I am stuck. If any of you can give me some pointers as to where to look or how to locate the section in Emacs which is responsible for terminal initialization I will be most grateful. One final note, the version of Unipress Emacs we have on the Pyramid does not experience this problem. We are unable to switch over to GNU Emacs until we can run it over the DEC LAT boxes. -- Dan O'Neill dko@calmasd.GE.COM GE Calma R&D ...!sdcsvax!calmasd!dko
dko@calmasd.GE.COM (Dan O'Neill) (03/25/88)
In a previous message I described a problem in running a unix version of GNU Emacs over a DEC LAT box to a tty. The DEC LAT box would complain about something, send out a stream of ^G's and thus force GNU Emacs to core dump. This is not a problem for VMS versions of GNU Emacs. As it turns out, this was a hardware configuration problem. The solution is to set the parameters on the LAT box connected to the unix box (in our case a Pyramid machine) as follows: old setting correct setting Character size: 7 bits 8 bits Parity: Even None The LAT will now transfer all of the data between the terminal and the host. -- Dan O'Neill dko@calmasd.GE.COM GE Calma R&D ...!sdcsvax!calmasd!dko
jimc@iscuva.ISCS.COM (Jim Cathey) (03/29/88)
In article <2698@calmasd.GE.COM> dko@calmasd.UUCP (Dan O'Neill) writes: >In a previous message I described a problem in running a unix version >of GNU Emacs over a DEC LAT box to a tty. The DEC LAT box would >complain about something, send out a stream of ^G's and thus force GNU >Emacs to core dump. This is not a problem for VMS versions of GNU Emacs. > >As it turns out, this was a hardware configuration problem. The >solution is to set the parameters on the LAT box connected to the unix >box (in our case a Pyramid machine) as follows: > > old setting correct setting > >Character size: 7 bits 8 bits >Parity: Even None > > >The LAT will now transfer all of the data between the terminal and the >host. Possibly it wasn't sending ^G at all. One of our 18.48 builds on a SYSV style system was messed up in that meta-DEL generated a ^G (according to emacs). What was happening was that VINTR and VQUIT were set to 0xFF, which caused a SIGINT and/or SIGQUIT to be sent on m-DEL. SIGINT/SIGQUIT are interpreted as ^G (abort) by emacs, so perhaps you were having something similar happen (parity widgets being interpreted as meta-whatevers), or other sources of SIGQUITs. The SVID I've seen recommends that you set VINTR to 0xFF or other 'illegal' character when you don't want SIGINT rather than providing a real 'off' mechanism. Humpph, illegal indeed! +----------------+ ! II CCCCCC ! Jim Cathey ! II SSSSCC ! ISC Systems Corp. ! II CC ! TAF-C8; Spokane, WA 99220 ! IISSSS CC ! UUCP: uunet!iscuva!jimc ! II CCCCCC ! (509) 927-5757 +----------------+ "With excitement like this, who is needing enemas?"