GNU bug report logs - #13841
24.3.50; Regression - unreadable `C-h k' help

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Thu, 28 Feb 2013 17:04:02 UTC

Severity: minor

Tags: fixed

Merged with 20157, 20942, 39848

Found in versions 24.3.50, 25.0.50, 26.3

Fixed in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: michael_heerdegen <at> web.de, larsi <at> gnus.org, 13841 <at> debbugs.gnu.org, drew.adams <at> oracle.com
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 <at> oracle.com>
> Cc: michael_heerdegen <at> web.de, larsi <at> gnus.org, 13841 <at> 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.




This bug report was last modified 5 years and 81 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.