RE: Tutorial incorrectly thinks emacs -Q uses customizations. Alarmist and confusing tutorial intro.

[Drew Adams]

> Could you please propose a better text?

As I said, I prefer that we not use this.  I think it has a negative effect.

> I am not quite sure "had" is incorrect here. The state of the TUTORIAL
> buffer may have changed since the link was created. Is not "had" the
> correct word then? Or how would you say it?

I wouldn't say it. I would just say something generic, without trying to
determine whether the user had actually customized Emacs. Something short
and simple, such as this:

"Keys mentioned in this tutorial are those defined by default. If Emacs has
been customized, then some keys might differ from those mentioned here. If
you want to use the tutorial with the standard Emacs keys, then start Emacs
again using `emacs -Q'."

IOW, "YMMV".

This need not be in red, and it need not be the very first thing the user
reads. It should not be. Put it after the first place where the tutorial
asks you to use a key, as a footnote. "YMMV" belongs in the fine print (more
or less).

> These text should only be showed if some of the key bindings used in the
> tutorial have been changed. In other words they are only showed when the
> tutorial does not work.

I don't agree that that is worthwhile. Just let users know that the tutorial
is written for standard (i.e. default) Emacs bindings. That's all.

The tutorial should not (IMO) be mostly about teaching keys, anyway. If it
is, then that's a mistake. Keys are only a means to Emacs functionalities;
we shouldn't concentrate too much on them.

Users can learn Emacs using emacs -Q, and they can then learn different
bindings afterward, if need be, for their customized version.

> We discussed what to do in this case earlier. We decided then that the
> best way to handle it was to tell the user about the problem. Other
> alternatives was to refuse to run the tutorial or to change the key
> bindings in the tutorial buffer so that they matched the tutorial.

I think the cure is worse than the disease. There is no reason to refuse to
run the tutorial or to try to adapt it. Just let users know that it assumes
standard (default) bindings. Keep it simple.

Users should get the same behavior each time they use the tutorial, whether
with customized or vanilla Emacs - any other behavior is confusing.
Referential transparency and all...

> Some more work can be done on this. It fails with very long names if I
> remember correctly now. But I felt this was good enough.

It's not needed. I don't think users who have customized versions of Emacs
really need to be told just which bindings have changed. It's true that some
of the tutorial won't "work" or even make sense to them without knowing
which keys to use, but it should be clear that they can always use the
tutorial with emacs -Q. We don't need to make the tutorial work for
customized bindings.

> I am not sure what is best. Of your proposals I like the first one best.
> What do others think?

None of them are needed. I shouldn't even have mentioned them. My point was
that what is there now is harmful, because confusing (and scary).

> > Another bug, unrelated to the tutorial: Clicking
> > `delete-backward-char' does
> > not show its binding (DEL).  The doc string needs to mention this.
>
> This is disturbing but maybe a bit hard to fix right now. I would rather
> put that in TO-DO for after the release.

`delete-backward-char' is a built-in function. It should be possible to fix
this detail. (Again, it has nothing to do with the tutorial.)

> > Most importantly: Do we really need this?
>
> Yes, I believe we need it. The idea is simply to tell the user let the
> user run the tutorial even though some things have changed, but inform
> the user what has changed. I think without this the user may get very
> confused when the tutorial does not work.

The confusion is 100x now. I see no need for the user to run the tutorial
using customized bindings.

If you could automatically adapt the entire tutorial to reflect the user's
bindings perfectly, then I guess it could be OK (but see above, about same,
repeated behavior). However, that is too difficult, and any half measure is
worse than none at all.

> Whether this is the best way to handle the problem with changed key
> bindings that affects the tutorial is another question (see above).

That's the question. My answer is "No".

> > This is crazy.  This is the FIRST thing that a newbie will see, when
> > trying to learn about Emacs.
>
> If no key bindings have been changed the user will not see this. (When
> the bug has been fixed.)

That bug really needs to be fixed, at a minimum. Right now, we're scaring
100% of the people who try the tutorial 100% of the time. Messing their
minds, to no good end.

> > Please, let's drop this or redo it completely.  If we keep it, it
> > needs to be 1) simple, 2) unalarming, 3) obviously of secondary
> > importance.  A tutorial should hold you by the hand in the beginning,
> > not scare and confuse you.
>
> IMO this is the wrong level to discuss it on. We should rather discuss
> the GUI instead and how that can be used to teach the user Emacs. After
> the release of course.

Fine, let's discuss the GUI and the tutorial and lots more after the
release. But let's please pull this enhancement now; it's not ready for
prime time.

The last thing we want the tutorial to do is confuse and scare new users.
Emacs already has a reputation for being difficult to learn and use. And
supposed key-binding madness is a big part of that bad rep. The tutorial
should make you feel self-confident, showing you that *YOU CAN* use Emacs
without being a key-binding wizard. If bindings are getting in the way, then
the tutorial has not done its job.

I feel so strongly that it is not mainly about learning keys, that I
wouldn't mind if the tutorial started with just the menu (which requires no
explanation to start using), but we've been down that path before...