jhs@MITRE-BEDFORD.ARPA (04/07/88)
Aha, there really ARE keypad functions! I guess I didn't get that far
through the manual, because I have been telling people there was no
keypad emulation. Sorry about that. I tend to get impatient with reading
long manuals, and it is certainly unfair to your yeoman efforts on kermit65
that I have misinformed a number of people. I'll have to print a retraction.
However, I would like to lobby for a more user-friendly implementation
than that described in the Version 3.3 kermit65 documentation.
I use a real vt100 at work and OmniCom at home, and I would go bonkers
(for awhile, at least) to have to map from needed function to printed
symbol on a vt100 (which, recall, I would not have at hand when needing
the information, since I would be at an Atari terminal, not my trusty
vt100 at work), to corresponding printed symbol on the Atari, which is
usually but not always the same, to new location of said symbol on the
Atari keyboard.
What is so nice about the OmniCom implementation is that just about
everything is mapped isomorphically in a geometric sense -- the
keypad layout is a 4-by-4 pad made up of
1 2 3 4
q w e r
a s d f
z x c v b n (v=ENTER, b=0 and n=.)
with only the b and n being out of place. They are the "last row".
When I started using OmniCom, I had been a user of "vt10sq", which uses
the same geometric layout, but requires you to type "ESC" before each
keypad key to indicate keypad mode. David Young kept the layout, which
made my life easier, since I had by then gotten very used to mapping between
it and the real vt100. I suggest that these two precedents -- vt10sq and
OmniCom -- are popular enough that if there is to be a standard location for
the keypad on the Atari keyboard, this is probably the right place for it.
For one thing, the 1 2 3 4 is easily mapped to PF1 through PF4.
David then enhanced the keypad operation by going to the convention that
pressing the SELECT key and holding it down turned on keypad mode for those
keys. This was a very great improvement over the vt10sq convention of
prefixing each keystroke with "ESC", but was slightly clumsy for me as a
right-hander, but I have gotten used to it. Lefties should love it. I later
suggested that he read the joystick trigger button too, so right-handers could
use it, and place the joystick over at the left side of the keyboard, leaving
their right hand free to peck on keypad keys.
The cursor keys can be mapped right onto the Atari cursor keys,
delete/backspace to BACKSPACE, CTRL-delete/backspace to DELETE
(I think that's how I did it -- my several hosts and application
programs are a bit schizoid on this point). Also, I like using
the Atari / reverse video key to map into Line Feed, and SHIFT/Atari
to map into Tilde, which one needs a lot with unix. The Atari key
on the 800XL anyway is RIGHT where the LF key on a vt100 is, making
it a natural reflex to poke it when what you want is "ARG" in the
Rand editor, or a real LF. But all this is straight macro definition.
I think this point of view, that users may well switch back and forth
between the real terminal and the emulator and that a graphic or geometric
emulation of the keyboard will be most helpful, should be used to guide
your final keypad emulation and key macro definition facilities. Of course
key macro definitions per se are pretty flexible anyway. In fact, if you did
nothing more than add macro definition capability, and used SELECT to define
the whole keyboard as a new character set, then of course one could define the
keypad anyway he/she wanted to. The only penalty would be duplicated storage
of a lot of ESC sequences (what, maybe 30 or 40 bytes?) and of course extra
effort to program the keypad macros versus inserting the constant part
automatically.
(Speaking of definitions, they ought to define "se" in English to mean he/she.
Hah, I hereby do so. Spread the word.)
OMNIVIEW (and I think standalone OmniCom too?) uses the HELP key to toggle
screen scrolling on and off. This is a lot easier to do than CTRL-1, as
supported by the Atari O/S, but of course it pre-empts the HELP key.
Then again, I haven't seen any program that uses it other than OMNIVIEW.
Then again, that reasoning is not my idea of good software engineering
practice. If flow control is implemented, one could of course use CTRL-s
and CTRL-q fairly conveniently.
I hope other comments from the Net will be stimulated by the above. Now
is the time to influence the final form of kermit65.
-John Sangster / jhs@mitre-bedford.arpajhs@MITRE-BEDFORD.ARPA (04/07/88)
Aha, there really ARE keypad functions! I guess I didn't get that far
through the manual, because I have been telling people there was no
keypad emulation. Sorry about that. I tend to get impatient with reading
long manuals, and it is certainly unfair to your yeoman efforts on kermit65
that I have misinformed a number of people 12 I'll have to print a retraction.
However, I would like to lobby for a more user-friendly implementation
than that described in the Version 3.3 kermit65 documentation.
I use a real vt100 at work and OmniCom at home, and I would go bonkers
(for awhile, at least) to have to map from needed function to printed
symbol on a vt100 (which, recall, I would not have at hand when needing
the information, since I would be at an Atari terminal, not my trusty
vt100 at work), to corresponding printed symbol on the Atari, which is
usually but not always the same, to new location of said symbol on the
Atari keyboard.
What is so nice about the OmniCom implementation is that just about
everything is mapped isomorphically in a geometric sense -- the
keypad layout is a 4-by-4 pad made up of
1 2 3 4
q w e r
a s d f
z x c v b n (v=ENTER, b=0 and n=.)
with only the b and n being out of place They are the "last row"
When I started using OmniCom, I had been a user of "vt10sq", which uses
the same geometric layout, but requires you to type "ESC" before each
keypad key to indicate keypad mode 12 David Young kept the layout, which
made my life easier, since I had by then gotten very used to mapping between
it and the real vt100. I suggest that these two precedents -- vt10sq and
OmniCom -- are popular enough that if there is to be a standard location for
the keypad on the Atari keyboard, this is probably the right place for it.
For one thing, the 1 2 3 4 is easily mapped to PF1 through PF4.
David then enhanced the keypad operation by going to the convention that
pressing the SELECT key and holding it down turned on keypad mode for those
keys. This was a very great improvement over the vt10sq convention of
prefixing each keystroke with "ESC", but was slightly clumsy for me as a
right-hander, but I have gotten used to it Lefties should love it I later
suggested that he read the joystick trigger button too, so right-handers could
use it, and place the joystick over at the left side of the keyboard, leaving
their right hand free to peck on keypad keys.
The cursor keys can be mapped right onto the Atari cursor keys,
delete/backspace to BACKSPACE, CTRL-delete/backspace to DELETE
(I think that's how I did it -- my several hosts and application
programs are a bit schizoid on this point). Also, I like using
the Atari / reverse video key to map into Line Feed, and SHIFT/Atari
to map into Tilde, which one needs a lot with unix. The Atari key
on the 800XL anyway is RIGHT where the LF key on a vt100 is, making
it a natural reflex to poke it when what you want is "ARG" in the
Rand editor, or a real LF 12 But all this is straight macro definition.
I think this point of view, that users may well switch back and forth
between the real terminal and the emulator and that a graphic or geometric
emulation of the keyboard will be most helpful, should be used to guide
your final keypad emulation and key macro definition facilities Of course
key macro definitions per se are pretty flexible anyway In fact, if you did
nothing more than add macro definition capability, and used SELECT to define
the whole keyboard as a new character set, then of course one could define the
keypad anyway he/she wanted to 12 The only penalty would be duplicated storage
of a lot of ESC sequences (what, maybe 30 or 40 bytes?) and of course extra
effort to program the keypad macros versus inserting the constant part
automatically
(Speaking of definitions, they ought to define "se" in English to mean he/she.
Hah, I hereby do so. Spread the word.)
OMNIVIEW (and I think standalone OmniCom too?) uses the HELP key to toggle
screen scrolling on and off 12 This is a lot easier to do than CTRL-1, as
supported by the Atari O/S, but of course it pre-empts the HELP key
Then again, I haven't seen any program that uses it other than OMNIVIEW.
Then again, that reasoning is not my idea of good software engineering
practice. If flow control is implemented, one could of course use CTRL-s
and CTRL-q fairly conveniently.
I hope other comments from the Net will be stimulated by the above 12 Now
is the time to influence the final form of kermit65.
-John Sangster / jhs@mitre-bedfordswklassen@trillium.waterloo.edu (Steven W. Klassen) (04/12/88)
In article <8804061912=AA04304@mitre-bedford.ARPA> jhs@MITRE-BEDFORD.ARPA writes: >However, I would like to lobby for a more user-friendly implementation >than that described in the Version 3.3 kermit65 documentation. > >What is so nice about the OmniCom implementation is that just about >everything is mapped isomorphically in a geometric sense -- the >keypad layout is a 4-by-4 pad made up of > > > 1 2 3 4 > q w e r > a s d f > z x c v b n (v=ENTER, b=0 and n=.) > How about the arangement: 7 8 9 7 8 9 u i o ==> 4 5 6 j k l 1 2 3 m , . 0 , . to make a numeric keypad similar to most computers out there? > >David then enhanced the keypad operation by going to the convention that >pressing the SELECT key and holding it down turned on keypad mode for those >keys. Why not use a SELECT+key to toggle keypad on and SELECT+key to toggle it off again? Then you do not have to use one hand for the SELECT key and you can use the keypad with whatever hand you desire. >Of course >key macro definitions per se are pretty flexible anyway In fact, if you did >nothing more than add macro definition capability, and used SELECT to define >the whole keyboard as a new character set, then of course one could define the >keypad anyway he/she wanted to... Perhaps use SELECT+a couple of keys to allow the user to have more than one keyboard definition. SELECT+key1 turns on definition 1, SELECT+key2 turns on definition 2, etc. SELECT by itself could turn off all keyboard definitions and return to normal. Steven W. Klassen Computer Science Major University of Waterloo