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

[Drew Adams]

> If you don't mind the Lisp form, you shouldn't mind the byte-compiled
> form, either.

Excuse me, but this is sheer nonsense.  I find it really
hard to believe that you are saying such a thing, Eli.
You who care so much about reasonably understandable
messages and doc for users.

Emacs users often (perhaps usually) read straightforward
Lisp code.  They do not read byte-code (except for rare
exceptions - perhaps).

Source code is intended to be read by humans.  Compiled
code, not so much.

> And if you cannot read bytecode, you can disassemble
> it, then it should be as crystal-clear to you as the Emacs 23 vintage
> result.

Wunderbar.  That's what you want to offer users, as
opposed to fixing this bug.  Just tell them, when they
see gibberish from `C-h f' that this is no bug but Emacs
doing everything it can to help them. ALL THEY NEED TO DO,
to decipher the gibberish, is to disassemble it.

Sheesh.  Really hard to believe this.

> > 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').
> 
> Indeed.  And in any other case like this.
> 
> So let's stop talking about "regressions", and start talking about the
> real problem here.  Which also suggests an easy solution.

Well, it is a regression.  But if you don't want to talk
about it, then don't(!) - please just fix it.

> > 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.
> 
> A more general solution is not to have lambda functions hang on keys
> and mouse clicks.

That's not a more general solution to aggressive/eager
byte-compiling.  That's the same "easy solution" that we
should apply to fixing this regression.  But that's all
we need, to close this particular bug.