Re: Emacs learning curve

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 14 Jul 2010 00:37:30 +0200
> 
> Read again my message and you see how between the two paragraphs
> you quoted there is a lot of substance.

That substance seemed unrelated to the outburst.  Basically, I don't
understand how a bunch, even a large bunch, of usability problems
could lead to far-fetched (and IMO wrong) conclusions that Emacs
development is controlled by a band of reactionaries.

> > Contrary to what you've read, I maintain that reading the tutorial is
> > not a necessity.
> 
> I'm not sure about this. Maybe we should experiment with a few seasoned
> hackers who never used Emacs and observe if they reflect surprise or
> confussion about some features that are contrary to all their previous
> experience, without perceiving any advantage on them.

I already conducted those experiments, on my daytime job.  None of the
users whom I introduced to Emacs ever read the tutorial.

> >> 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".
> 
> Well, call them by some other name, but the maintainers I'm thinking of
> are those with the power of making controversial decisions against the
> opinion of other prominent Emacs contributors. Currently they are Chong
> and Stefan, AFAIK.

None of whom said anything against better usability so far.  And
Yidong did most of the hard work of integrating CEDET into Emacs to
begin with.

> This is fine with me, as far as those people do not stop development,
> advancement, change or whatever you call it, on other areas.

I don't recollect any incident that would go by that handle.  There
was a lot of tiresome longish discussions about defaults for this or
that option, but I wouldn't recommend generalizing them to something
as significant as what you are talking about.  That's why I suggested
not to start arguing about options, but instead to present a vision
and a plan.

> One related
> example comes to mind: when the bug tracker was discussed, some
> maintainer of a key package threatened with stopping his Emacs work if
> the tracker's interface was such and such (being "such and such"
> precisely the kind of UI which is considered the most open and
> user-friendly for beginners.)

How's this relevant to Emacs features and usability in general?  Did
anyone suggest a change that was rejected because it was incompatible
with the bug tracker?

> Well, I was thinking on that plan, because I'm working on a project that
> is tangential to this, so I was even considering to write an sketch and
> submit it here just in case there is something on it that is unaceptable
> or someone proposes an improved strategy. Guess what? there was no need
> for it: was smashed a few post above.

I didn't see anyone smashing the plan, because no plan was ever
presented.

> * Follow the GNU guidelines wrt the programming language. There is quite
>   a bit of personal, questionable opinions there. But well, maybe we
>   could devise a design that buries the "ugly" code out of sight (I
>   share the opinion about the uglyness, but I must take on account the
>   usefulness of the beast. Besides, some C code in Emacs can rival a C++
>   template meta-programming library on terms of readability.)

If you read those parts of the Standards document carefully, you will
see that they are merely _recommendations_.  A case in point is the
Groff project: a very old member of the GNU family, it was implemented
in C++ from day one.

Anyway, I'd expect most, if not all, of the usability-related job to
be done in Lisp, so I see no problems with the choice of programming
language here.

> * When there is a GNU package for doing something, use it instead of a
>   non-GNU one. It doesn't help much that the non-GNU package is
>   compatible with the GPL. Given the nature of the GNU project, this
>   makes sense, as long as the GNU package is a match for the non-GNU one
>   on terms of how good is it for the job. However, as we have
>   experienced recently, an inferior GNU system triumphs over a superior
>   non-GNU one, hoping that, eventually, the GNU system improves. There
>   is little point on convincing the key people about the slight
>   possibilities of seeing those hopes ever realized.

Is this even relevant?  Did someone analyze what external packages are
needed for the job at hand and presented that analysis?

Giving up because of theoretical complications doesn't sound wise to
me.

> * Unless it is something accessory that does not conflict with existing
>   code, the plan must be technically acceptable for an overwhelming
>   majority of the key Emacs hackers. For a plan that introduces
>   significant changes, this happens with less frequency than the
>   alignment of the four outer planets of the Solar System.

Again, is this relevant?  What "significant changes" are we talking
about?  I would imagine a specialized package, perhaps built based on
CEDET, and/or specialized mode.  These can be turned on and off; those
"reactionaries" who don't want these features will never turn them on,
or at worst will turn them off in their ~/.emacs.  Puff -- the problem
is gone.

> * Ditto for the UI changes included in the plan. This is, possibly, even
>   more difficult. Once you have write access to the repo you are on your
>   own for changing things (or you can work on your own branch) but some
>   existing users will complain out loud if they are suppossed to add a
>   line to their .emacs for keeping the previous behavior. Think about
>   something that changes some core piece of Emacs philosophy.

See above: start with making it an optional feature that is off by
default.  If it's good, it will eventually be turned on.  There were
enough examples of that in Emacs history.

> > 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)
> 
> Sorry, only for the GUI infrastructure, this would be a multi-year
> effort (working an average of 10 hours per week.)

Yeah!  But even a 1000-mile journey begins with a single first step.
If no one will ever make that step, the journey will never end.

In other words, the fact that a significant effort is required is just
a test of the will and motivation of those who are the most profound
critics of the current state of Emacs usability.  If the motivation
and the will power are high enough, they will pass that test with
flying colors.

> But it doesn't matter, because my plan was already rejected.

No, it wasn't.  Don't give up too early.  Most of the complications
and obstacles you see are imaginary, or could made to be so, given
some creative thinking and positive attitude.  Be prepared to listen
to the old guard and respect their opinions, and be prepared to look
for ways to compromise that don't defeat your goals.  It's not that
hard.

> > 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.
> 
> I completely agree, but it is in contradiction with what you wrote above
> about every developer scratching it itch.

I was hoping the Plan will attract new developers with the right itch.