StarLAN login & emacs

[Leslie Mikesell]

In article <3378 at westmark.WESTMARK.COM> dave at westmark.WESTMARK.COM (Dave Levenson) writes:
>We run AT&T SysV/386r3.2.2 and the StarLAN UNIX Server 3.2.  When
>we run the kermit terminal emulation program on an MS-DOS client
>and log in to UNIX on the server, everything works find except the
>EMACS text editor.

>EMACS acts as if extra ^Z characters are being sent from our DOS
>client to the host, or sometimes as if other control characters are
>being sent.  It tries to save the buffer after every keystroke (as
>if we followed every keystroke with ^X^S).  After about fifteen
>seconds of inactivity, it suddenly exits to the UNIX shell, without
>saving the buffer, as if we had typed ^Zn.

The starlan tty emulation is streams based and handles a read()
with O_NDELAY set and no data available by returning a -1 (as
per STREAMS instead of 0 (as a tty would).  Emacs doesn't check.

The fix is to find the read() in keyboard.c and make it treat a
negative return as if it were 0.  This may be fixed in the current
version, though.  Rn will have the same problem, and there the
read() is hidden in a couple of macros.

>Other interactive software, such as vi, FACE, and such work just
>fine.  What is special about the way emacs talks to its terminal?

It sets O_NDELAY for non-blocking reads - you may have shells running
in other windows, etc.

>What is special about using Starlan in this way?  Emacs works
>find from the UNIX system console, or from terminals who log in
>over tty ports.

Setting the termio structure VMIN and VTIME fields to 0 to get
non-blocking reads doesn't work at all, and setting O_NDELAY
on the file descriptor makes reads return -1 when no data is
available.

BTW, if you haven't already noticed, you have to remove the "xt"
capability from the AT386 terminfo entry to make EMACS work right
on the 386 console.

Les Mikesell
  les at chinet.chi.il