GNU bug report logs -
#13841
24.3.50; Regression - unreadable `C-h k' help
Previous Next
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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13841 in the body.
You can then email your comments to 13841 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Thu, 28 Feb 2013 17:04:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 28 Feb 2013 17:04:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
emacs -Q
C-h k
Then choose menu item Options > Line Wrapping in This Buffer > Truncate
Long Lines.
You see binary output instead of useful help:
<menu-bar> <options> <line-wrapping> <truncate> runs the command #[nil
"ILLEGIBLE, INCOMPREHENSIBLE BINARY INCANTATIONS" [visual-line-mode
word-wrap 0 nil toggle-truncate-lines 1] 2 nil nil], which is an
interactive compiled Lisp function.
It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
(anonymous)
Not documented.
For reference wrt this regression, this is what Emacs 23.4 shows
instead - much more readable and helpful:
<menu-bar> <options> <line-wrapping> <truncate> runs the command
(lambda nil (interactive) (if visual-line-mode (visual-line-mode 0))
(setq word-wrap nil) (toggle-truncate-lines 1)), which is an
interactive Lisp function.
It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
(anonymous)
Not documented.
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-02-25 on ODIEONE
Bzr revision: 111879 yamaoka <at> jpl.org-20130225224731-cv9gznq5nqf3ei7g
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Mon, 10 Feb 2014 07:34:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 13841 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> C-h k
>
> Then choose menu item Options > Line Wrapping in This Buffer > Truncate
> Long Lines.
>
> You see binary output instead of useful help:
>
> <menu-bar> <options> <line-wrapping> <truncate> runs the command #[nil
> "ILLEGIBLE, INCOMPREHENSIBLE BINARY INCANTATIONS" [visual-line-mode
> word-wrap 0 nil toggle-truncate-lines 1] 2 nil nil], which is an
> interactive compiled Lisp function.
>
> It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
>
> (anonymous)
>
> Not documented.
>
> For reference wrt this regression, this is what Emacs 23.4 shows
> instead - much more readable and helpful:
>
> <menu-bar> <options> <line-wrapping> <truncate> runs the command
> (lambda nil (interactive) (if visual-line-mode (visual-line-mode 0))
> (setq word-wrap nil) (toggle-truncate-lines 1)), which is an
> interactive Lisp function.
>
> It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
Perhaps that's just because it didn't byte-compile the function? So
we're making progress.
Anyway, if we put lambdas into menus, `C-h k' isn't very helpful:
(bindings--define-key menu [truncate]
`(menu-item "Truncate Long Lines"
,(lambda ()
(interactive)
(if visual-line-mode (visual-line-mode 0))
(setq word-wrap nil)
(toggle-truncate-lines 1))
:help "Truncate long lines at window edge"
:button (:radio . (or truncate-lines
(truncated-partial-width-window-p)))
:visible (menu-bar-menu-frame-live-and-visible-p)
:enable (not (truncated-partial-width-window-p))))
I think the right solution here would be for `C-h k' just to say that
it's an anonymous function and leave it at that.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Thu, 28 Apr 2016 22:39:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 13841 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I think the right solution here would be for `C-h k' just to say that
> it's an anonymous function and leave it at that.
Or perhaps it should just do this with byte-compiled functions.
Anyway, here's a test case:
(key-binding [(menu-bar) options line-wrapping word-wrap] t)
=>
#[nil "\204\300\301!\210\302\303!\207" [visual-line-mode 1 message "Visual-Line mode enabled"] 2 nil nil]
The binary bit, at least, is probably not something we want to show to
the user. But the rest? It might help with chasing down code, which is
what I often use `C-h k' for...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Fri, 29 Apr 2016 16:23:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > I think the right solution here would be for `C-h k' just to say that
> > it's an anonymous function and leave it at that.
>
> Or perhaps it should just do this with byte-compiled functions.
> Anyway, here's a test case:
[...]
> The binary bit, at least, is probably not something we want to show to
> the user. But the rest? It might help with chasing down code, which is
> what I often use `C-h k' for...
This is a REGRESSION. With Emacs 23.4, emacs -Q C-h k, same
recipe, you see this:
<menu-bar> <options> <line-wrapping> <truncate> runs the command
(lambda nil (interactive) (if visual-line-mode (visual-line-mode 0))
(setq word-wrap nil) (toggle-truncate-lines 1)), which is an
interactive Lisp function.
It is bound to <menu-bar> <options> <line-wrapping> <truncate>.
(anonymous)
Not documented.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sat, 30 Apr 2016 11:48:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 13841 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> 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.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sat, 30 Apr 2016 15:39:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sat, 30 Apr 2016 15:54:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 30 Apr 2016 07:37:50 -0800 (GMT-08:00)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 13841 <at> debbugs.gnu.org
>
> > > 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.
Of course, there was a problem! Showing users a bunch of convoluted
Lisp when they ask what a key does is plain usability bug! It doesn't
matter whether that Lisp is compiled or not, it's no way of _helping_
the user understand what the function does.
If you don't mind the Lisp form, you shouldn't mind the byte-compiled
form, either. 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.
> 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.
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sat, 30 Apr 2016 17:21:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sat, 30 Apr 2016 17:31:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> 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.
Forcibly Merged 13841 20157.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 30 Apr 2016 18:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sat, 30 Apr 2016 18:15:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 13841 <at> debbugs.gnu.org (full text, mbox):
I agree that user help should show documentation, not just
Lisp code. But certainly - far more important - not byte code.
The fix for this bug (and any that are similar) is to
use a named function with a doc string. I think (hope)
we agree about that.
(We can disagree that if a user can read Lisp source code
then s?he should be able to also read byte code, or she
is just as likely to be able to do that.)
Forcibly Merged 13841 20157 20942.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 30 Apr 2016 20:05:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sun, 01 May 2016 13:52:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 13841 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> A more general solution is not to have lambda functions hang on keys
> and mouse clicks.
Or just give the lambda a docstring.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sun, 01 May 2016 15:11:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Drew Adams <drew.adams <at> oracle.com>, larsi <at> gnus.org, 13841 <at> debbugs.gnu.org
> Date: Sun, 01 May 2016 15:50:45 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > A more general solution is not to have lambda functions hang on keys
> > and mouse clicks.
>
> Or just give the lambda a docstring.
No, I think we should forbid using a lambda as a user-visible key
binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sun, 01 May 2016 15:14:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 13841 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> No, I think we should forbid using a lambda as a user-visible key
> binding.
I think we should avoid doing so in the code in Emacs (we already avoid
using lambdas as function definitions for normal keystrokes, but it's
present in some menus), but I don't think we should make that invalid in
general. I think it's fine for a user to define menus (or keystrokes)
"sloppily" for private use.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Sun, 01 May 2016 15:44:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 13841 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, drew.adams <at> oracle.com, 13841 <at> debbugs.gnu.org
> Date: Sun, 01 May 2016 17:13:33 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > No, I think we should forbid using a lambda as a user-visible key
> > binding.
>
> I think we should avoid doing so in the code in Emacs
That's what I meant, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Wed, 09 Oct 2019 03:29:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 13841 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > No, I think we should forbid using a lambda as a user-visible key
>> > binding.
>>
>> I think we should avoid doing so in the code in Emacs
>
> That's what I meant, yes.
I have now fixed this in menu-bar.el for the original reported case (and
the ones in nearby menus). There may be more lurking other places, but
we can fix those if somebody reports them, I guess.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) fixed.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 09 Oct 2019 03:29:03 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.1, send any further explanations to
20157 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Wed, 09 Oct 2019 03:29:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Wed, 09 Oct 2019 10:58:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 13841 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> I have now fixed this in menu-bar.el for the original reported case (and
> the ones in nearby menus). There may be more lurking other places, but
> we can fix those if somebody reports them, I guess.
Thanks.
I don't recall: did we want to fix only compiled lambdas, or any
anonymous functions (including quoted lambdas)?
Attached a quick rough search for candidates (search for "-->") - is any
of them problematic?
Regards,
Michael.
[menu-bar-lambdas.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#13841; Package
emacs.
(Wed, 09 Oct 2019 18:58:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 13841 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> I don't recall: did we want to fix only compiled lambdas, or any
> anonymous functions (including quoted lambdas)?
All key bindings (including menu ones) should be to named functions, I
think. That allows inspection via `C-h k' and the user can jump to the
function definition to see what it does.
> Attached a quick rough search for candidates (search for "-->") - is any
> of them problematic?
All of them should be changed, I think, although the
tab-bar-make-keymap-1 looks a bit difficult to deal with.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 07 Nov 2019 12:24:07 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Sun, 01 Mar 2020 04:05:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 30 Mar 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.