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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 30 Apr 2016 09:20:38 -0800 (GMT-08:00)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: michael_heerdegen@web.de, larsi@gnus.org, 13841@debbugs.gnu.org
> 
> > 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.

Lisp code is not documentation.  I find it really hard to believe you
are saying such a thing, after filing so many bug reports about
unclear and unusable documentation.

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

They should read neither as documentation.

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

But neither is documentation.

> > 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.

No, I'm saying that we should not show code as documentation.

> > 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.

Yes, it is.  If no code is show as documentation, aggressive/eager
byte-compiling will hurt no one.