From: friedman@gnu.ai.mit.edu (Noah Friedman)
Subject: Re: New Maps of -- 
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
Date: Mon, 13 Apr 1992 13:01:31 GMT

In article <DOOM.92Apr13024239@elaine5.Stanford.EDU> doom@elaine5.Stanford.EDU (Joseph Brenner) writes:
>Suppose I completely redesigned my keymap and then offered it
>up as a new alternative, encouraging others to use it?
>Further suppose I decide to talk the sys admins here at
>Stanford into making it the default keymap for all new users
>of emacs?
>
>Would there be anything evil, anything deeply un-Gnu about this?

   Providing an alternative keymap is fine, if they're good keymaps (more
on this below).  You should make it as easy as possible for users to find
out about the alternative map and get documentation for it.  I would
discourage you from making it the default set (even if the changes were
good) because people reading any of the several published user manuals for
GNU emacs (not to mention the online documentation) would become confused.

>Some Doom notes for a more rational keybinding (in order of priority):
>
>* Avoid collision with other uses of control characters:
>** Use C-? instead of C-h for help

   But for many people C-? is their delete key.  All you would be doing by
swapping the meaning of these two keys is to annoy the other half of the
universe.  

>** Use C-c as command interrupt only (in addition to C-g?)

   C-c is a fairly useful prefix for a large number of commands.  (it's
mnemonic for "ctrl-Command" is easy to remember, too.  If you get rid of it
you'll have to find another key to put the prefix on.  And it certainly
doesn't seem any more counterintuitive than C-x, or M-x for that matter.
See the final paragraph of this message for more. 

>** Use C-" for quoting control characters rather than C-q
>** May need to switch all C-s commands to something else also.

   My PC keyboard at home doesn't recognize C-" as a usable key.  If you do
this you may be preventing people dialing in from home from using parts of
emacs.

>*** Similarity of C-x u and C-x C-u can cause new problem rather than fix one

   You can always undo the changes if you make a mistake.  Undo is also
bound on C-_, so unless your terminal is braindead you don't have to use
C-x u anyway.  

   Users can always disable one or the other commands if necessary.  Since
you haven't proposed a better location for such commands, I don't see any
good reason to remove them. 

   I can also accidentally pull the SCSI cable out of my machine instead of
the printer cable.  That doesn't mean the cables shouldn't be put anywhere
near each other.  A little caution is all that's necessary.  And in the
case of emacs typing errors, they can be undone without any damage. 

>*** C-x C-f and C-x f should not do such wildly different things.

Same rationale as above.    
(note: I personally disable C-x f because I mistype frequently and almost
never change fill-column anyway.  That's not true of some people)

>
>* Remove dyslexia in commands, where possible:
>** C-x > and C-x < go in counter-intuitive directions as defined.

   There has been a lot of discussion about this over the years (as well as
the interpretation of scroll-up and scroll-down).  The problem is that
there are two ways to interpret the meaning of those commands, and one does
not seem to be any better than the other.  One interpretation of scroll-up,
for example, is to say "scroll the text in such a way that I perceive a
portion which is nearer the beginning, i.e. move my 'window' upward through
the text".  The other means "scroll the text upward while my 'window' stays
in place, effectively placing my window closer to the end of the buffer"
(the latter is the current meaning of the command).

   The same ambiguity exists in the scroll-right and scroll-left commands. 

   For some of us the existing commands are intuitively easy to understand.
For others, they are not.  Since there's no overwhelming choice for one
over the other, it's probably better to preserve the status-quo and not
confuse old users and new users (reading the manual) alike.  Changing the
meaning of these commands to do subtly different things seems like it will
create the same sort of problems you mention with the close association of,
e.g. C-x C-f and C-x f which "should not do such wildly different things"
since the key bindings are so similar.

>* Modify cursor controls in the direction of wordstar/turbo pascal/etc:
>** C-s, C-d, C-x, C-e  instead of C-b, C-f, C-n, C-p
>** C-a, C-f instead of M-b, M-f
>** Perhaps: C-q C-s, C-q C-d instead of C-a, C-e (conflicts with 1st req.)

   The current commands (C-b, C-f, etc) are highly mnemonic for
ctrl-Backward, ctrl-Forward, ctrl-Next, and ctrl-Previous.  The wordstar
commands, while they make some sense, aren't really necessarily any better,
especially in light of the rest of the command set you propose.  If people
really want wordstar editing keys, why don't they get wordstar-mode.el from
archive.cis.ohio-state.edu and use that?  That is a more complete emulation
of wordstar (which I have to admit I like second to emacs over all the
editors I've used)

>* In general, give ease of typing priority over mnemonics.

   That comment seems to imply that the current commands are difficult to
type.  I'm not sure I 100% agree.  I do admit that not having a real
functioning meta key makes life more difficult (I hacked up kermit so that
the alt key on my PC would behave like meta when I was dialing up), but
once you have one the commands are pretty accessible and easy to type.  I'm
curious to know how many other people in this newsgroup agree with the
sentiment.

   As a side note about things like the C-? vs. C-h controversy: Remember
that EMACS predates Unix by at least a couple of years.  People complain
about some of the keybindings in GNU Emacs because they don't correspond
with the default cbreak settings of most unix systems (e.g. C-c has a
different meaning).  That's because compatibility with the original EMACS
is preferred (by the authors, at any rate).  I also appreciate the fact
that I can run emacs on other operating systems (ms-loss, vms, etc) and
have a compatible environment.

Enjoy. 

---
Noah Friedman 
friedman@prep.ai.mit.edu
Newsgroups: alt.religion.emacs