> > The standard speaks only in terms of keystrokes, not ASCII values.
> 
> ::sigh::

Yes, that certainly undermines their position that OF should be usable
from ASCII terminals.

> And do ADB and USB devices send the same codes for these keystrokes?
> Who knows...

But it doesn't matter what codes get sent, as long as the same keystroke
produces the same command.

> > 	Apple extensions:
> > 	^@		same as ^space
> 
> Wait. ^space == NULL? That boggles the mind...

Apple is off the hook this time.  Blame DEC and possibly other terminal
makers.

http://vt100.net/docs/vt100-ug/table3-5.html

http://vt100.net/docs/vt220-rm/table3-5.html

(There could be a few typos, but I hope you get the idea that DEC was
rather lenient in its keyboard mappings for control keys.)

Besides, you should know that from Emacs.  It always advertised that ^space
would set the mark (even the documentation in the TECO version says that)
and ^space generally works on ASCII terminals.  But ASCII never defined 
^space so it obviously has to send some other character.

> > 	^?		doesn't do what the standard says
> 
> Probably because there's no difference between that and one of the
> delete/backspace keys in the Apple hardware world. (That's purely
> a guess.)

Apple's "keystroke-to-ASCII" routine is quite simplistic.  I don't know
if the one in the OS is smarter than the one in OF.

> > Command and Option are ignored (so I guess there's no meta key) and there
> > seems to be no "erase and save back to beginning of line" keystroke.
> > Oh well... this feature is nice to have anyway.
> 
> Yeah, well, being as emacs wants to be its own operating system,
> there's a limit to how much of it you want in your firmware anyhow.

Yeah, but I think the keystroke-to-ASCII routine could still be a bit
smarter.  Oh well, at least it's reliable.  I do wish MacOS programs
wouldn't use it, though.  Why shouldn't I be able to distinguish ^M
from Return when setting up my MacOS text editor keys? :)

-- Derek