[net.micro.mac] Use of command keys

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