rich@ria.ccs.uwo.ca (Rich Jones) (03/15/90)
We have a vax 6430 running vms 5.2. On this machine, we use GNU emacs 18.47.11. Our problem is that when a user of a vt100 terminal (or an emulator of this) holds the right (or left) arrow key down to advance through the text in a file, emacs seems to loose track of what it is supposed to do with the sequence (^[[C) and starts interpreting the characters individually. Sequences of [C may be inserted into the text or the user is put into the expression-evaluation area, or both. Here is part of a report from our communications/network group: > We tried one timing experiment. If every character in the sequence ^[[C > arrives in a separate packet things work ok. We haven't tried groups > of two. In the example that we sent you the problem was forced by > having the terminal auto-repeat the forward cursor. At other times it > will happen on seemingly random key strokes fairly separated from > others (always multi-character keystrokes, however). On an idle (or > fairly idle) system last Saturday the problem seemed much worse than > the time we ran the trace. Things seemed to get worse sometime in > January. Perhaps the latest multinet, perhaps the upgrade to 6430, > perhaps even the upgrade to vms5.1 (or what-ever we are currently at). > > It is 0752 in the morning here (not much going on -- monitor system > shows 1 or 2% out of 300% for cpu) and I just tried to run emacs and > without using the auto-repeat saw at least 3 lost character problems > within a few seconds of slow tapping of the various cursor keys. I > think that this problem must be related inversely to load. Is that a > clue? Through much testing, we have discovered that the problem seems to be in emacs, not in the method used to connect to the VMS machine (our first guess). It fails on LAT, Multinet IP, and direct wire connections to the system (all running at 9600 bps). Has any other site been having this problem? Have you found a solution? I have been testing GNU emacs 18.55, but the same problems exist. Running at a slower baud rate is not an option, neither is getting rid of all vt100's and their emulators. Getting users to not use their arrow keys is also not feasible. One suggestion that's been given to us is the following: > > GNU Emacs, when it reads an ESCAPE, does a read-with-timeout to > see if any characters are following it (so you can still use ESCAPE as > a command alone). I'll bet that the emacs code gets confused when > characters arrive so quickly. One of the things the network does to > the input is "BUNCH" characters into bursts (packets) which could > overrun EMACS. I think this is an EMACS bug. > Has anyone found a "fix" for this (if this is indeed the problem) under VMS? I've posted this to both comp.os.vms and to comp.emacs. If you are answering from the vms group posting, please send directly to me as I do not follow that group (too big). I'll post a summary of responses. Many thanks for any help.......rich
jbw@bucsf.bu.edu (Joe Wells) (03/17/90)
In article <RICH.90Mar15120535@hadrian.ria.ccs.uwo.ca> rich@ria.ccs.uwo.ca (Rich Jones) writes: One suggestion that's been given to us is the following: > > GNU Emacs, when it reads an ESCAPE, does a read-with-timeout to > see if any characters are following it (so you can still use ESCAPE as > a command alone). I'll bet that the emacs code gets confused when > characters arrive so quickly. One of the things the network does to > the input is "BUNCH" characters into bursts (packets) which could > overrun EMACS. I think this is an EMACS bug. Well, I just checked in the source code for GNU Emacs (in src/sysdep.c and src/keyboard.c) and I could not find any evidence to support that assertion. GNU Emacs will allow you to use ESC alone if it is bound to a command in the local keymap, but is a prefix in the global keymap, however this does not seem to be related. -- Joe Wells <jbw@bu.edu> jbw%bucsf.bu.edu@cs.bu.edu ...!harvard!bu-cs!bucsf!jbw