KFL@MC.LCS.MIT.EDU ("Keith F. Lynch") (03/02/86)
From: Jeff Siegal <JBS%DEEP-THOUGHT@EDDIE.MIT.EDU>
1) The ESC key is dead. It is an unmanagable concept. If you
don't know why, I'll be glad to explain it.
Please do.
The escape key is necessary for lots of software, from Emacs to
VisiCalc. On virtually every ASCII keyboard it is in a prominent
place, and since ESC is very seldom a part of any text or numeric
input to a program, it makes a very useful command key or command
prefix key. I have used programs which use ESC under VMS, UNIX,
TOPS-10, TOPS-20, CP/M, MS/DOS, Apple-DOS, and ITS. Most major
programs that I write use the ESC key for something. The only ASCII
keyboards I can recall ever seeing that don't have it are the VT200
and MicroVAX keyboards made by DEC. Even the stripped down Apple II
keyboard has an ESC key.
These days, with screen editors, spreadsheets, database programs,
and other screen oriented software all the rage, the ESC key is more
important than ever. Especially on ANSI terminals, as they use ESC
sequences for virtually everything.
2) C-S, C-Q are too commonly used in the communcations protocol
to be useful in applications. I hurts me to say this, since
I'm generally an EMACS fan too.
^S ^Q flow control is an idea whose time has passed. With
international networks, the line delays are too long. When I used a
VT100 terminal to log onto a VMS VAX 3000 miles away, I had to turn
smooth scroll off, as the delay on the line was causing the terminal
buffer to overflow before the host got the ^S, resulting in garbage
on the screen.
The only reason for ^S ^Q flow control is because the terminal can't
keep up with the data coming in. At speeds less than 19,200 baud, I
don't think there is any excuse for that. My H19 terminal, costing
less than half the cost of a VT100 at the time I got it, can keep up
with any and all data and ESC sequences even at 9600 baud. There is
not reason why DEC terminals should not be able to.
One reason for a terminal being unable to keep up is smooth scroll.
Smooth scroll was never a terribly good idea. We encourage our VMS
users not to use it since processing all the ^Ss and ^Qs eats up a
significant percentage of our VAX-11/785. And because sending a
broadcast message to a user who is ^Sd can cause the broadcasting
process to freeze.
I think that smooth scroll was intended to make text easier to read
as it scrolls. Text can be difficult to read if it scrolls at a
variable rate. However, this problem was solved years ago. The
solution is for the host to send one screen of information at a time
and to wait for the user or the terminal to request another screen.
The new text then overwrites the old text from the top, and nothing
ever scrolls. Note that no amount of network delay can result in any
data being lost or garbled, since nothing is sent until the terminal
says it is ready for another screenful.
I was dismayed to discover that DEC is apparently unaware of this.
As demonstrated by the fact that the NO-SCROLL key on the VT100 does
not switch the terminal from scroll mode to wrap mode as I had
guessed the first time I saw it, but simply freezes the screen,
preventing any new text from being displayed.
^S ^Q flow control is not incompatible with other uses for ^S and
^Q. Many terminals, including the VT100, will use ^S and ^Q for flow
control and will allow the user to type those characters for use with
applications programs, such as Emacs, that use them. The VT200,
however, simply ignores ^S and ^Q when typed by the user. This is not
reasonable behavior. Neither is it reasonable that, while the VT200
has dozens of keys that send ESC followed by several characters, it
has no key that simply sends an ESC. Fortunately, it is easy to have
Emacs interpret the backquote key (which is where the ESC key belongs)
as an ESC, at the expense of having a hard time sending a real
backquote character. But this is no solution, since most programs
that require an ESC as input do not allow users to rebind keys in this
way. Neither should terminals or computers be set up such that users
have to fight against them, and have to do obscure and complicated
rebindings, to be able to use features that most users have now been
taking advantage of for years.
In particular, it is not reasonable for a terminal to not let the
user send all 128 ASCII codes, or to not be able to do so without some
sort of rebinding or reprogramming of the terminal. The trend, in
fact, is away from keyboards with missing codes, such as the Apple II,
and towards keyboards that allow users to send all 256 possible 8 bit
codes.
DEC is not causing the problem. The problem is applications which
have not evolved to co-exist with modern terminal/communications
standards.
It looks to me like DEC *IS* causing the problem. No other modern
computers or terminals that I am aware of have these misfeatures.
Please tell me how Emacs should 'evolve' to compensate for this
lossage. If TPU is an 'evolved' Emacs, I will choose the old way any
day of the week.
...KeithJBS%DEEP-THOUGHT@EDDIE.MIT.EDU (Jeff Siegal) (03/02/86)
1) The ESC key is dead. It is an unmanagable concept. If you
don't know why, I'll be glad to explain it.
Please do.
[lots of flamage about VisiCalc, etc. All keyboards have ESC keys
(paraphrased)]
Especially on ANSI terminals, as they use ESC
sequences for virtually everything.
Exactly the point. My concept of unmanageable comes from the fact the
the ESC code is used as the lead-in for ANSI character sequences (most
common ones start with ESC-[, which has an 8-bit equiv. I can't
remember; some others start with ESC-O, still others with ESC-P).
These codes are used by the terminal to report the use pressing the
function or other special keys, to report the cursor position, to
report mouse position, and mouse button activation, etc. Giving the
single code (27 - ESC) a meaning of its own prevents these other
functions from being used.
An aside: I complained a while ago to RMS about GNUemacs not having
support for ANSI sequences (on the input side) and even offered to
write the code and make the appropriate mods to the keyboard interface
code. His response was that he did not want to eliminate the
traditional Emacs command ESC-[, since he used that and did not use
ANSI terminals. I tried to explain that ESC was just a kludge for the
lack of a Meta key, and that Meta would be implemented by another
prefix key on ANSI terminals (Gold key on a VT100, perhaps), but I was
ignored (how dare you speak out against the ESC key and other religious
nonsense).
2) C-S, C-Q are too commonly used in the communcations protocol
to be useful in applications. I hurts me to say this, since
I'm generally an EMACS fan too.
^S ^Q flow control is an idea whose time has passed. With
international networks, the line delays are too long. When I used a
VT100 terminal to log onto a VMS VAX 3000 miles away, I had to turn
smooth scroll off, as the delay on the line was causing the terminal
buffer to overflow before the host got the ^S, resulting in garbage
on the screen.
Non-broken applications of XON/XOFF use it only for flow control over
a single comm line (e.g. EIA RS-212). For example, between the
terminal and the computer (or terminal concentrator) or between the
computer and a printer on an async. line.
There is no out-of-band data path for communications over an EIA line
with 4 conductor wire. If people are willing to use 6 conductor cable,
there is hardware flow control, but in most cases this is not done, and
all hardware does not support it. It will also not work over a modem.
As you say, using XON/XOFF over a network is likely to fail horribly.
Over network lines, the network protocol should (and does) provide
out-of-band flow control.
In any case, the use over any part of the link between the user and
the computer of the C-S and C-Q chars prevent their use by
applications programs.
The only reason for ^S ^Q flow control is because the terminal can't
keep up with the data coming in. At speeds less than 19,200 baud, I
don't think there is any excuse for that.
How about a graphics command sequence to rotate a figure x degress in
three dimensions (or even to fill a large region on the screen)? How
about terminals with optional hard-copy of the recieved characters?
How about a terminal in SET-UP mode? How about a LONG sequnce of
configuration codes?
My H19 terminal, costing
less than half the cost of a VT100 at the time I got it, can keep up
with any and all data and ESC sequences even at 9600 baud. There is
not reason why DEC terminals should not be able to.
See above.
One reason for a terminal being unable to keep up is smooth scroll.
Smooth scroll was never a terribly good idea. We encourage our VMS
users not to use it since processing all the ^Ss and ^Qs eats up a
significant percentage of our VAX-11/785.
Nonsense. If you are going to make such outrageous claims, please
provide either a reference or a way for someone else to demonstrate
it. (BTW: Do you use smooth scroll or not; above you said that you
had to "turn off smooth scroll", implying that it was normally on)
And because sending a
broadcast message to a user who is ^Sd can cause the broadcasting
process to freeze.
Yes, this is a VMS bug.
I think that smooth scroll was intended to make text easier to read
as it scrolls. Text can be difficult to read if it scrolls at a
variable rate. However, this problem was solved years ago. The
solution is for the host to send one screen of information at a time
and to wait for the user or the terminal to request another screen.
The new text then overwrites the old text from the top, and nothing
ever scrolls. Note that no amount of network delay can result in any
data being lost or garbled, since nothing is sent until the terminal
says it is ready for another screenful.
This is strictly your preference. I perfer jump scroll to both smooth
scroll and non scrolling. If someone prefers smooth scroll, why should
they be prevented from using it by the lack of flow control?
[flame about vt100 no-scroll key]
^S ^Q flow control is not incompatible with other uses for ^S and
^Q. Many terminals, including the VT100, will use ^S and ^Q for flow
control and will allow the user to type those characters for use with
applications programs, such as Emacs, that use them.
This is only the case if auto-flow-control is turned off. If it is on,
the C-S and C-Q keys change the internal "screen-frozen" state bit. The
terminal only sends XON/XOFF's when the internal buffer reaches certain
documented states (i.e. number of characters in buffer, etc.)
The VT200},
however, simply ignores ^S and ^Q when typed by the user. This is not
reasonable behavior.
The VT220 behavior is the same as the VT100. Turn XON/XOFF off on the
"comm" setup menu, and C-S and C-Q will generate the control chars, but
the terminal will not use those codes for flow control.
Neither is it reasonable that, while the VT200
has dozens of keys that send ESC followed by several characters, it
has no key that simply sends an ESC.
This is exactly the point. If the terminal sends an escape, the application
has no way to know if there are more characters following. Assuming that
an ESC is a command by itself prevents the other features from being
used.
Fortunately, it is easy to have
Emacs
Depends on your version of Emacs.
interpret the backquote key (which is where the ESC key belongs)
This may be your position, and others may share it (I may share it),
but the vt200 keyboard is based on an international standard.
as an ESC, at the expense of having a hard time sending a real
backquote character. But this is no solution, since most programs
that require an ESC as input do not allow users to rebind keys in this
way.
I will make one small concession in my position; new terminals
probably should have an ESC key so as to not break existing software
(a temporary violation of the standard) but...
Neither should terminals or computers be set up such that users
have to fight against them, and have to do obscure and complicated
rebindings, to be able to use features that most users have now been
taking advantage of for years.
applications should be running (not walking) away from the use of ESC as
a command on its own.
In particular, it is not reasonable for a terminal to not let the
user send all 128 ASCII codes, or to not be able to do so without some
sort of rebinding or reprogramming of the terminal. The trend, in
fact, is away from keyboards with missing codes, such as the Apple II,
What the hell did the Apple ][ keyboard have to do with proper
designs of keyboards/terminals? The international extension of
ASCII (ISCII :-)), uses all eight bits.
and towards keyboards that allow users to send all 256 possible 8 bit
codes.
OK. There are the missing 128 characters.
DEC is not causing the problem. The problem is applications which
have not evolved to co-exist with modern terminal/communications
standards.
It looks to me like DEC *IS* causing the problem. No other modern
computers or terminals that I am aware of have these misfeatures.
Please tell me how Emacs should 'evolve' to compensate for this
lossage.
Partly explained above. Any arbitrary sequence of characters should be
able to set the meta flag for the next character.
If TPU is an 'evolved' Emacs, I will choose the old way any
day of the week.
Not being experienced in TPU, I'll just say that your logic is
defective (if Emacs is old, and TPU is new, and TPU is worse than
Emacs, than anything new must be worse than the old way)
...Keith
Jeff
-------KFL@MC.LCS.MIT.EDU ("Keith F. Lynch") (03/03/86)
From: Jeff Siegal <JBS@DEEP-THOUGHT.MIT.EDU>
Giving the single code (27 - ESC) a meaning of its own prevents these other
functions from being used.
If you are familiar with Emacs, as you say you are, you should know
that ESC is not a command, but is a command prefix, just like in the
ANSI escape sequence set.
My point here was that it is often necessary to key in one of these
ANSI escape sequences, to give the terminal a command. If there is no
ESC key on the terminal, how can this be done?
An aside: I complained a while ago to RMS about GNUemacs not having
support for ANSI sequences (on the input side) ...
I am not sure what you mean. I'm not certain of ITS Emacs, but I
know that with the Emacs we have on our VAX, it is easy to make ESC-[
act like ESC. I have long since done this, so that VT100 arrow keys
can move the cursor in Emacs.
... I tried to explain that ESC was just a kludge for the
lack of a Meta key, and that Meta would be implemented by another
prefix key on ANSI terminals (Gold key on a VT100, perhaps), ...
Not always. What about the meta-ESC command? How do you do that
with just a meta key. (It is easy with just an ESC key, it becomes
ESC-ESC).
Most terminals don't have a meta key. The VT100 and VT200 don't.
Meta is implemented in ASCII by toggling the 8th bit. But DEC
precludes this by using the 8th bit for its multinational character
set. This set is another halfway DEC idea. The problem with it
(other than it eliminates use of the 8th bit for meta) is that the
foreign alphabetic characters it implements are not treated like
letters by any DEC software. Foriegners do not regard those as funny
characters, but as regular letters. And it can cause no end of
confusion when they are not treated as letters in DEC word processing
programs, editors, compilers, assemblers, spreadsheets, database
programs, or any other DEC or third party software I am aware of.
This just means that foriegners have to carefully concentrate on each
letter to try to decide whether it is in the English alphabet or not.
It would be a lot easier on them if these unusable letters were simply
unavailable, then they wouldn't waste time trying to use them.
The only reason for ^S ^Q flow control is because the terminal can't
keep up with the data coming in. At speeds less than 19,200 baud, I
don't think there is any excuse for that.
How about a graphics command sequence to rotate a figure x degress in
three dimensions (or even to fill a large region on the screen)? How
about terminals with optional hard-copy of the recieved characters?
How about a terminal in SET-UP mode? How about a LONG sequnce of
configuration codes?
Good point. But I was pointing out that the VT100 and VT200 need to
send ^S a lot more often than that, and just for reception of plain
text. That isn't reasonable.
As for graphics, etc, once more the terminal should send something
to request the next page (or however much) of data, rather than
telling the host to stop when the terminal buffer gets too full. The
latter is much more likely to lead to lost and garbled data. The
trend is definitely away from ^S and ^Q and towards what I describe.
All the modern graphics standards implement it.
You cannot rely on the existance of out-of-band signalling. When I
was logged into the VAX 3000 miles away, I was not going through any
network, but was dialing direct. ^S ^Q was the only protocol DEC made
available for such a phone call, and it failed horribly.
Also, ^S ^Q is very sensitive to line noise, and to flakey
connections. And what if your terminal or local host crashes? With
my protocol, no data will be sent until it comes up again. With your
protocol, since it isn't sending any ^Ss, data will continue to flow
in an unbroken stream, to be lost into the ether.
(BTW: Do you use smooth scroll or not; above you said that you
had to "turn off smooth scroll", implying that it was normally on)
The time I had to turn it off on the 3000 mile call was when we were
just starting to learn how bad it was. It wasn't until a few months
later that we decided it should always be off on all terminals.
If someone prefers smooth scroll, why should
they be prevented from using it by the lack of flow control?
I still think smooth scroll is a bad idea, for many reasons (not the
least of which is that long use of it has been known to cause users
dizziness, nausea, and a strong feeling that the text is standing
still and the building is sinking) but it is perfectly compatible with
rational protocols.
The VT200,
however, simply ignores ^S and ^Q when typed by the user. This is not
reasonable behavior.
The VT220 behavior is the same as the VT100. Turn XON/XOFF off on the
"comm" setup menu, and C-S and C-Q will generate the control chars, but
the terminal will not use those codes for flow control.
And it also disables smooth scroll, even though smooth scroll is
perfectly compatible with use of ^S and ^Q as commands, as can be seen
on the VT100. One of many VT200 misfeatures. One of many reasons we
decided not to buy any.
... the vt200 keyboard is based on an international standard.
I wish they would stop with the international standards already.
The only way they could have made the keyboard harder to use would be
to place some of the keys on the bottom.
[In Emacs] Any arbitrary sequence of characters should be
able to set the meta flag for the next character.
I agree. I also think that any character or sequence of characters
should be able to be bound to any command. This has been the case for
years. This is NOT possible for DEC's new TPU editor which will not
allow you to use ^S for search (or for anything else).
I think it a major win that when a friend of mine from Stanford
visited recently, that even though he had no experience with VMS, once
I put him into Emacs, he was completely at home. He was able to use
the Emacs commands, including ^S for searching, and various ESC
commands, despite the fact that to VMS these characters have very
different meanings.
If I had put him into TPU, even one that I had made as much like
Emacs as possible, as soon as he had tried to search for something
with ^S, the screen would have frozen, and if he did not realize this,
no amount of trying anything (unless he happened to hit ^Q) would have
helped him.
I think it is a major win that an applications program can work the
same way on many different operating systems. That in any Emacs
anywhere, ^S will search. That in any Emacs anywhere, ^G will get me
out of a funny state. But if Emacs was to be rebuilt to your
specifications, on any VMS system ^S would freeze the screen and ^G
would NOT get you out of that mode. I think that would be a major
lose.
...KeithJBS%DEEP-THOUGHT@EDDIE.MIT.EDU (Jeff Siegal) (03/03/86)
If you are familiar with Emacs, as you say you are, you should know
that ESC is not a command, but is a command prefix, just like in the
ANSI escape sequence set.
Oh really? How about the ESC-ESC (or M-ESC) command you speak of?
ESC is a real command in this usage. ESC is also a command in the
sense that it tells Emacs to set the Meta bit for the next character.
I repeat: If Emacs receives an ESC, should it set the Meta bit (on the
next character)? Common usage says yes, but what if the ESC was only
the lead-in to an ANSI sequence?
My point here was that it is often necessary to key in one of these
ANSI escape sequences, to give the terminal a command. If there is no
ESC key on the terminal, how can this be done?
As I agreed before (perhaps not in a message sent to you), one should
be able to send all 256 8-bit codes from the keyboard for obscure occasions
like this. Applications should not depend on it any more than they depend
on a 66 line screen; it is (should be) a luxury.
I am not sure what you mean. I'm not certain of ITS Emacs, but I
know that with the Emacs we have on our VAX, it is easy to make ESC-[
act like ESC.
How, my I ask, do you go to beginning-of-paragraph? If ESC-[ acts like
ESC, than M-A, M-B, M-C, M-D are up, down, right, and left, which is
certainly not what they do in traditional Emacs.
I have long since done this, so that VT100 arrow keys
can move the cursor in Emacs.
Then you have broken your Emacs.
... I tried to explain that ESC was just a kludge for the
lack of a Meta key, and that Meta would be implemented by another
prefix key on ANSI terminals (Gold key on a VT100, perhaps), ...
Not always. What about the meta-ESC command?
Exactly my point. ESC should not be a command (or a user-entered prefix).
How do you do that
with just a meta key. (It is easy with just an ESC key, it becomes
ESC-ESC).
Most terminals don't have a meta key. The VT100 and VT200 don't.
VT100 has no excuse. VT200 uses 8-bit codes for other things.
Meta is implemented in ASCII by toggling the 8th bit. But DEC
precludes this by using the 8th bit for its multinational character
set.
...and the 8-bit ANSI control codes.
This set is another halfway DEC idea. The problem with it
(other than it eliminates use of the 8th bit for meta) is that the
foreign alphabetic characters it implements are not treated like
letters by any DEC software. Foriegners do not regard those as funny
characters, but as regular letters. And it can cause no end of
confusion when they are not treated as letters in DEC word processing
programs, editors, compilers, assemblers, spreadsheets, database
programs, or any other DEC or third party software I am aware of.
They work just fine in EDT. I've never tried to use them with other
DEC software. If the DEC software doesn't work, that's DEC's software
developers' fault, not the fault of the codes used to represent the
characters.
This just means that foriegners have to carefully concentrate on each
letter to try to decide whether it is in the English alphabet or not.
I fail to see how this follows from 8-bit codes. It may follow
from broken DEC software.
It would be a lot easier on them if these unusable letters were simply
unavailable, then they wouldn't waste time trying to use them.
(1 more time) The characters should be both there and usable. As it is,
they can be output by applications (and by the VT200 setup mode) to make
things easier to read by non-english speaking users.
How about a graphics command sequence to rotate a figure x degress in
three dimensions (or even to fill a large region on the screen)? How
about terminals with optional hard-copy of the recieved characters?
How about a terminal in SET-UP mode? How about a LONG sequnce of
configuration codes?
Good point. But I was pointing out that the VT100 and VT200 need to
send ^S a lot more often than that, and just for reception of plain
text. That isn't reasonable.
The VT220 does not. The VT100 does, but only if equiped with the AVO.
This is, of course, broken.
As for graphics, etc, once more the terminal should send something
to request the next page (or however much) of data, rather than
telling the host to stop when the terminal buffer gets too full.
What you describe will only work in a half-duplex environment. With
data flowing in both directions, this becomes unreasonable. Example:
what do you do when the "send-next-page" commands come in too fast (on a
split speed line, for example).
You cannot rely on the existance of out-of-band signalling. When I
was logged into the VAX 3000 miles away, I was not going through any
network, but was dialing direct.
Was it really direct (i.e. terminal-->modem-->phone-line-->modem-->VAX 3000
miles away) or was there something in between to introduce buffering
delays?
^S ^Q was the only protocol DEC made
available for such a phone call, and it failed horribly.
Also, ^S ^Q is very sensitive to line noise, and to flakey
connections.
Not really. This may be the function of your terminal. Most good
implementations of XON/XOFF will repeat the XOFF several times if
the output does not stop (i.e. XOFF at buffer-half-full, XOFF at
buffer-3/4-full, XOFF at buffer-nearly-full), and will send XONs
after a certain amount of time if output does not resume. The vt100's
and vt200's implement the multiple XOFF, but not the multiple XON.
The time I had to turn it off [smooth scroll] on the 3000 mile call
was when we were
just starting to learn how bad it was. It wasn't until a few months
later that we decided it should always be off on all terminals.
I still think smooth scroll is a bad idea, for many reasons (not the
least of which is that long use of it has been known to cause users
dizziness, nausea, and a strong feeling that the text is standing
still and the building is sinking) but it is perfectly compatible with
rational protocols.
I maintain that it should be on if the user wants it on, and off if
the user wants it off. It should neither be always on, nor always off.
The VT220 behavior is the same as the VT100. Turn XON/XOFF off on the
"comm" setup menu, and C-S and C-Q will generate the control chars, but
the terminal will not use those codes for flow control.
And it also disables smooth scroll, even though smooth scroll is
perfectly compatible with use of ^S and ^Q as commands, as can be seen
on the VT100. One of many VT200 misfeatures. One of many reasons we
decided not to buy any.
On the vt100, if one uses smooth scroll without flow control, lost data
results; it (smooth scroll) is NOT perfectly compatible with using ^S and
^Q as commands. Again, I never said that I liked vtXXX terminals; only
that there XON/XOFF is too widely used to be ignored.
I can hardly see why you wouldn't buy vt220's baased on this; you
said you never used smooth scroll (and that it was off on all your
terminals).
[In Emacs] Any arbitrary sequence of characters should be
able to set the meta flag for the next character.
I agree. I also think that any character or sequence of characters
should be able to be bound to any command. This has been the case for
years. This is NOT possible for DEC's new TPU editor which will not
allow you to use ^S for search (or for anything else).
But the point is you shouldn't want to use ^S for search because it won't
work well universally.
I think it a major win that when a friend of mine from Stanford
visited recently, that even though he had no experience with VMS, once
I put him into Emacs, he was completely at home. He was able to use
the Emacs commands, including ^S for searching, and various ESC
commands, despite the fact that to VMS these characters have very
different meanings.
Ah, but if Emacs didn't make assumptions about what form of flow control
would be used (if any), than there would be a (universally accepted command)
other than ^S, ^Q, ESC, NUL, etc. for searching which could be used on ANY
system, even if XON/XOFF was implememted in hardware (and could not be
turned off).
If I had put him into TPU, even one that I had made as much like
Emacs as possible, as soon as he had tried to search for something
with ^S, the screen would have frozen, and if he did not realize this,
no amount of trying anything (unless he happened to hit ^Q) would have
helped him.
Which means TPU is probably not for people who want to use Emacs. If they
want to use Emacs, let them use Emacs.
I think it is a major win that an applications program can work the
same way on many different operating systems. That in any Emacs
anywhere, ^S will search. That in any Emacs anywhere, ^G will get me
out of a funny state. But if Emacs was to be rebuilt to your
specifications, on any VMS system ^S would freeze the screen and ^G
would NOT get you out of that mode. I think that would be a major
lose.
I agree that the commands should be universal. However, consider how
inconsistant using C-S, C-Q, etc. for commands in an environment which
uses them for flow control. The biggest win in human interfaces is
consistency. Take a look at the Mac. Well written software on the Mac
needs very little documentation. The user interface is the same as
other software.
Take a user (on VMS, for example) who is used to the conventions used
by all of the other utilities (e.g. TYPE, DIRECTORY, SORT, ACCOUNTING)
utilities. If he wants to stop the output, he presses ^S, or the
HOLD-SCREEN (or no-scroll) key. When he wants it to resume, he either
presses ^Q or the HOLD-SCREEN key again. Put him in Emacs, and other
software which ignores consistency, and watch him lose.
My gripe is with software (like Emacs) which when put into an environment
which makes assumptions (very common ones) about flow control, forces
an inconsistant user-interface.
...Keith
Jeff
-------daemon@ucbvax.BERKELEY.EDU (The devil himself) (03/03/86)
> This may be your position, and others may share it (I may share it), > but the vt200 keyboard is based on an international standard. > Jeff What standard? I have heard and challenged this claim before, and have never gotten a reference to a real live standards-body type document. Just because the keyboard is weird doesn't mean it's internationally kosher. By the way, I like the LK201, except for the stupid <> key. Note that the LK201 keyboard doesn't generate anything even remotely resembling ASCII; it's up to the box at the other end of the coiled cord (VT220, VT240, VT241, Pro-350, Rainbow, VAXstation-II, etc.) to turn what the keyboard sends into ASCII (or whatever). My Rainbow has a key labelled ESC (F11) that actually sends 033 (or causes the software to see an 033, which amounts to the same thing). If the box your LK201 talks to is programmable (i.e., anything except VT2xx) you can cause the keyboard to look like anything. Dvorak, anyone? But back to my original question: *what* international standard?
Bakin@HI-MULTICS.ARPA (Jerry Bakin) (03/11/86)
As long as we are running away from the discussion at hand,
...vi is quite capable
of understanding special-key sequences beginning with ESC, even
though hitting ESC in command mode by itself just sounds the bell
(or flashes the screen if the terminal is thus capable). I bet you
all wonder how vi can make this distinction. Well, it's simple.
vi waits for a short period after getting an ESC to see what else
it gets right afterward. If the ESC was immed- iately followed by
the rest of a special-key sequence, vi obeys it. If the ESC is NOT
followed by the remainder of a special-key sequence, or something
else which should be valid in command mode, during that wait, vi
beeps or flashes to indicate an error.
I used to have to dial up this multics system from 2000 miles away. Gee
I had a lot of noise (no GTE :). Anyway, I noticed that most (> 95%) of
the noise were pairs of <ESC>-{ or {-<ESC>. I wrote an extension to the
Emacs (in MacLisp) which sensed the time between time of program
execution and the next character. If the program timed out, or the next
character was neither an <ESC> nor a {, the character(s) was inserted.
Otherwise, the two characters were eaten up -- yum. I bound this
extension to the <ESC> and { keys. This got rid of almost all of the
noise and almost never ate (or even visibly slowed insertion of) <ESC>s
or {s.
Jerry.