Re: GNU Emacs raison d'etre

[Karl Fogel <kfogel@red-bean.com>]

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 <kfogel@red-bean.com>
    To: Christopher Lemmer Webber <cwebber@dustycloud.org>
    Cc: ndame <ndame@protonmail.com>,  Emacs developers <emacs-devel@gnu.org>
    Subject: Re: What is the most useful potential feature which Emacs lacks?
    Date: Wed, 13 May 2020 23:08:04 -0500
    Message-ID: <87y2pvqhuj.fsf@red-bean.com>

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

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