Xref: utzoo comp.emacs:6484 gnu.emacs:1234 comp.unix.ultrix:1194
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!agate!ucbvax!tut.cis.ohio-state.edu!rpi!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.emacs,gnu.emacs,comp.unix.ultrix
Subject: Re: DS3100, Gnu-emacs, and X11
Message-ID: <8412@batcomputer.tn.cornell.edu>
Date: 16 Jul 89 01:05:24 GMT
References: <10094@boulder.Colorado.EDU>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Distribution: na
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 27

In article <10094@boulder.Colorado.EDU> hartzell@spike.colorado.edu (George Hartzell) writes:
>I am using Gnu-emacs 18.54 on a color DECstation 3100 running
>UWS2.1/3.1. [...] It seems to work fine, but after a couple of minutes of
>work something weird happens.  The most noticable manifestation is
>that key-click gets turned on, and (less reproducibly) certain
>keystrokes start disappearing.  The missing keystrokes *might* be
>being interpreted as the "compose key" somehow; the first key stroke
>is ignored, the second generates a beep, and the third is recognized.

How did you compile it?  In particular, what optimization level?  Does
this still happen if you log in from a terminal (or telnet or decnet)
(i.e. is it specific to the X11 interface)?

I had a similar problem, though it only seemed to manifest itself in the
minibuffer (usually when I was doing an i-search), but only if I was using
the X11 interface.  Logging in via DECnet it worked fine.  So I switched 
from -O to -g, and it worked fine.  Eventually, I isolated it to an 
optimization bug compiling x11term.c, but couldn't track it down any further 
(I normally have to see assembly to figure these things out, but the pmax 
assembler is still beyond my ken).  So I recompiled with -O on everything 
but x11term.c (which, yuck, I compiled by hand without -O), and everything 
seems to work.  I suppose we (meaning the computer group here--I'm just a
user) should submit an SPR on this, or something, but we haven't yet.
Anyway, this may be your problem too.

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell U.