Re: Making Emacs more friendly to newcomers

[Eli Zaretskii <eliz@gnu.org>]

> From: Sébastien Gendre <seb@k-7.ch>
> Date: Mon, 20 Apr 2020 00:44:40 +0200
> 
> - Alice: A long time user. She got a personal Emacs configuration she
>   had perfected over the years. She chose herself what system is used
>   to show function completion, which code parser is used for her daily
>   used languages. She add some packages to integrate with special
>   tools used at her work. Emacs is her home and office: She use it as
>   much for her personal project than for her work. She also made a
>   personal workflow with org-mode and write some personal Elisp
>   functions and advices. She forge the tools to her need. She do not
>   want to have an update of Emacs who break her configuration, her
>   workflow or her muscle memory.

There's a flaw in this description of how long-time Emacs users
concoct their configurations.  What's in their configuration depends
_heavily_ on the defaults: the features whose defaults satisfy such
users are never touched in the init file.  Any "vanilla" Emacs that
turns off many features will run a high risk of breaking such
configurations, because it violates the assumptions on which those
configurations rely.

At least, that's how I maintain my init files.

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages

The first and the most important problem with this is to identify what
you informally call "all the 2020 features, a modern interface, all
needed modern features to start coding with most popular languages and
easy to use for basic usages".  If you review past discussions on this
and related subjects, you will see that opinions on what should be
part of that set of features vary widely, so much so that I don't
believe any significant agreement is practical.  It _might_ be
possible to come up with a relatively short list of features that
could "modernize" Emacs, about which enough people will agree that
they should be part of "2020 features".  However, I'm not sure even
this limited goal is possible, and will continue to be unsure unless
and until someone comes up with such a list, and we see what's in it
and how many people agree on the list.

On top of that, the list (and the dispute to go with it) will need to
be updated with each major release.

Suppose we do have such a list -- will that be enough to make Emacs
sufficiently more attractive to Bob and his friends?  I don't know.
One problem is that we don't have many such Bob's on our team or even
reading this list, and those few who are very quickly become Alice's.
So their voice is never heard.  We don't have any HFE experts on
board, who could pretend to be a Bob.  So who will be able to
represent them and make sure the list of said features will be to
their liking?

> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything

I'm guessing that by "new" you mean all those "modern" features that
we don't currently turn on by default.  Otherwise, I don't see any
useful purpose for such a "vanilla" Emacs.

> And if Emacs detect, after an update or a first start, an already
> existing configuration that it could break because of some features:
> Emacs simply activate `vanilla-mode` automatically.

I don't see how Emacs can do that, when many dozens of optional
features are involved.  How do you write code that detects whether a
given feature can break something?  Ideally, we will have already
considered that, and make every effort not to break any existing
feature or muscle memory.  And who will write and maintain such code,
and update it with each release?  Are you aware of any other project
that does anything similar?

> It's just a starting point, but I think this could be a simple but
> very useful solution.

This assumes that someone does all the research and design and
implementation needed for that, and that we as a project commit to
maintaining these very non-trivial facilities for the years to come.
You may not realize it, but this is a very far cry from what we do
now.  For example, it is a long and frustrating uphill battle just to
make sure that NEWS provides information for how to get back old
behavior, for every one of those new features that do change behavior.
Please try to imagine (and describe to us, if possible) what kind of
development procedures will have to be put in place to support what
you propose, which is much more complex and problematic.