Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!hao!oddjob!mimsy!aplcen!osiris!jdia From: jdia@osiris.UUCP Newsgroups: comp.sources.d,comp.emacs Subject: Re: when using termcap, get it right! Message-ID: <1166@osiris.UUCP> Date: Fri, 12-Jun-87 13:31:03 EDT Article-I.D.: osiris.1166 Posted: Fri Jun 12 13:31:03 1987 Date-Received: Tue, 16-Jun-87 01:05:52 EDT References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM> <6828@mimsy.UUCP> <1335@super.upenn.edu.upenn.edu> Organization: Johns Hopkins Hospital Lines: 68 Keywords: termcap, curses Xref: utgpu comp.sources.d:777 comp.emacs:1017 Summary: There are other problems too! In article <1335@super.upenn.edu.upenn.edu>, catone@dsl.cis.upenn.edu (Tony Catone) writes: > > The problem we have with this is that our users fall in love with > the VT100 keyboard for editors like EDT and TPU, and then complain > about the incomplete VT100 emulation PC's provide. In reality, most > times it turns out the emulators (PC/Intercom, MS-Kermit, CrossTalk) > are very complete (with the notable exception of 132 column mode), but > are limited by the fact that the PC keyboard does not physically have > as many keys as the VT100 layout. Unix users of emacs and vi are > not usually as unhappy, since those editors do not rely as much on > function keys etc. A worse problem exists for those of us who access machines through Bridge boxes, multiplexers, and some types of switches. First of all, most of these filter out some control characters, to use them for their own weird purposes, or handshaking. More than half of these that I have encountered do not pass ^S and ^Q (xoff and xon) as they are sent. This recks havok with editing in EMACS, which usually has ^S bound to search-forward and ^Q bound to quote-character. To top it off, ^X^S is SAVE-FILE!!!! Try working in an editor where you can't even save a file!!! There are usually ugly kludges around these problems. These usually consist of binding other keys to these functions. This is especially difficult in emacs because there are functions already bound to most of the keys and key-combinations. Why can't multiplexers/bridgeboxes pass these AS THEY ARE RECEIVED??? It shows a lack of thought on the part of someone, I'm not quite sure who. There has got to be a better way of doing this handshaking! Or, there has to be a version of emacs that makes more use of individual terminals' program function keys, and less use of control chars. esc-codes are ok, but the control codes can really mess things up. Worst problem ever seen: At an unnamed computer center there are several microterm terminals (vt100/vt220 compatible), and several DEC-GiGi's. Obviously everyone prefers to use the microterms. So one day I go there to do some work, and I discover that all of the microterms are in use. So I go to a gigi. I start up emacs, and discover that every time the screen is rewritten, emacs decides it wants to search! Why? because the GiGi's are so inept that they can't really hand 9600 baud (after all, their terminal logic is written in inerpretive basic!!). So, they tell unix to stop sending data so they can catch up, using ^S/^Q. But emacs interprets this as a search. &%$%*^$*&)^^%&-up eh? The "IDEAL" solution to this problem would be to make emacs understand pf-keys better. Microemacs is easily kludged to do this. Isn't it about time this happened? I won't even mention that most emacs'es don't understand the cursor keys which exist on all but the most archaic terminals (and Macintoshes). :-) That's Enough... Spidey! -- A message from Spidey, and the Spidey Team. ------>>>> \_\ /_/ ____________________________________________________________ _[*]_ \ Reachable via UUCP: ...decvax!decuac!aplcen!osiris!jdia / / / \ \ / ...allegra!mimsy!aplcen!osiris!jdia \