Re: Emacs learning curve

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > I think it is more reasonable to add alias, perhaps make some commands
 > non-interactive and add new ones with the "new" terms, and replace all
 > references on the Emacs manual (not the Elisp manual) to use the new
 > terms.

Well, we already have some of that (cf the `next-line' command vs. the
`forward-line' function), but I can't say I'm a big fan of it even as
limited as it is.  It also has the major huge defect from your point
of view that it enables the COFs ("cranky old fart") to continue
coding in traditional Emacs LISP, so you have the worst of both
worlds: good code written in the traditional dialect which the
newcomers have difficulty reading, and code of really ambiguous
practicality (ie, CRAP) written by newcomers in the newfangled dialect
(remember, in current LISP most commands that have very similar
functionality to separate API functions are duplicated in this way
because they have have DWIM-ish aspects that make them inappropriate
for use in programs).

 > I don't see why old timers would have a problem with this. After
 > all, if we expect from every newcomer to learn Emacs-ish,

As Drew points out, we don't have to connect Emacs-ish to LISP naming,
though.  Most newcomers are users who learn keybindings or discover
commands via the menus, and don't program or use LISP command names at
all (they refer to commands by their bindings, not by their names).
Most new programmers among those new users actually use macros for
almost all of their programming.  Most new e-LISP programmers among
those new programmers use a very small fraction of all Emacs commands.
The small fraction (5%? 1%?) of all new users who actually go on to
program modes etc will mostly be using existing code as a model for
the arcane stuff.

 > we can expect from the veterans to learn that Paste means the same
 > as Yank (in case they still don't know.)

And how do you explain to newcomers why "Paste" is on the C-y key?
Currently most one-letter control chords have mnemonic names (f =
forward, p = previous, y = yank, etc).

Also, to me at least, "paste" does not mean the same thing as "yank".
Yank is an operation that communicates between the Emacs kill ring and
an Emacs buffer.  Paste is an operation that communicates between a
system data store (in my case, either the X PRIMARY selection or the
Mac clipboard) and an Emacs buffer.  The semantics are therefore
subtly different, and in fact this is valuable to me because most of
the stuff on the system clipboard is useless to my Emacs work, and
similarly almost nothing on my Emacs kill ring is useful outside of
Emacs.

 > Sure, there are technical details, none hard, although maybe a bit
 > controversial... Oh, wait!

Oh, wait! is right.  Many people have the old versions embedded in
private modes, additional functions, skeletal library templates, etc,
both in use and as quoted boilerplate for inserting into new code.
Not to mention people who are using older versions with some
backported code, as well as forked projects.  While none of these are
a consideration for Emacs as such, if those users or projects abandon
work on Emacs or related projects, it will be a loss to Emacs.
Balanced by what gain?  I don't really see much gain; people who use
and program Emacsen are a special breed, and I don't think it's the
particular LISP dialect that puts up the largest hurdles to newcomers.

 > > It would be much easier to get support if you create such a pictorial
 > > vocabulary for use by new users and non-programmers.  Bonus points for
 > > making it possible to create a "keyboard macro" using only the mouse,
 > > translate it to Lisp, and associate the pictures with the appropriate
 > > Lisp commands.  And of course much of the relevant vocabulary will
 > > already be present in collections of icons provided by GNOME et al.
 > 
 > Not really, the long term investment should be to teach modern terms to
 > Emacs, instead of insisting on forcing every newcomer to learn the Emacs
 > terms.

Please reread what I wrote.  My point *is* to teach Emacs a modern
vocabulary.  However, the one I propose doesn't have the defects I
point out for changing LISP above, because it's used in a completely
different context that does not conflict with historical LISP
definitions.