bug#13841: 24.3.50; Regression - unreadable `C-h k' help

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

> > This is a REGRESSION.  With Emacs 23.4, emacs -Q C-h k, same
> > recipe, you see this:
> 
> The difference to newer Emacsen is that this menu command had been a
> quoted lambda in Emacs 23 (that didn't get compiled), and has been
> unquoted since then (good!).  So I guess it's not a regression since
> 23.4.

Not sure what you're saying about when or whether a regression
was introduced.

In fact, this is a regression that was introduced in Emacs 24.3
(probably you meant that, not 23.4).  In 24.2 and prior there
was no such problem.

Sure, it is a good thing in general that code gets byte-compiled.
That doesn't mean that everything is better, and this is one
downside to simply replacing (in effect) source code with byte
code.

A big advantage of Emacs and its use of Lisp is seeing into
and manipulating, at runtime, the programs that underlie the
behavior.  Simply replacing (in effect) source code with byte
code works against that introspection (whether by people or
by program).

If byte-compiling is going to be done in such an automatic,
blanket way, then perhaps a pointer needs to be kept to the
source code, for uses such as this.

In this particular case, at least, showing users byte code
is not helpful.  I hope we can all agree on that, at least.

And in this particular case, at least, a simple fix should
be to use a named function and not an anonymous one (in
`menu-bar-line-wrapping-menu').

But a more general solution should be sought to the various
problems introduced by the aggressive/eager byte-compiling
that is the underlying cause of this regression.