Re: Emacs learning curve

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 12 Jul 2010 22:53:24 +0200
> 
> A few weeks ago I was required to translate an old, small Visual Basic
> application to C#. I was less than thrilled with the job, but anyways
> the first thing was to configure Emacs as a C# editor. There is
> csharp-mode, which does code formatting. So far, so good. There are two
> methods for code completion, one based on CEDET and the other on an
> external tool. The CEDET method was a nonstarter, the other worked
> so-so. As I'm an absolute beginner on C# and it comes with a vast API,
> code completion was too much of a time-saver to be neglected. After 3
> hours trying to raise Emacs to the minimum usability level, I gave up
> and tried certain popular IDE, out of despair. 15 minutes later my
> client's application, on its basic inception, was running on the screen,
> mostly thanks to an accurate and fast code completion system that not
> only shows the candidates for completion, but also displays some
> documentation explaining what every method does. This saves a lot of
> time browsing documentation.

CEDET is a relatively new addition to Emacs.  I don't use it, but from
some comments by its maintainer posted here, it sounds like it needs
some work to bring it up to a reasonable level of usability for
newbies.  Like everything else in Emacs, this job needs motivated
individuals to step forward and do it.  I don't see anything in this
situation that could trigger this outburst:

>                                   It is disheartening to see how every
> time that someone proposes a tiny change on the default configuration
> for lowering the entry barrier, a vociferous group of reactionaries try
> to block the initiative, usually winning the fight, just because they
> don't want to add a line or two to their .emacs file.

What "reactionaries"?  All I see is a newly added package and a job to
be done with making it better, waiting (for a relatively short time,
up until now) for volunteers to do it.

How on earth evident problems with a single Emacs package can lead to
such extremist opinions?  Did you have an awfully bad day or
something?

> Emacs does just the opposite. See how people on this discussion says "of
> course the new Emacs user will read the Tutorial etc."

Contrary to what you've read, I maintain that reading the tutorial is
not a necessity.  Half of it describes issues that are common
knowledge nowadays, anyway (e.g., "If you want to insert text, just
type the text").  The other half is only needed for "advanced users".
Most of that is available through menus, so no need to learn the
keyboard keybindings, unless you are a touch typist.

We are keeping the tutorial and recommend that users read it because
of a certain policy.  I happen to agree with that policy, but I also
know that it has nothing to do with the ability to use Emacs
reasonably well, right from day one.

Of course, what you can do with Emacs from day one does not
necessarily include features like CEDET or Gnus -- but the tutorial
will not help here, either.

> IMAO the Emacs maintainers should ignore the winning and threatening of
> those users and focus on making Emacs as attractive as possible to the
> new generations of hackers.

Breaking news: There is no such thing as "Emacs maintainers".  There's
a group of people who contribute to Emacs development, each one in the
area of his/her interests.  (In addition, they fix bugs, as much as
their time and energy allows them -- but I hope you will agree that
what you want cannot be achieved by way of fixing bugs.)  Areas that
are not within the interests or expertise of these developers do not
get developed, no matter how important they are.  The support for
editing bidirectional text is a good recent case in point, if you need
one.

Conclusion: people who are interested in making Emacs more usable by
"new generations of hackers" should stop complaining, and instead
_act_.  Don't try to fix this or that isolated feature -- this just
tends to get bogged down in endless bike-shed arguments about defaults
and faces.  Instead, work out and present "The Plan" -- a list of
issues that need to be handled, infrastructure that needs to be added,
and features and packages that need to be developed or added, in order
to reach the goal.  Then start producing code according to that Plan.
There's nothing like a working code to convince non-believers (if
there are such among the active developers) and there's nothing like a
workable plan to attract followers.  If there's anything clear from
this confused thread, it's that we sorely need some kind of unified
"vision" and specific goals.  Throwing random ideas and critique will
get us nowhere.