Re: Learning "my emacs" from the start

[florian@fsavigny.de (Florian v. Savigny)]

  > From: Thien-Thi Nguyen <ttn@gnu.org>
  > 
  > I agree OP's way is impractical and inefficient, but that doesn't mean
  > it is impossible or undesirable.  It's no problem for people to scope
  > out the joint before joining the party; the door is always open and the
  > Software is (as always, thank GNU very much) Free.  Too, some sidewalk
  > spectacle is its own reward, and keeps the puke out of the punchbowl...

Hmm. I am a bit unsure about what precisely you mean by "keeping the
puke out of the punchbowl" - would you mind explaining that?

Provided this expression does not completely change the meaning, I
understand you mean that it is an interesting experiment, to which I
would agree. It would seem to me that Hans' list of symbols function
could turn out useful as an additional diagnostic tool for people who
are trying to take a look behind the scenes for whatever reason, but
at the same time finding it to cumbersome to read the whole source
code of whatever package or functionality.

Nevertheless, Hans, I have to admit I still do not really understand
how you are going to understand Emacs better by looking at hundreds of
symbols (or maybe I have got something wrong). From my experience, the
Lisp symbols actually in use range from the highly important to the
rather obscure (i.e. those which only have a role for working around
some glitch, or which the programmer only introduced because (s)he had
no better idea, or whatever).

I am particularly puzzled because you are calling the learning curve
for Emacs amazingly steep. That might be true, even if I am far from
sure about that -- it would seem to me that the learning curve chiefly
has to do with the keybindings, which are manageable, and probably the
fact that there is always more to learn, but the latter is something
you do not HAVE to do, and otherwise actually a nice fact - you often
discover additional functionality as you start desiring it. (AKA
"There should be a function that...," followed by the discovery that
it actually already exists.)  But most importantly, I cannot imagine
how the learning curve with your method can be any less steep, instead
of, I imagine, about 10 times steeper.

As to the keybindings, I think you do have a point here, but the issue
is actually complicated. The double (not to mention even longer)
combinations a la C-x C-f can indeed be cumbersome if you need them
often. If, that is. C-x C-f is not a good example, because it is used
rarely enough not to make itself noticeable as cumbersome. And some
commands are so rarely used that it actually makes more sense to call
them with M-x and by their names.

Nevertheless, even if Microsoft bindings such as C-v for paste and C-c
for copy can be called a standard with good reason, given the
prevalence of Windows systems, I think you need to take into account
that those which "everybody" knows only call a small handful of
functions (I, for one, can think of C-c, C-x, C-v, C-o, C-p, C-a, C-s,
C-z, and C-y), and it is obvious that this scheme cannot accomodate
more than 26 commands. (Alt- always calls a menu.)  Thus, those
bindings are not that powerful if looked at closely, while the Emacs
bindings are almost infinitely extensible. I virtually never call a
menu when I work in Emacs. (When I do, I literally use them as
"menus", i.e. to have a look at what else is on offer.)

Second, from my experience, many grandmothers work at Windows PCs
without even using (or knowing) C-c and the like.

Third, the Emacs style of keybindings is also a standard (as, as I
suppose, the vi-style bindings are, but I have no experience with
vi). It is used, for example, on the bash command line, and in many
Unix programs.

Fourth, some, perhaps many, Emacs keybindings are more ergonomic: C-e
and C-a are easier to reach than End or Home, and M-f and M-b more so
than C-left arrow and C-right arrow. (And, arguably, reserving
Alt-Letter for menus can be called a design error in that respect.)
Marking a region is also more ergonomic...

What I do agree with is that the unfamiliarity of Emacs bindings can
turn people away from Emacs before they notice it is not actually a
big deal. (My impression is actually that it is important how memnonic
the key combinations are - M-f and M-b, for example, are easy to
remember, while C-w is unintuitive. It is natural to me now, but only
because I have used it for years.) What is also a bit of a problem is
the concurrence of the two standards - I regularly have to work in
LibreOffice Writer, and sometimes inadvertently use Emacs keys there.

Thus, it might be a really worthy undertaking to explore if it is
possible to find a scheme that reasonably reconciles these two
standards, i.e. finds the best subset, both in terms of memnonics and
ergonomics (but then I don't know anything about Mac bindings - still
different?). A bit like a Unicode for keyboard commands, that is.

Independently, the most useful approach is probably an individual
one. As others have pointed out, impractical keybindings do exist (C-c
C-o C-a, for example, for nxml-show-all, is really an absurd monster.)
But then it would be best to observe which functions you call how
often, and define really short keybindings for them. As others have
pointed out, you can always find such free short keybindings. And even
if you really don't, you can still redefine keys.

(My personal favourite for more rare commands is the style C-c a [abc]
for a related family of commands, i.e. using a single letter (here, "a")
as another prefix key. In this example, you'd get C-c a a, C-c a b, or
C-c a c, i.e. three commands which start with C-c a.)

By the way, is there a function analogous to open-dribble-file, which
records all the COMMAND calls (not keys), and which would enable you
to statistically evaluate how often you call which function? That
would certainly be of great help to anybody wishing to define more
keyboard commands that enable them to write more ergonomically.


[Sorry if this has got rather long. I have shortened, but now I am
running out of time.]

-- 

Florian von Savigny
Melanchthonstr. 41
33615 Bielefeld