jdia@osiris.UUCP (06/12/87)
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 \
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/15/87)
Railing against the use of DC3 and DC1 for flow control by some terminals is pointless -- they need to throttle incoming data, especially at high bit rates and when performing complex actions such as line insertion, and the DC3/DC1 method was chosen as the best way to do this, given that most modems don't correctly handle control-line (out of band) flow control. If your terminal requires support for DC3/DC1 flow control, you should so inform the UNIX terminal handler, which will make sure the DC3/DC1 characters are not seen by the application. You should also have the "xo" Boolean capability set in the termcap entry. If in spite of this, your copy of EMACS nonetheless persists in receiving DC3/DC1 and treating them as user command keystrokes, then your EMACS is in need of repair. The version I often use does not have this problem. (You should also get out of the habit of using any key bindings containing ^S or ^Q. That was a really stupid set of defaults in the first place.)
tech@auvax.UUCP (06/16/87)
In article <1166@osiris.UUCP>, jdia@osiris.UUCP (Josh Diamond) writes: > 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 ... > 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? The problem for me is that to use function keys I have to take my hands off the keyboard and reach for the function keys. Worse, I have to take my eyes off the screen and look at my hands. On VMS I use the TPU based LSEDIT where I have mapped the more used function keys to emacs like control chars. I have to conclude that Function Key editors were not invented by typists. ********* 73 ********** Richard Loken VE6BSV . **** .. **** Athabasca University .... **** Athabasca, Alberta Canada ..........**** ihnp4!alberta!auvax
moore@UTKCS2.CS.UTK.EDU.UUCP (06/16/87)
In article <5988@brl-smoke.arpa>, Doug Gwyn <gwyn@brl-smoke.arpa> writes: > ... If in spite of this, your >copy of EMACS nonetheless persists in receiving DC3/DC1 and treating them >as user command keystrokes, then your EMACS is in need of repair. The >version I often use does not have this problem. (You should also get out >of the habit of using any key bindings containing ^S or ^Q. That was a >really stupid set of defaults in the first place.) Display editors were using ^S and ^Q before terminals were. Using ^S and ^Q for terminal flow control without providing a means of keyboard-to-application transparancy was the stupid decision. Too bad, it would have been easy to do it right. The sad truth is that it's easier to fix the software than to fix or get rid of all of the brain-damaged terminals, terminal concentrators, etc. Keith Moore Internet: moore@utkcs2.cs.utk.edu University of Tenn CS Dept CSnet: moore@tennessee Knoxville TN BITNET: moore@utkcs1
mjp@spice.cs.cmu.edu (Michael Portuesi) (06/16/87)
Keywords: jdia@osiris.UUCP (Josh Diamond) writes > 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? A genuine DEC VT-100 can't deal with 9600 baud throughput either, and does the exact same thing. Whoever decided that a flow control mechanism should use two characters out of the ASCII set should be shot. > 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). :-) But Emacs is supposed to be portable, not only across machine architectures and operating systems but across input devices as well. I use up to four different keyboards a day, with varying layouts and differing function keys. I also use four or more different flavors of Emacs (GNU, MicroGNU, Epsilon, Hemlock (an Emacs written in Common Lisp here at CMU) and (ugh) Gosling). I for one am glad there is some common denominator between all these editors, because my brain can't handle that many context shifts. As a result, I wind up using few special features of these editors since I can't get used to using a feature that's not present anywhere else. GNU Emacs can be customized to recognize special keys on your terminal, so you can bind functions to them. At least it recognizes the cursor and function keys on my Amiga emulating a VT-100. I would be surprised if the other variants of Emacs wouldn't let you do the same. --M -- Mike Portuesi / Carnegie-Mellon University Computer Science Department ARPA: mjp@spice.cs.cmu.edu UUCP: {backbone-site}!spice.cs.cmu.edu!mjp BITNET: rainwalker@drycas (a uVax-1 run by CMU Computer Club...tons o' fun)
earleh@dartvax.UUCP (Earle R. Horton) (06/16/87)
In article <1166@osiris.UUCP>, jdia@osiris.UUCP (Josh Diamond) writes: > > 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). :-) > The Macintosh does too have cursor keys! If you bought one before the cursor keys came out, then you have to shell out some $ to get a new keyboard with cursor keys, but hey, this is America. If you want to criticize the Mac, pick something valid, like the speed of display. You are right about one thing, however. Mac cursor keys produce easily-recognizable characters (^^,^\,^_,^]), then the terminal program usually converts them to unrecognizable ANSI gibberish, then you have to write mlisp (or lisp) to get the emacs to recognize it. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
guy@gorodish.UUCP (06/16/87)
> I have to conclude that Function Key editors were not invented by typists.
I have to conclude that this is a flame based on personal anecdotal
evidence. There are benefits to function keys (for one thing, you
don't have to hit a shift key - I, for one, find I occasionally get
^X-^N when I want ^X-n) and there are benefits to control keys (you
don't have to move your hands from the main keyboard).
However, it is possible to work with a program that uses control keys
(most of the time I don't end up getting ^X-^N when I want ^X-n) and
it is possible to work with a program that uses function keys (when
useing such an editor my hands learned where the function keys were,
and I could go there and back very quickly without looking).
I have yet to see any objective evidence to indicate either that function
keys are clearly superior to control keys or that control keys are
clearly superior to function keys. It would be interesting to see
experimental (as opposed to anecdotal) evidence either way.
You can say that you work better with control keys, or that you work better
with function keys, but not that "control keys are better" or
"function keys are better".
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.comjmg@mdbs.UUCP (John Murray Gamble) (06/17/87)
In article <189@auvax.UUCP> tech@auvax.UUCP (Richard Loken) writes: > >The problem for me is that to use function keys I have to take my hands off >the keyboard and reach for the function keys. Worse, I have to take my >eyes off the screen and look at my hands. > >On VMS I use the TPU based LSEDIT where I have mapped the more used function >keys to emacs like control chars. > >I have to conclude that Function Key editors were not invented by typists. > > ********* 73 > ********** Richard Loken VE6BSV > . **** > .. **** Athabasca University > .... **** Athabasca, Alberta Canada >..........**** ihnp4!alberta!auvax Actually, i conclude just the opposite. *Editing* is different from *typing*. The operations involved in editing (moving or deleting lines, words, or characters, searching/replacing) have very little to do with actual creative typing. When i am typing, my fingers stay on the main keyboard for long periods of time, and when i am editing my left hand rests while my right hand works the keypad. I never had to look at my hand, anymore than i look at the keyboard for typing. This is one of the reasons i miss EDT. When doing actual editing, all the keys i need to use are beneath *one* hand, which does not need to move while i am editing. No silly control key to hit (an operation invented to destroy the pinkie finger on the left hand) while simultaneously hunting for the key to be control-ed. Thank god EMACS-style editors allow key rebindings, or my fingers would be useless. For those wondering what the fuss about EDT is, a short, incomplete description of it would be to call it the RISC equivalent of editors. Very few commands in screen mode, but they are very powerful. It is analagous to driving a car, in that the same operations work in forward and reverse, with the directions toggled by a key(pad)stroke. It was a definite change from vi and took a lot of getting used to, but it ruined vi for me. EMACS (any flavor) is now my editor of choice. ---------------------------------------------------------------------------- John M. Gamble | Lo! thy dread Empire COBOL is restored; 2550 Yeager Rd. #15-2 | Light dies before thy uncreating word: West Lafayette, IN 47906 | Thy hand, great Anarch, lets the curtain fall, -------------------------| And Universal Darkness buries all. (313) 497-9501 | ihnp4!pur-ee!mdbs!jmg | from "The Dunciad", sort of, by Alexander Pope ----------------------------------------------------------------------------
tech@auvax.UUCP (06/17/87)
In article <21251@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > > I have to conclude that Function Key editors were not invented by typists. > > I have to conclude that this is a flame based on personal anecdotal > evidence. There are benefits to function keys (for one thing, you Some little nits can't tell a flame from a reasonably restrained comment. I said that this was my opinion and did not imply that control keys are better but suggested that two or three people out of 100,000 might prefer them. I will explain flames so that you can use the term correctly in the future. THIS IS A FLAME. YOU ******* IDIOT!!! ********* 73 ********** Richard Loken VE6BSV . **** .. **** Athabasca University .... **** Athabasca, Alberta Canada ..........**** ihnp4!alberta!auvax
daveb@geac.UUCP (Dave Brown) (06/19/87)
In article <8706152003.110@utkcs2.cs.utk.edu> moore@UTKCS2.CS.UTK.EDU.UUCP writes: >In article <5988@brl-smoke.arpa>, Doug Gwyn <gwyn@brl-smoke.arpa> writes: > >> ... If in spite of this, your >>copy of EMACS nonetheless persists in receiving DC3/DC1 and treating them >>as user command keystrokes, then your EMACS is in need of repair. The >>version I often use does not have this problem. (You should also get out >>of the habit of using any key bindings containing ^S or ^Q. That was a >>really stupid set of defaults in the first place.) > >Display editors were using ^S and ^Q before terminals were. Using ^S >and ^Q for terminal flow control without providing a means of >keyboard-to-application transparancy (sic) was the stupid decision. >Too bad, it would have been easy to do it right. Both terminals using flow control and programs using the same characters for other purposes are historical accidents, and were substantially cleaned up in the days of poll-and-select by something called ASCII, which defined (yay!) a set of in-band (boo!) signals for basic terminal/printer operations in the new 7-bit code they defined (most manufacturers were using 6-bit or less). Snarling at each other about who was first is silly: *both* were first, but on different sites. How about a discussion on something useful? WHAT KEYS DO YOU BIND IN PLACE OF ^S, ^Q? RSVP D.R. Brown. daveb@geac
meissner@xyzzy.UUCP (Michael Meissner) (06/25/87)
In article <810@geac.UUCP> daveb@geac.UUCP (Dave Brown) writes: > > WHAT KEYS DO YOU BIND IN PLACE OF ^S, ^Q? I use C-T for C-S, M-" for C-Q (and M-+ for the traditional C-T character transpose). This was initially because the DG CCA emacs port had an alternate guise that mimic'ed the traditional AOS/VS edit bindings. I have also C-T is much easier to type than either C-S or C-\, and I do searches considerably more than traspose, etc. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!dg_rtp!meissner