Re: GNU Emacs raison d'etre

[Karl Fogel]

On 14 May 2020, Dmitry Gutov wrote:
>Yes, the tradeoff is somewhere in there, but my problem with the
>conclusion is that it would be really easy to misapply your principle 
>(e.g. by saying we don't need fancier buttons, even though we probably
>do, or that the Getting Started guide is good enough and doesn't need 
>improvement, and someone should go work on specialized Org-mode docs
>instead).
>
>Making good use of it seems difficult.

Any guiding principle can be misused, but that doesn't make it useless.

The particular misuses you cite above are speculative -- no one's actually 
saying those things, as far as I'm aware.

In a reply to Christopher Lemmer Webber just now [1], I got a little bit more 
specific:

  > If we just say "Emacs should be easier for newcomers to learn",
  > that's not a useful rallying cry IMHO.  If we say instead "Emacs
  > should try to attract newcomers who have a higher-than-average
  > probability of becoming high-investment users, and should explain
  > early on to those newcomers what the road ahead looks like", *then*
  > we have a high-level guiding principle we can actually use.

So there's some concrete guidance about *how* we might seek to improve the 
Getting Started guide (and other things like the Emacs web site, starter 
videos, etc):

* Tell newcomers up front that Emacs really starts to be worth it after a few 
years, not a few weeks.  Set expectations right from the start.

* Show them some of the abilities they will eventually have, so that they can 
see why it's worth it to make the investment.

* Also tell them about the ways in which Emacs may frustrate them along the 
way, and explain that those frustrations are common and are sometimes 
inevitably entangled with the same things that make Emacs winning in the long 
term.

I find it fairly easy to come up with ways in which this principle would 
provide guidance in certain decisions.  I could try to list more of those ways, 
if it would be helpful, but I just don't want to get into a sub-discussion 
about each such example.  It's meant to be a high-level principle, after all.

Ultimately, I personally find it helpful in thinking about how to teach Emacs 
and how to write packages.  Here is the principle, reworded slightly after a 
suggestion from H. Dieter Wilhelm:

"GNU Emacs's raison d'être is to be the text manipulation environment that best 
rewards sustained user investment."

Apparently some other people here find it useful as well.   You might or might 
not be one of them, but I can at least promise you that I'll never use this 
principle to make bad suggestions about ways in which Emacs should be made 
unfriendly to newcomers :-).

>The kind of person who *could* make a better judgment in this area is
>someone who specializes on UX. And they are rare guests around here.

More UX expertise would always help, naturally, but those of us who are here 
are not wholly ignorant of the field either, nor of the questions and tradeoffs 
that need to be dealt with.

>Are you sure that this particular aspect is _bad_ for new users, though?

Yes.  I am sure.

I've taught Emacs to a lot of people -- scores of them, at least; I don't keep 
track, but the sample size is large enough to be beyond merely anecdotal at 
this point.  I've watched newcomers run into the same obstacles over and over, 
and this particular obstacle is always one of the first they encounter.

>Nobody likes to stretch they hand too far. But I'll grant you
>this point, that Emacs is *somewhat* on the side of high-investment
>here.
>
>This part is expected of a professional tool, however, and the
>experience for newcomers could be improved without taking away much
>from the "oldies". See the 'transient' package, for example, recently 
>proposed for inclusion on emacs-devel.

I don't have any experience using 'transient', so I'd need more explanation 
from you to understand what you meant by that part.  (I tried to understand 
'transient' from reading [2] and [3], but unfortunately -- and somewhat 
surprisingly! -- the documentation at those pages does not give a single 
concrete example of transient's use.)

However, your assertion that "the experience for newcomers could be improved 
without taking away much from the 'oldies'" is exactly what I'm arguing is not 
true.  I actually think we can't (much) improve this particular part of the 
experience for newcomers without taking away one of the things about Emacs that 
most rewards investment.

The newcomers who eventually *do* become experts do so in part by first 
stumbling across new commands accidentally (in that crowded keybinding space) 
and then using help tools like `C-h l' to see what they just did.  So one of 
the things we should prioritize is teaching newcomers how important those help 
facilities are and how to use them in a smart way.  I'm specifically saying 
that this is *more important for Emacs than it is for other editors*.  Sure, 
users of (say) the Atom editor should eventually know how to use the built-in 
help there too.  But it's a difference in prioritization: for Emacs users, 
using that built-in help is more important than it would be in other editors, 
and the methods and circumstances of using the help are different too.  So we 
should incorporate that fact into how we present Emacs to new users.

(Again, this is from at least some experience.  The users I've taught who have 
gone on to become proficient Emacs users are ones who invested very early in 
learning the various help facilities and when to use them.)

>Some of them, probably. At this point, I think, there are still a lot
>of decisions that would bring us closer to newcomer-friendliness while 
>keeping no worse high-investment compatibility.

That could be true, though I'm a bit more skeptical than you are.  In any case, 
it does not make the principle inoperative; it is consistent with the principle.

I believe we'll make better decisions if we keep in mind that "friendly to 
newcomers" is not, in itself, the primary goal.

>I'm glad that we both like LSP, or at least the idea of it.
>
>But it seems these days almost everybody wants it, except for MS Word
>and Notepad users.

Yes.  High-investment users, however, see more possibilities from LSP than 
low-investment users do -- they'll go farther with it.

>There are certain aspects where LSP is not exactly perfect: the
>functionality it allows is limited by the protocol, and by LSP servers 
>available currently. It's an "ecosystem amplifier", or maybe an
>equalizer even.
>
>I mean, it for sure is great, not to be lagging in language support
>for a whole number of languages where we did before. But there are
>different protocols that allow more powerful extensibility. nREPL, for
>example.

Ah, that's a technical question about the suitability of LSP for a particular 
problem space, and I'm not well-informed enough to have a useful opinion there. 
 If you say nREPL, I'm not going to argue! :-)

Best regards,
-Karl

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01893.html

    From: Karl Fogel <address@hidden>
    To: Christopher Lemmer Webber <address@hidden>
    Cc: ndame <address@hidden>,  Emacs developers <address@hidden>
    Subject: Re: What is the most useful potential feature which Emacs lacks?
    Date: Wed, 13 May 2020 23:08:04 -0500
    Message-ID: <address@hidden>

[2] https://github.com/magit/transient/blob/master/lisp/transient.el

[3] https://emacsair.me/2019/02/14/transient-0.1/