From: Drew Adams <drew.adams@oracle.com>
To: Noam Postavsky <npostavs@gmail.com>
Cc: 33164@debbugs.gnu.org
Subject: bug#33164: 26.1; Compiled function information in *Help*
Date: Sun, 28 Oct 2018 07:17:29 -0700 (PDT) [thread overview]
Message-ID: <0e796704-669a-4c58-9530-cd810d56494e@default> (raw)
In-Reply-To: <877ei2jj5a.fsf@gmail.com>
> 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.
next prev parent reply other threads:[~2018-10-28 14:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-26 15:05 bug#33164: 26.1; Compiled function information in *Help* Drew Adams
2018-10-28 13:27 ` Noam Postavsky
2018-10-28 14:17 ` Drew Adams [this message]
2021-06-23 14:05 ` bug#33164: Compiled function value " Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0e796704-669a-4c58-9530-cd810d56494e@default \
--to=drew.adams@oracle.com \
--cc=33164@debbugs.gnu.org \
--cc=npostavs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).