GNU bug report logs - #33164
Compiled function value information in *Help*

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33164 in the body.
You can then email your comments to 33164 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; Compiled function information in *Help*
Date: Fri, 26 Oct 2018 08:05:39 -0700 (PDT)

emacs -Q

C-h v region-extract-function tells me:

region-extract-function is a variable defined in 'simple.el'.
Its value is #f(compiled-function (method) #<bytecode 0x1001ae2e9>)
...

There is a link to `simple.el'.  And the #<bytecode...> is also a link,
to the disassembled byte-code.

This is a bit more helpful than what we had in Emacs 24 (which was the
byte-code, printed).

But it is less helpful than what we had back in Emacs 23, which printed
the name or the lambda expression of the function that is the value of
the variable.  Examples:

 comment-line-break-function is a variable defined in `simple.el'.
 Its value is comment-indent-new-line


 completion-annotate-function is a variable defined in `minibuffer.el'.
 Its value is (lambda (var)
                (and (custom-variable-p (intern-soft var))
                "  (option)"))

Such description provided lots of helpful information, and we've lost
that now.

I guess this comes from eager macroexpansion (?).  But is there no way
for our help system to know what the function name or original lambda
expression is, and print that?

Yes, it would be helpful for it to _also_ provide the info that the
value is actually the byte-compilation of that function, when that is
the case, and to provide a link to the disassembly of that byte-code.

But just showing the byte code, even disassembled, is not so helpful.
What if a user wants to go to the function definition, to use it as a
model for defining a new value for the variable or just to study it?

Our help system should not become _less_ helpful just because we find
ways to optimize Emacs or make other improvements.  From a help
perspective, this is a step backward for users.

But maybe I'm missing something?  Is there currently some way to get to
the source code defining the function that is the variable value?


In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30 built on CIRROCUMULUS
Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea
Windowing system distributor 'Microsoft Corp.', version 10.0.16299

Message #8 received at 33164 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 33164 <at> debbugs.gnu.org
Subject: Re: bug#33164: 26.1; Compiled function information in *Help*
Date: Sun, 28 Oct 2018 09:27:45 -0400

retitle 33164 Compiled function value information in *Help*
quit

Drew Adams <drew.adams <at> oracle.com> writes:

> C-h v region-extract-function tells me:
>
> region-extract-function is a variable defined in 'simple.el'.
> Its value is #f(compiled-function (method) #<bytecode 0x1001ae2e9>)
> ...
>
> There is a link to `simple.el'.  And the #<bytecode...> is also a link,
> to the disassembled byte-code.

> But it is less helpful than what we had back in Emacs 23, which printed
> the name or the lambda expression of the function that is the value of
> the variable.  Examples:
>
>  comment-line-break-function is a variable defined in `simple.el'.
>  Its value is comment-indent-new-line

This one is still the same in newer Emacs versions.

> But just showing the byte code, even disassembled, is not so helpful.
> What if a user wants to go to the function definition, to use it as a
> model for defining a new value for the variable or just to study it?

Similarly, C-h v float-pi tells me

    float-pi is a variable defined in ‘float-sup.el’.
    Its value is 3.141592653589793

It doesn't show me (* 4 (atan 1)) for study.

> But maybe I'm missing something?  Is there currently some way to get to
> the source code defining the function that is the variable value?

In this case, the link to `simple.el' takes you there because it's the
default value.  But in general, no, that information is not saved
anywhere.

The easiest fix is to say we should never assign anonymous functions to
variables (there have already been a couple of cases where some
anonymous function values were given names), so then they would all show
a symbol like comment-line-break-function.

Message #13 received at 33164 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33164 <at> debbugs.gnu.org
Subject: RE: bug#33164: 26.1; Compiled function information in *Help*
Date: Sun, 28 Oct 2018 07:17:29 -0700 (PDT)

> In this case, the link to `simple.el' takes you there because it's the
> default value.  But in general, no, that information is not saved
> anywhere.

Yes, what you say makes sense.  I guess I am wondering whether
the byte-compiler might (be made to) record the source in the
byte-compiled function definition.  A byte-compiled file
records the absolute name of the source file, as well as the
Emacs release/build and the time of the compilation (creation
of the .elc).

Perhaps some "source" location information could be recorded
in the byte-code, and be retrievable by a help function?
In the case of a source definition in a file, the info could
be similar to what we record in a .elc.  But perhaps even if
the source code were in a buffer, or even via `M-:', perhaps
some textual indication/description of that source could be
recorded, along with the date & time.

Just a thought.  Yes, that would increase byte-code size,
and it should anyway be optional I guess.  But it might
allow for a little more introspection than what we can get
now (disassembled code).

If you want to recast this bug report as an enhancement
request along those lines, perhaps (again) retitling, please
do so.

> The easiest fix is to say we should never assign anonymous functions to
> variables (there have already been a couple of cases where some
> anonymous function values were given names), so then they would all show
> a symbol like comment-line-break-function.

That would not be something I'd ask for or appreciate.
I want to be able to get more info about existing function
values, not reduce the types of function values we can
assign to variables.

It can be helpful for help functions if someone uses a
symbol (providing a name and perhaps a source location),
but users need to be able to define and assign code as
values on the fly.  The idea of this report is to ask
for possible improvement in the introspection of byte-code
values - specifically time and location of definition.

Message #16 received at 33164 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33164 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#33164: Compiled function value information in *Help*
Date: Wed, 23 Jun 2021 16:05:17 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

>> But it is less helpful than what we had back in Emacs 23, which printed
>> the name or the lambda expression of the function that is the value of
>> the variable.  Examples:
>>
>>  comment-line-break-function is a variable defined in `simple.el'.
>>  Its value is comment-indent-new-line
>
> This one is still the same in newer Emacs versions.
>
>> But just showing the byte code, even disassembled, is not so helpful.
>> What if a user wants to go to the function definition, to use it as a
>> model for defining a new value for the variable or just to study it?
>
> Similarly, C-h v float-pi tells me
>
>     float-pi is a variable defined in ‘float-sup.el’.
>     Its value is 3.141592653589793
>
> It doesn't show me (* 4 (atan 1)) for study.

The help buffer shows the actual value of the variable, which may be
set somewhere else than it has been defined.  It's not feasible for the
Emacs help system to take you to all locations a variable has been
changed, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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