Re: GNU Emacs raison d'etre

[Dmitry Gutov]

On 14.05.2020 07:56, Karl Fogel wrote:

> 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.

Actually, those examples are closer to the discussions I have taken 
part in (let's not change xxx because existing users will complain; and 
the newbies will just have to get in line, the entry barrier is high 
anyway, who cares if they have to learn one more thing to get started).

On the flip side, I don't remember anybody propose to make key bindings 
less "staggered".

> 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.

I think we already do (the rest flocks to #1, #2 and #4 popular 
options). No need to try harder in that direction.

> 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.

That feels like giving up. And "worth it" depends on personal 
expectations. From reading comments on Reddit, converts from Vim, for 
instance, try Spacemacs or Doom Emacs, and seemingly become satisfied in 
a matter of days.

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

Not sure what you have in mind here. If it's a "here's not an Emacs 
would solve a problem", this could turn into a useful tutorial for 
journeyman emacsers.

> * 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.

Not a bad advice, but deciding on such a list in official documentation 
might not be easy (people have opinions). Once we do decide, it would be 
better to try to improve these things first.

> 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."

I still don't like it. It either means "you don't get much until you 
struggle for a while" (which just sounds discouraging) and/or "no other 
program comes even close at text manipulation", which is... pretty 
conceited and kind of limited at the same time. I mean, Emacs is great 
and all, but I don't have "text manipulation" as the #1 goal in my life. 
Or even among top 10 goals.

The higher-level things one can implement with Emacs Lisp are a lot more 
interesting.

> > 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.

Okay, but is it still a problem after they've tried Emacs for a day, for 
instance? For a week?

These periods of time would of course suggest Emacs is not ideal for 
total newbies, but they're not the kind of "sustained investment" you 
described either.

> > 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.)

You press 'C-x', wait a while - and it pops up a window with the 
descriptions of all commands whose bindings start with 'C-x'. Same for 
all other "incomplete" key sequences. Looks pretty handy for beginners.

> 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.

Yes, ok. Maybe this one is harder to improve that some others.

> > 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.

It's not like extreme user-friendliness was ever a guiding principle 
here. :-)

In this we're, again, similar to other professional software.