contextual help on new features

[Joe Corneli <jcorneli@math.utexas.edu>]

Greg Novak recently kicked off a thread in the help.gnu.emacs forum,
entitled "Is Emacs becoming Word?".  What he appears to have meant by
this question is

  Emacs is becoming increasingly WYSIWYG (by default),
  and I find that annoying.

The replies he received were mixed.  Some people liked the new WYSIWYG
features.  Some people hated them.  Some people liked the fact that they
exist, but don't use them personally.  Etc.  We see discussions of this
nature in help.gnu.emacs fairly frequently.

The real point of the thread was - how easy is it to turn off new
features that you don't like (again, a frequent topic of discussion).

But also, more generally, how easy is it to make the most of new
features - to learn how to use them well (even if that means, for you,
turning them off).

I mentioned that it would be nice to have contextual help, of some
sort, on new features.

For example, the the first time "\pi" automatically turns into a greek
symbol in the current buffer, you might see a message telling you
what's just happened.  In addition to being informative, this message
should have an "actionable" aspect to it -- specifically, the user
could be given the choice to either "accept" the new feature, or
"reject" it.  Upon accepting the feature, this particual message would
go away.  Upon rejecting the feature, not only would the messages go
away, but your .emacs would get set up with a configuration item that
stops the feature from activating in the future.

The actual definitions of "accept" and "reject" are somewhat
context-dependent.  For example, the first time you get a prompt about
discarding undo data, "reject" should mean "don't prompt me again,
just do it next time!", *not* "don't discard undo data."  In some
cases, more than one option might be offered.  (Perhaps features could
be accepted on a trial basis, as in "Ask me again next week, I'm not
sure whether I like this yet or not.")

This does not seem so different from two things that we are used to in
emacs - `customize' and `disable-command'.  In effect, the suggestion
is "why not make new features 'tentatively-enabled', so that they run,
but also automatically display information about themselves, and
furthermore come packaged with the relevant customization apparatus?"

If implemented, I think that this suggestion would help support good
coding style.  New features would be sure to come packaged with useful
documentation and also with easy access to the code users need to use
them effectively.  

Accepting a new feature would be no more or less pain-less/-ful than
rejecting the feature, which would give users a sense of balance that
I think they many currently find lacking.  This idea could grow into a
somewhat enriched help subsystem, eg. "`rich-help-last-command'" might
not only bring up a buffer describing the last command, but also
provide relevant customization items.

I'm reminded a little bit of Word's annoying talking paperclip.
(Which no one seems to be able to figure out how to turn off.)  Of
course, the first feature that one should be able to turn off using
the new feature I'm describing here would be that very feature.

On the one hand, I might expect to get flamed now for promoting an
idea that already is already implemented, or otherwise
inessential/non-useful.  Well, I acknowledge that the basic components
of a system like this seem to exist, and its usefulness is a matter of
opinion.  On the other hand, I might also expect to get flamed for
promoting an idea that is too different from what emacs users are used
to, or too far off course from what the emacs project is aiming for
right now.  I can't really argue one way or another about that.

I will leave it to persons more experienced than me to think these
matters over.