[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#13841: 24.3.50; Regression - unreadable `C-h k' help
From: |
Eli Zaretskii |
Subject: |
bug#13841: 24.3.50; Regression - unreadable `C-h k' help |
Date: |
Sat, 30 Apr 2016 20:29:56 +0300 |
> 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.