[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs learning curve

From: Óscar Fuentes
Subject: Re: Emacs learning curve
Date: Mon, 12 Jul 2010 22:53:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

grischka <address@hidden> writes:

>> Obviously, there is no reason to choose words perversely (e.g. use
>> "red" when we mean green).
> Or use "scroll-up" where it means scroll down, or use "split-horizontally"
> where it splits vertically ;)

Good one. Sometimes Emacs makes me wonder if I suffer from some type of
spatial disability.

The Emacs community has a more serious confussion discriminating what's
good and what's bad among two opposites, though:

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.

The mentioned code completion system on that IDE is a marvel for
beginners but, as it constantly pops on the screen hiding the code
below, maybe it is a pain for experienced hackers who know the API
well. Of course there is a knob for disabling it.

The crux of the matter is that the IDE comes ready to be as helpful as
possible for beginners, and adds options for turning features on and off
as you adquire experience. This is equivalent to saying that the IDE
comes preconfigured for making converts and then it assumes that as
those newcomers adquire experience they will learn how to adapt things
to their taste.

Emacs does just the opposite. See how people on this discussion says "of
course the new Emacs user will read the Tutorial etc." I was able to
write and run a basic application on a language that I barely know,
using a IDE for the first time, in less time that it takes to read the
Emacs tutorial. Translating the 5000 LOC Visual Basic application to C#
required less time than I needed for learning and configuring Emacs for
matching the usability level of my previous editor, ten years ago (and
now it wouldn't require much less work.)

The GNU project, and Emacs specifically, is about producing Free
software for the people. "People" here means all potential audience. In
practice, Emacs today is mostly focused on bringing incremental
improvements for current users, caring little about the demands and
expectations of the rest of world. 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.

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. Having gratuitous oddities, expecting a
sustained effort from the prospective user until he perceives the
virtues of Emacs, being dismissive towards competing tools instead of
learning why they are attracting more users than Emacs... is simply

The user who must be happy with Emacs is the user who doesn't know it


reply via email to

[Prev in Thread] Current Thread [Next in Thread]