egisin@orchid.UUCP (08/12/87)
When using gnuemacs (18.47) with Xsun (10.4) on a Sun 3/50 (Sun OS 3.1), the window is not updated after certain commands (for example ^X^F) until I type another command. We also have emacs on a Vax (4.3 BSD), and X on a vaxstation (Ultrix 2.0). I tryed all four combinations of X server and emacs, it only is broken when both are on a Sun. Any fixes for this?
hodges@VIOLET.BERKELEY.EDU (08/12/87)
When using gnuemacs (18.47) with Xsun (10.4) on a Sun 3/50 (Sun OS 3.1), the window is not updated after certain commands (for example ^X^F) until I type another command. Any fixes for this? I have observed similar problems with an earlier gnu, 18.45 I think. The problems go away with Sun OS 3.2. I am now using 18.46 on a sun under os 3.2. A work-around is to start gnu from an xterm window (e.g., the console window) by directly entering the start-up command: %emacs <parameters> & or to put the startup command in a file and source the file: %source emacs-startup For some unknown reason, it does not work to put execute permissions on the startup file and execute it directly from xterm (you get the behavior referred to in the query), and there doesn't seem to any way to automate starting up emacs in .cshrc.
rlk@think.COM (Robert Krawitz) (08/13/87)
In article <8708121652.AA04634@violet.berkeley.edu> hodges@VIOLET.BERKELEY.EDU writes:
]
] When using gnuemacs (18.47) with Xsun (10.4) on a Sun 3/50 (Sun OS 3.1),
] the window is not updated after certain commands (for example ^X^F)
] until I type another command.
]
] Any fixes for this?
Yes -- in the kernel. The kernel does not handle SIGIO properly on
sockets in many versions of 4.2. I have the same symptoms on the Sun
3/140 that I'm using right now. Nothing to do but to live with it for
the time being. The fix was sent in to Berkeley and DEC, and I know
that it works properly under 4.3 and Ultrix 1.1 and 1.2, and I haven't
tried 2.0 but I'd be surprised if even DEC could re-break it :-)
It won't happen every time. But when you visit a particularly large
file, there's a particularly good chance of it happening. Rmail is
the worst "offender" in this regard.
] I have observed similar problems with an earlier gnu, 18.45 I
]think. The problems go away with Sun OS 3.2. I am now using 18.46 on
]a sun under os 3.2.
] A work-around is to start gnu from an xterm window (e.g., the
]console window) by directly entering the start-up command:
]
]%emacs <parameters> &
Which doesn't necessarily work, and in any case can't work for
commands you invoke inside emacs.
]or to put the startup command in a file and source the file:
]
]%source emacs-startup
]
] For some unknown reason, it does not work to put execute
]permissions on the startup file and execute it directly from xterm
](you get the behavior referred to in the query), and there doesn't
]seem to any way to automate starting up emacs in .cshrc.
You don't want to start up emacs from your .cshrc, anyhow. From your
.login, maybe. Since you very likely use xinit on a sun, you might as
well start it up that way.
Robert^Z