vishniac@wanginst.UUCP (Ephraim Vishniac) (06/05/85)
As a follow-up to all this discussion of what programs do/don't support command keys, and when they do/don't work, why is it that every terminal emulator I've seen uses the command key as a "control" key? In text editing (whether in Edit, MacWrite, MacDraw, MacPaint,...), unusual character codes are generated with the *option* key while the command key is reserved, logically enough, for commands. Using the command key for generating character codes leaves the option key unused and prevents the use of command key shortcuts for menu items. Was this a MacTerminal mistake that everyone copied? Or is there some reason? Lonnie Abelbeck, do you know the answer? -- Ephraim Vishniac [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac vishniac%Wang-Inst@Csnet-Relay
guido@boring.UUCP (06/07/85)
The problem with using the Option key as a control key lies in the keyboard decoding. Interpretation of the Option key is done deeply hidden in the system file. The Macintosh uses a 256-character set, of which the first 128 characters are the corresponding ASCII characters and the second 128 (well, three quarters of them) are used for "funny" characters like math and foreign language symbols. The keyboard decoding in the system file uses a table which gives for every combination of shift, caps lock and Option, what character out of the character set should be generated. This table depends both on the keyboard you use (European keyboards have a different lay-out and one extra key) and on the country you're in (well, the country the mac thinks you're in). You can change the latter by software. There is also software with which you can change the map completely, but it depends on intricacies of the system code that are not (*** yet ***) revealed in Inside Macintosh. In contrast with this all, the Command key can be read out and interpreted by any program. For each character in the 256-character set that can be generated from the keyboard, it can be determined whether the Command key was pressed with it or not (some programs choose to ignore this fact!). So this is probably the reason why all terminal emulators use the Command key as a control key. They're right about it in that it does not make any assumptions about your keyboard layout or how your system file interprets the keys. (With the remapping software you could define the Option key to transmit the control characters. Personally I like the idea most of using the Caps Lock key -- it's much more in the "natural" place for a Control key. But you have to break the clicking mechanism...) Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam guido@mcvax.UUCP
lra@rduxb.UUCP (Lonnie R. Abelbeck, AT&T Bell Labs) (06/09/85)
> > Was this a MacTerminal mistake that everyone copied? Or is there some > reason? Lonnie Abelbeck, do you know the answer? > Well, I'm not one for copying MacTerminal mistakes, but there are a couple good reasons for using the Command Key for the "control" key. First, the Command and Option keys are treated differently by the Event Manager. The Command key is "detected" while another key is depressed, therefore Command-A is treated as "A" with the Command key depressed. The Option key treats the key as a totally new character defined in the KeyMap Resource on startup. Typically the Option key generates characters with Hex values greater than 0x7F with no real order, so Option-A is the foobar character and Option-A is not neccessarily one less than Option-B. Therefore by simply AND'ing the generated character with 0x1f when the Command key is detected results in both Command-a and Command-A yielding Control-A. Second.... you say, just DEFINE Option-A to yield Control-A in the KeyMap Resource. You don't want to do this if you want to keep foreign compatibility. By using the Command key approach, when the foreign Localizer program is run to edit the Key resource, the new A'ish character is detected with the Command key and a Control-A is generated. If the terminal program messes around with the Keymap you will no doubt screw-up the foreign mapping. (this is the reason I have resisted using the Option Key as a Meta Key in VersaTerm) Third, the Command key is easier to hit than the Option Key. I hope this helps.... Lonnie Abelbeck ihnp4!rduxb!lra
mikem@uwstat.UUCP (06/09/85)
> > > > Was this a MacTerminal mistake that everyone copied? Or is there some > > reason? Lonnie Abelbeck, do you know the answer? > > > > Well, I'm not one for copying MacTerminal mistakes, but there are a couple > good reasons for using the Command Key for the "control" key. ..... > (this is the reason I have resisted using the Option Key as a Meta Key > in VersaTerm) However the newest version of MacKermit, includes a little program which allows one to define any keyboard mapping for the terminal emulation. I still use command as the CNTRL key (I could use caps lock if I removed the locking mechanism), and I use option as a META key. Allowing the user to specify thier own keyboard seems the best approach to me. It probably (I'm not sure about this?), allows for hte international version of the mac too. (Can anyone in Europe confirm this?). --Mike -- Mike Meyer -- Phone +1 (608) 262-1157 (Leave messages at 262-2598) ARPA: mikem@Statistics <==> mikem@Wisc-Stat.ARPA UUCP: ...!{allegra,ihnp4,seismo,ucbvax,pyr_chi,heurikon}!uwvax!uwstat!mikem
tdn@cmu-cs-spice.ARPA (06/10/85)
You can use OPTION as a CONTROL key with MacTerminal by copying its internal
keyboard mapping resource to a file, editing the map with a disk editor (such
as Fedit 1.2 (which is free, unlike versions 2.0 and later), and copying the
modified resource into a MacTerminal document. None of this is documented in
the MacTerminal manual, but it was documented in a couple of USENET messages
several months ago.
For that matter, you can modify the font that MacTerminal uses on a per-
document basis.
-- Thomas Newton
Thomas.Newton@cmu-cs-spice.ARPA