Re: GNU Emacs raison d'etre

[xristos <xristos@sdf.org>]

On Thu, 21 May 2020 11:33:25 +0200, 
Arthur Miller <arthur.miller@live.com> wrote:
> Indeed. But for anything to live long, it needs to adapt to changs, and
> software/IT community changes rapidly. That seems to be basic law of
> evolution. Emacs does not seem to adapt despite being super adaptable
> software package so well. Is community big enough to be sustainable in
> long term?

Emacs has lived long, hasn't it? It is certainly one of the longest-living
pieces of software that I use daily. This could mean that Emacs has adapted
well to changes in the field or that said changes were fads, not worth
adapting to. Either way, it seems the model that lies at the core of Emacs
has stood the test of time. 

>> In my eyes, Emacs is doing an outstanding job on that.
> Personally I don't think Emacs will go extinct any time soon, neither,
> but what will happen in next 40 years? 

No one can tell what will happen in the next 10 years, never mind 40.
It is a mistake to make decisions by working backwards from a hypothetical
projection rather than looking at the past and recognizing what has made
Emacs truly unique:

Its capacity to symbiotically [1] mold with the user and give raise to a
metasystem [2] that is much more than the sum of its parts. If Emacs has a
superpower, that is it.

> Is it important though? But I would like to see bigger community now so
> we get even more developers and even better Emacs :-)

That would be nice, but Emacs should not compromise on its core values in
order to achieve it. Emacs can not win going toe-to-toe with VSCode but
it can certainly shift the arena from not-quite feature parity with
fad-editor-of-the-decade [3] to doubling down on user-empowerment:

A lot of Emacs users, even old users, don't see Emacs as anything more than
an editor and haven't been exposed to the "moldable information processing
tool" way of thinking. This should be addressed by us doing everything we
can to shorten the time needed for a new user to first be fully exposed
to this paradigm and subsequently ignite the molding process.

I see João admit that he's not familiar with a lot of the C-h commands.
This is a problem that should be easy to fix. I've long seen the Emacs
tutorial as unnecessarily narrow-minded in its focus on text editing.
Richard mentioned a robot game but I suggest the tutorial be reworked
instead to be much more extensive. It should first lay out the models that
make Emacs powerful and then through exercises expose the user to said
models and reinforce the central paradigm.

That should include familiarization with all introspective commands,
configuration and customization, how buffers and processes work, and a
practical introduction to Emacs Lisp, including showing IELM and what one
can do inside it (e.g. Set working buffer).

I think this would go a long way towards letting users have a glimpse of
the possibilities on offer. Emacs has great manuals but either very few
newcomers read them or if they do, still don't get the big picture.
An interactive, hand-on approach would surely work better.

[1] https://groups.csail.mit.edu/medg/people/psz/Licklider.html

[2] https://xristos.sdf.org/why-emacs.txt

[3] That's not to say that Emacs should not provide VSCode features where
    it makes sense to do so. But the moment you start compromising on
    core values (e.g. providing a singular model that everyone should adopt
    and making alternatives hard or impossible to do) is when things start
    to go wrong since you're fighting the essence of what makes you great.
    I haven't so far seen anything here that makes me believe this will be
    the case but it's something to think about.