RE: GNU Emacs raison d'etre

[Drew Adams <drew.adams@oracle.com>]

> >We made this very simple a few years ago: Just keep typing C-g.
> >I guess these users don't know that.
> 
> Sometimes they know that, but it's still stressful for them to have to
> do it.  They don't like the sensation of getting into state they don't
> understand, and then having to type a magical quit-key to get out of
> that state.  It makes them apprehensive about even using the editor --
> they feel like they got bitten.
> 
> >Can anyone thing of a better way to teach them about this?
> >It could teach them first about the minibuffer, then about C-g
> >to get out.  It could copy the current minibuffer prompt
> >into the help screen to make the explanation clearer.
> >
> >The tricky part is how to detect when a user could use this help.
> 
> I don't think the issue is ignorance about C-g.  It's that people have
> a relationship with software interfaces in which they're not accustomed
> to being bitten.  Even when the bite draws no blood, they still don't
> like the feeling.
> 
> I can see directly that they don't like the feeling, that it's
> upsetting to them.  I conjecture that part of the reason is that even
> if they quickly ascertain that everything's all right this time, they
> still have a (rational) fear that the next time the bite might actually
> cause harm -- e.g., that maybe they'll lose a file, or accidentally
> rename something, or that edits that they don't know about will be
> accidentally made somewhere.
> 
> I haven't actually asked new users if that's their worry, but on the
> now-rare occasions when Emacs bites me, I worry about such things.
> Also, I've been using Emacs long enough to know that most likely
> nothing harmful happened, and that if I patiently unwind the state I'll
> be able to figure it all out.  A newcomer does not have that comfort at
> first, and they can only acquire it through sustained exposure to the
> editor.
> 
> Again, none of the above is meant to suggest that Emacs should change
> something.  I'm just saying that we should be intentional about the
> kinds of users Emacs is likely to attract, and not make changes
> designed around people who are unlikely to be long-term Emacs users
> anyway.

I hear you, Karl.  Just a thought - sorry it's
longer than I thought it would be.

I think it makes sense for the Emacs tutorial -
or some Emacs tutorial(s) - to have users use C-g
right off the bat, in a realistic way.  In fact,
have them use C-g at various points in the
tutorial, to show what it can do in different
contexts.

Users should get to know C-g and some important
help keys right at the outset - and now and again
throughout the tutorials.  Doing stuff with Emacs
is a dialog with Emacs, including a lot of asking
Emacs and learning about what's going on in any
given context.

By having them use these things over and over, to 
different ends, tutorial(s) can help users learn
why they are important - how helpful they can be.

There's a tremendous amount of stuff you can
learn about Emacs, and you can learn pretty much
all of it by asking Emacs itself.  Learning how
to do that - at least some basic ways - gives
you a leg up.

I mentioned the `Whoops!?' submenu I add to the
`Help' menu.  It has 3 items:

 `Cancel Current Action' (C-g)
 `Back to Top Level' (no key; command `top-level')
 `What Did I Do!?'       (C-h l)

Regardless of whether we put such things in a
help menu, I think an Emacs tutorial should have
users use them a bit.
___

Yes, `C-h l' could still be improved.  But it's
useful as it is, and showing the output in a
tutorial can be a way to point out some key
notation, including pseudo function keys.

The first thing to point out about `C-h l' output
are the keyboard key sequences.  They, at least,
are recognizable, once you know the notation.

We can also say what things like <down-mouse-1>,
<help-echo>, <menu-bar>, <view-lossage>, and
[view-lossage] represent, in general.  That way,
the output isn't so scary or just a wall of vomit.

Knowing in general what you're looking at, even
without understanding it, lets you see past what
(to you at that point) is just noise, to some
meaningful signals that you can recognize (e.g.
keyboard keys).
___

And of course, tutorials that get into some Lisp
can get users acquainted with more powerful ways
to ask Emacs.

Some of the things that are obstacles, because
Emacs is maybe not helpful enough regarding them,
can be subject to (later) tutorial explorations.
How to find out about faces, highlighting, chars,
overlays, fringe, mode-line, etc.

Someone who uses Emacs to work quickly, as Karl
suggests, knows Emacs well in one sense.  Someone
who knows how to dig in and ask Emacs things about
itself knows Emacs well in another sense.

Knowing something about asking Emacs provides (1)
self-confidence, (2) power to learn further, and
(3) knowledge that you can find out, yourself,
how to learn further _further_.  It's an eye-opener
to learn that Emacs is pretty much interactively
transparent all the way down.