Re: GNU Emacs raison d'etre

[Karl Fogel]

On 17 May 2020, Dmitry Gutov wrote:
>>> 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.

The nature and variety of a newcomer's problems with Emacs depends a lot on how 
much coaching the newcomer is getting from someone with more experience.

But even with good coaching, it takes a long time for Emacs to become "worth 
it", by which I mean "better for that user than the J. Random Popular Text 
Editor they might have gone with instead".

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

Thanks for the explanation.  I haven't used it myself nor seen anyone else use 
it, so I don't feel confident in saying one way or the other whether it would 
help beginners.  Next time I'm teaching someone, maybe I should try it, though.

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

Thanks -- glad that helped.

>>> 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 another message I sent a moment ago, I replied to the above (via someone 
else who was quoting you), so I'll repeat that part of my response here:

  > While "friendly to newcomers" means something on its own,
  > "user-friendliness" only means something after one has characterized
  > the users in question.  That's the main point I've been trying to
  > make: that there is no such thing as a generic user, so we have to
  > make decisions about which kinds of users to optimize for.
  >
  > In most UI/UX conversations (not necessarily here, but on the Net in
  > general), most of the time people unconsciously say "user-friendly"
  > as a synonym for "easy for newcomers to pick up quickly" -- without
  > realizing that it also implies "tends not to reward sustained
  > investment", since these two qualities inevitably trade off.
  > 
  > So if we characterize our users as "those who see, or who have the
  > potential to see, the value of making a sustained investment in
  > their text manipulation environment", *then* yes, by all means Emacs
  > should be user-friendly.  But if we're saying "user-friendly" in the
  > colloquial sense that most people use the term in, then no, I think
  > it would be a mistake for Emacs to aim for that.

I wish that the first thing they would teach in UX school is to stop using the 
term "user-friendly" :-), much as medical professionals are (I'm told) taught 
to stop saying "throw it away" because there's no such thing as "away" in a 
hospital -- each kind of medical waste needs to be disposed of by a specific & 
suitable method.

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

Well, I'm not sure exactly what "professional software" means in this context, 
but if it means "expects the user to make sustained investment", then I agree.

Best regards,
-Karl