mason@ANUBIS.UCHICAGO.EDU.UUCP (04/06/87)
There was quit a flurry about two weeks ago regarding gnu emacs on the sun
under X. I thought I would add what little we have learned to the fray:
When you run gnu emacs on a remote machine, displaying it on the local
terminal, there is no problem with emacs refreshing the screen correctly. If
you run it in an xterm window on your current machine with "xterm ${host}:0"
it also works fine. It doesn't seem to work fine directly.
These were results from 3.0. We are just now upgrading to 3.3 (as I write
this note) and hope the problem goes away. I just thought I would mention
this to help anyone else with 3.0 out there.
Regardless, it is surprising that changing the *Operating System* should
affect X in such an unobvious way. Thus, the question I would put forth is
not how to fix it but rather what could they have done to make this
difference in the first place?
Commentary is welcome. If you reply to me and there is sufficient discussion
I will summarize and post to the net. Regardless, I will summarize and
forward to anyone who responds.
Tony Mason
Univ. of Chicago, Dept. of C.S.
ARPA: mason@anubis.uchicago.edu
UUCP: ...ihnp4!gargoyle!masonrlk@ATHENA.MIT.EDU.UUCP (04/07/87)
The operating system DOES affect the behavior because of bugs in 4.2BSD. Specifically, SIGIO doesn't work properly on sockets, so asynchronous I/O gets blown out of the water. This isn't a problem if you start emacs from a remote machine, assuming the remote machine is running 4.3 or 4.2 with fixed socket code. It also won't be a problem if you're running it inside an xterm, because SIGIO works properly for terminals (see the fcntl(2) man page for this nonsense). However, an emacs started from a 4.2 machine with broken socket code will have these problems, as I know from experience. Robert^Z