Re: Making Emacs more newbie friendly

[David Kastrup <dak@gnu.org>]

PT <mailshield.gg@mailnull.com> writes:

> On Sat, 19 Mar 2005 12:56:17 +0200, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> Some of the ``cool stuff'' is turned off because the veteran users
>> find it so annoying that they protest vociferously each time
>> someone suggests them to be turned on by default.
>
> And this is the wrong point of view. I'm a veteran user. I can turn
> anything off I don't like, but a newbie cannot turn the useful
> things on until he gets to know emacs better. The problem is they
> usually give up (at least the ones I met), because they miss the
> convenience features!
>
> I support turning every useful feature on by default. I don't really
>see how a veteran user can find anything annoying. I can put some
>lines into my emacs and I won't see that thing ever again.
>
> Newbies first! Veterans can fix anything they don't like.

And that is the wrong point of view.  If ``cool stuff'' is turned off
because the veteran users find it so annoying, the solution is not to
turn it on by default before it gets changed in a way that stops the
annoyance.

We don't need dancing paperclips, no thanks.  But that does not mean
that we don't need a help system at all.  Indeed, Emacs gives out
messages pointing out keybindings and stuff (and marks menus with
them).  But it does that in a way that does not hamper productivity.

If you take a look at the Emacs developer list, you will frequently
find long fights going on about features.  Basically, for something to
be enabled by default, it needs to have a history of working, of not
causing massive resource problems, of not blocking previously working
editing practices without an obvious escape route and so on.

And often, after long fights and arguments, the proponents then come
up with a solution that is so compelling that it gets adopted in
pretty unanimous agreement.

And that is a much more healthy process than the "let's throw
everything that's frilly on at once".  Yes, there are projects that
adopt that strategy, and people tend to fawn on them for a few months,
then drop them again.  For example, take the toolbar.  The XEmacs
toolbar is one of those distinguishing things that make me say "I
don't want to use that, it is so repulsive".  I can stand the current
Emacs toolbar, in contrast, for longer amounts of time without
aesthetic problems.  With the singular exception of Gnus, the icons of
which are absolutely garish.  Probably because they have been designed
to fit with XEmacs.

There are other things that are getting worked out, like enabling
auto-compression-mode and auto-image-mode: there are some cases where
using them causes inappropriate effects, and the trend in Emacs
development is not to integrate such stuff before the problems are
under control.

And this "don't enable it until it has a quality that makes it
unannoying even when you have only marginal use for it" strategy makes
for more solid results in the long run.

There is no sense in encouraging integrating half-baked stuff by
popular demand until nobody can do serious work without half a dozen
extensions interfering with productivity.  Emacs contains hundreds of
features that will be at most marginally interesting to most users.
If you have to configure a few dozen off before Emacs starts becoming
useful for productive work, you might as well forget about
proselytizing.

Font locking now gets in the vicinity where one can consider making
the default on.  Previously, it would make Emacs stall on large files,
not an acceptable default for serious work.  At the moment where using
it becomes more or less just a matter of taste instead of technical
necessity, and when the defaults are reasonably tasteful to appeal to
a larger audience even when exposed for longer amounts of time to it,
then the time has come to switch it on by default.  I'll switch it off
immediately again, but if I do so, it should only be because I prefer
pure black-on-white for everything as a matter of personal taste, not
because it impedes Emacs operation and human interaction.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum