GNU bug report logs - #55853
28.1; Please document f#(...) syntax in Elisp manual

Previous Next

Package: emacs;

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

Date: Wed, 8 Jun 2022 16:57:01 UTC

Severity: normal

Found in version 28.1

Fixed in version 28.2

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: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "55853 <at> debbugs.gnu.org" <55853 <at> debbugs.gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#55853: 28.1; Please document f#(...) syntax in Elisp manual
Date: Tue, 05 Jul 2022 20:55:27 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> Maybe instead of (or in addition to) a disassembly, a
> user could be pointed - a least in some cases - to the
> original source code (Lisp or C)?

Are there such cases?  The place is not always well defined.

In the cited original thread, when you see

  org-file-apps-windowsnt is a variable defined in `org.el'.

in the C-h v popup you just click on the "org.el" button and are
directly guided to the source of the byte-code function.  We can't get
much better I guess since we don't save the exact position of every
lambda expression when compiling.

If the byte-code function is named, you can click on the name that will
likely be around.  And if it has not, it's probably not trivial to find
a related place of a definition (if there is one).

So, hard to answer without a real-life example where this would actually
be a real improvement.

Michael.




This bug report was last modified 2 years and 322 days ago.

Previous Next


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