Re: Is Emacs becoming Word?

[Joe Corneli]

   > But now I'm thinking that it might be even nicer to be able to get
   > help on the last event, or sequence of events... 

   I was thinking along the same lines and was just about to try to throw
   together a proof-of-principle bit of code.  When something odd
   happens, the user would use something like "M-x what-just-happened"
   and get info about what Emacs thinks its doing, how to shut it off,
   etc.

I think it probably wouldn't be too ungodly hard to write a
`what-just-happened' function (but I'm not sure).  

Like you pointed out,

   Retrofitting existing code to actually provide good
   context-sensitive information would seem to be a herculean task.

But nevertheless, documentation of this sort _should_ exist.  Unless
we're told how to turn things off (for example) we'll get confused.
Writing the documentation would probably be the hard part, patching it
in to `what-just-happened' seems like it would be relatively easy.

One thing that would be especially useful would be code that would
show where exactly the variables relevant to a certain event were set.

It probably isn't hard to say where a given variable is set.  The
difficulty is in specifying internally which variables are relevant
to which events.

   2) This will only help Emacs users who know that the
   what-just-happened command exists.  That is, the situation which
   prompted this discussion was that Emacs was translating certain inputs
   into special characters and I didn't understand why.  If I didn't know
   about the what-just-happened command, I would remain confused.

I don't think this is a huge concern, because if the command existed
it would be listed by C-h ? and either you'd have figured that out, or
you'd have posted here and been told about the command, then used it,
and probably still found it to be useful quite useful.  (I.e. once you
learn of the command it would reduce confusion many times, and you
only have to learn it once.)

   Advantages of the second (verbose minibuffer messages for tentatively
   enabled functionality) approach include:
   1) By design, the information only has to be added to new user-visible
   functionality.  This seems much easier than trying to bring a fully
   general contextual help system to fruition.
   2) Presumably all Emacs users read messages in the minibuffer, so the
   information about new user-visible changes will reach everyone as they
   encounter it, rather than having to go digging for it in the NEWS
   file, for example.  One could think of this as a dynamic way of
   reading the NEWS file.

   Disadvantages include:
   1) This approach cannot be described as unobtrusive.  All Emacs users
   would see an increased number of messages in the minibuffer, at least
   until they decide to permanently enable the new functionality.  

But it could be turned off.

   I've only recently started digging through significant amounts of
   elisp code, so I defer to the judgment of others concerning the
   feasibility of either of these two ideas.


The second one requires appears to be technically no different from
`disable-command'.  The first one is harder, but if you can write a
`what-just-happened' prototype, certainly people can begin to do the
gruntwork (german/english pun :)) to further populate its output with
useful documentation.