Re: Emacs learning curve

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

[snip]

> 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?

If you do selective quoting and paragraph reordering for reaching a
negative opinion, I'm left wondering who of us is having an awfully bad
day. Read again my message and you see how between the two paragraphs
you quoted there is a lot of substance.

>> 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.

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.

[snip]

> 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.

As is implicit on the message you quoted, the features provided by CEDET
are a must-have if you pretend to advertise Emacs as a productivity
boost for certain tasks which are becoming more prevalent as time
passes, so those features should work (and work well) from the very
moment the user visits a file where they are applicable.

>> 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.

> 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.

This is fine with me, as far as those people do not stop development,
advancement, change or whatever you call it, on other areas. 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.)

> 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.

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.

It seems that a workable plan here must meet the following conditions:

* 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.)

* 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.

* 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.

* 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.

> 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.) But it doesn't matter,
because my plan was already rejected.

> 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.