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

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

[Drew Adams]

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@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'
 

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@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/

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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 "\b\204\b\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

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

[Drew Adams]

> Lars Ingebrigtsen <larsi@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.

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

[Michael Heerdegen]

Drew Adams <drew.adams@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.

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

[Drew Adams]

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

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

[Eli Zaretskii]

> Date: Sat, 30 Apr 2016 07:37:50 -0800 (GMT-08:00)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 13841@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.

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

[Michael Heerdegen]

Eli Zaretskii <eliz@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.

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

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Drew Adams <drew.adams@oracle.com>,  larsi@gnus.org,  13841@debbugs.gnu.org
> Date: Sun, 01 May 2016 15:50:45 +0200
> 
> Eli Zaretskii <eliz@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,  drew.adams@oracle.com,  13841@debbugs.gnu.org
> Date: Sun, 01 May 2016 17:13:33 +0200
> 
> Eli Zaretskii <eliz@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.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

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

[Michael Heerdegen]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

Lars Ingebrigtsen <larsi@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.


[-- Attachment #2: menu-bar-lambdas.el --]
[-- Type: application/emacs-lisp, Size: 33109 bytes --]

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@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#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.

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

[Eli Zaretskii]

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

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

[Drew Adams]

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