GNU bug report logs - #60568
[FR] 30.0.50; Help buffers and function bodies for generated functions

Previous Next

To reply to this bug, email your comments to 60568 AT debbugs.gnu.org.

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

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: [FR] 30.0.50; Help buffers and function bodies for generated functions
Date: Thu, 05 Jan 2023 07:56:11 +0000

Hi,

There have been a discussion [1] about including some of the helpful
package [2] features into built-in *Help* buffers.

One of the discussed features was displaying function source code right
in *Help* buffers. This feature usefulness have been objected at that
time, on the grounds that showing function code may be too long and
cause large *Help* buffers.

Recently, we have stumbled upon a situation when showing function code
is not only useful, but one of the few sane ways to examine it [3].
Functions that are not directly written in the source but rather
generated programmatically cannot currently be easily examined using
built-in help functionality (using describe-function or other means).
The help buffer only links to the (point-min) in the library defining
the generated function - not very helpful. In contrast, helpful extracts
function body from symbol function slot.

To illustrate, one can try the following:

1. emacs -Q
2. M-: (require 'ob-shell)
3. <F1> f org-babel-execute:sh <RET>
4. Click on the source code link in *Help* buffer
5. Observe point jumping to (point-min) with no obvious way to find the
   function definition.

Would it be possible to provide function body info via *Help* system in
Emacs?

[1]
https://yhetil.org/emacs-devel/AM9PR09MB4977A7738F83C5C24EF5829196D59 <at> AM9PR09MB4977.eurprd09.prod.outlook.com

[2] https://github.com/Wilfred/helpful

[3] https://orgmode.org/list/87h6x8kluc.fsf <at> localhost

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.17.6) of 2023-01-02 built on localhost
Repository revision: 9377a3c889aa3b178a11a3b849c3d1665da096d6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Gentoo Linux


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50;
 Help buffers and function bodies for generated functions
Date: Thu, 05 Jan 2023 10:09:59 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Date: Thu, 05 Jan 2023 07:56:11 +0000
> 
> There have been a discussion [1] about including some of the helpful
> package [2] features into built-in *Help* buffers.
> 
> One of the discussed features was displaying function source code right
> in *Help* buffers. This feature usefulness have been objected at that
> time, on the grounds that showing function code may be too long and
> cause large *Help* buffers.
> 
> Recently, we have stumbled upon a situation when showing function code
> is not only useful, but one of the few sane ways to examine it [3].
> Functions that are not directly written in the source but rather
> generated programmatically cannot currently be easily examined using
> built-in help functionality (using describe-function or other means).
> The help buffer only links to the (point-min) in the library defining
> the generated function - not very helpful. In contrast, helpful extracts
> function body from symbol function slot.
> 
> To illustrate, one can try the following:
> 
> 1. emacs -Q
> 2. M-: (require 'ob-shell)
> 3. <F1> f org-babel-execute:sh <RET>
> 4. Click on the source code link in *Help* buffer
> 5. Observe point jumping to (point-min) with no obvious way to find the
>    function definition.
> 
> Would it be possible to provide function body info via *Help* system in
> Emacs?

Provide how?

You basically ignore the valid objections voiced against such a
feature, and present a specific case where (a) the source code is
extremely short, and (b) the existing Help facilities are less than
helpful because they have a deficiency.  How does it follow from the
specific use case you present that we must show the source code in
Help buffers?  An alternative solution would be to teach Help
functions to find the place where the source code is generated and let
users examine that if they want.  I could even argue that this
alternative is better, because with your proposal we will show a
source code that doesn't actually exist anywhere in the form we show
it.

If we do decide to show the source code in some circumstances, we need
to do that selectively and in a way that doesn't display unnecessarily
large Help buffers that would then run the risk of "drowning" useful
information, making it easy to miss.  So any such proposal should
suggest how to avoid the downsides, at least.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 08:20:21 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Would it be possible to provide function body info via *Help* system in
>> Emacs?
>
> Provide how?

For example, clicking source code link for function without definition
may display a new separate buffer with function body stored in the
function symbol.

> You basically ignore the valid objections voiced against such a
> feature, and present a specific case where (a) the source code is
> extremely short, and (b) the existing Help facilities are less than
> helpful because they have a deficiency.  How does it follow from the
> specific use case you present that we must show the source code in
> Help buffers?

Sorry, I did not imply that the function body will be _displayed_ in
*Help* buffers. Just accessible via some means.

As an alternative to my above suggestion, the function body might be
displayed upon clicking on some button in help buffer. Maybe using
outlines to fold/unfold the definition as necessary.

(BTW, don't *Help* buffer already suffer from too long variable values
being displayed? I don't mean it as an argument to add function body -
rather pointing that we might want some ideas how to deal with long
sexps displayed in *Help*)

> An alternative solution would be to teach Help
> functions to find the place where the source code is generated and let
> users examine that if they want.  I could even argue that this
> alternative is better, because with your proposal we will show a
> source code that doesn't actually exist anywhere in the form we show
> it.

Yes, for the particular use case I mentioned here. But how? I do not see
any obvious ways how to know where the function was generated unless
`defun' stores some extra auxiliary information when defining a
function.

> If we do decide to show the source code in some circumstances, we need
> to do that selectively and in a way that doesn't display unnecessarily
> large Help buffers that would then run the risk of "drowning" useful
> information, making it easy to miss.  So any such proposal should
> suggest how to avoid the downsides, at least.

I agree that too long function bodies, similar to too long variable
values are objectively degrading readability.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 10:32:05 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: 60568 <at> debbugs.gnu.org
> Date: Thu, 05 Jan 2023 08:20:21 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Would it be possible to provide function body info via *Help* system in
> >> Emacs?
> >
> > Provide how?
> 
> For example, clicking source code link for function without definition
> may display a new separate buffer with function body stored in the
> function symbol.

That is less desirable, IMO, then teaching Help commands to be smarter
with showing the source code.  One of the main reasons to go to the
source code is to examine the surrounding code, and consider the
function in its context.  This will be impossible with your proposal.

> (BTW, don't *Help* buffer already suffer from too long variable values
> being displayed? I don't mean it as an argument to add function body -
> rather pointing that we might want some ideas how to deal with long
> sexps displayed in *Help*)

Yes, they do.  Patches are welcome to deal with these cases.

> > An alternative solution would be to teach Help
> > functions to find the place where the source code is generated and let
> > users examine that if they want.  I could even argue that this
> > alternative is better, because with your proposal we will show a
> > source code that doesn't actually exist anywhere in the form we show
> > it.
> 
> Yes, for the particular use case I mentioned here. But how? I do not see
> any obvious ways how to know where the function was generated unless
> `defun' stores some extra auxiliary information when defining a
> function.

Storing more information is one way.  Looking for more sophisticated
regexps (if the "usual" ones fail) is another.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 09:40:11 +0000

>
> Would it be possible to provide function body info via *Help* system in 
> Emacs?
>

Would this fit the bill?

diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index bf64d032b6..049eb2fa5a 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -281,7 +281,14 @@ help-function-def--button-function
             (unless (= (point) position)
               (push-mark nil t))
             (goto-char position))
-        (message "Unable to find location in file")))))
+       (with-help-window (help-buffer)
+         (insert (format "Function `%s' could not be found in " fun))
+         (if file
+              (insert (format "`%s'." file))
+            (insert " this file."))
+         (insert "\n\n")
+         (insert (format "Function definition:\n\n" fun))
+         (insert (format "%S" (symbol-function fun))))))))

 (define-button-type 'help-function-def
   :supertype 'help-xref

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 09:52:19 +0000

>> Would it be possible to provide function body info via *Help* system in 
>> Emacs?
>
> Would this fit the bill?
>

Shorter and better:

diff --git a/lisp/help-mode.el b/lisp/help-mode.el
index bf64d032b6..75ccd93938 100644
--- a/lisp/help-mode.el
+++ b/lisp/help-mode.el
@@ -281,7 +281,11 @@ help-function-def--button-function
             (unless (= (point) position)
               (push-mark nil t))
             (goto-char position))
-        (message "Unable to find location in file")))))
+       (with-help-window (help-buffer)
+         (insert (format "Function `%s' could not be found in `%s'."
+                          fun file))
+         (insert "\n\nFunction definition:\n\n")
+         (insert (pp-to-string (symbol-function fun))))))))

 (define-button-type 'help-function-def
   :supertype 'help-xref

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 11:45:15 +0100

Ihor Radchenko <yantar92 <at> posteo.net> writes:

> Recently, we have stumbled upon a situation when showing function code
> is not only useful, but one of the few sane ways to examine it [3].
> Functions that are not directly written in the source but rather
> generated programmatically cannot currently be easily examined using
> built-in help functionality (using describe-function or other means).
> The help buffer only links to the (point-min) in the library defining
> the generated function - not very helpful. In contrast, helpful extracts
> function body from symbol function slot.

I'd prefer we teach the Help facilities how to go to the source code of
that kind of functions.  Some years ago, I added support for go to
definition from *Help* buffers when the symbol was generated by a Lisp
macro; there's no reason we couldn't extend the code to also handle this
particular case.

Showing the source code inline is something I feel more suitable for
third-party packages.  It is probably more interesting from a core Emacs
perspective to make sure that help-mode provides the appropriate hooks
for users and packages to customize what to show without needing to
reimplement *Help* from scratch.  I don't know what other people think,
my opinion about this may be a minority.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 10:52:45 +0000

Daniel Martín <mardani29 <at> yahoo.es> writes:

> I'd prefer we teach the Help facilities how to go to the source code of
> that kind of functions.  Some years ago, I added support for go to
> definition from *Help* buffers when the symbol was generated by a Lisp
> macro; there's no reason we couldn't extend the code to also handle this
> particular case.

Could you point to the implementation?

> Showing the source code inline is something I feel more suitable for
> third-party packages.  It is probably more interesting from a core Emacs
> perspective to make sure that help-mode provides the appropriate hooks
> for users and packages to customize what to show without needing to
> reimplement *Help* from scratch.  I don't know what other people think,
> my opinion about this may be a minority.

+1 from me.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50;
 Help buffers and function bodies for generated functions
Date: Thu, 05 Jan 2023 13:20:47 +0200

> Cc: 60568 <at> debbugs.gnu.org
> Date: Thu, 05 Jan 2023 11:45:15 +0100
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Ihor Radchenko <yantar92 <at> posteo.net> writes:
> 
> > Recently, we have stumbled upon a situation when showing function code
> > is not only useful, but one of the few sane ways to examine it [3].
> > Functions that are not directly written in the source but rather
> > generated programmatically cannot currently be easily examined using
> > built-in help functionality (using describe-function or other means).
> > The help buffer only links to the (point-min) in the library defining
> > the generated function - not very helpful. In contrast, helpful extracts
> > function body from symbol function slot.
> 
> I'd prefer we teach the Help facilities how to go to the source code of
> that kind of functions.

Agreed.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org,
 Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 12:33:26 +0000

>> I'd prefer we teach the Help facilities how to go to the source code of 
>> that kind of functions.
>
> Agreed.
>

What is missing in the five-line patch that does this?  With the recipe, 
the file in which org-babel-execute:sh was defined (ob-shell.el) is 
opened, and the function definition is displayed.  I don't think we can do 
much better (e.g. reliably find the place where the function was defined).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 16:16:13 +0200

> Date: Thu, 05 Jan 2023 12:33:26 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Daniel Martín <mardani29 <at> yahoo.es>, yantar92 <at> posteo.net, 
>     60568 <at> debbugs.gnu.org
> 
> 
> >> I'd prefer we teach the Help facilities how to go to the source code of 
> >> that kind of functions.
> >
> > Agreed.
> >
> 
> What is missing in the five-line patch that does this?  With the recipe, 
> the file in which org-babel-execute:sh was defined (ob-shell.el) is 
> opened, and the function definition is displayed.  I don't think we can do 
> much better (e.g. reliably find the place where the function was defined).

Why not?  A function definition usually has some specific keywords in
it.  It is true that someone could have obfuscated the code which
generates a function to the degree that it would be infeasible to
recognize, but we don't need to support such arbitrary measures, we
only need to support what's really being used.  IOW, "reliably"
doesn't need to mean with 110% reliability.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 14:27:41 +0000

>> What is missing in the five-line patch that does this?  With the 
>> recipe, the file in which org-babel-execute:sh was defined 
>> (ob-shell.el) is opened, and the function definition is displayed.  I 
>> don't think we can do much better (e.g. reliably find the place where 
>> the function was defined).
>
> Why not?  A function definition usually has some specific keywords in 
> it.  It is true that someone could have obfuscated the code which 
> generates a function to the degree that it would be infeasible to 
> recognize, but we don't need to support such arbitrary measures, we only 
> need to support what's really being used.  IOW, "reliably" doesn't need 
> to mean with 110% reliability.
>

Hmmm, you mean try to find heuristically where e.g. in the ob-shell.el 
file the org-babel-execute:sh function was defined?

The function body is this:

(lambda
  (body params)
  "Execute a block of sh commands with Babel."
  (let
      ((shell-file-name "sh")
       (org-babel-prompt-command
	(or
	 (alist-get "sh" org-babel-shell-set-prompt-commands)
	 (alist-get t org-babel-shell-set-prompt-commands))))
    (org-babel-execute:shell body params)))

and it has been created here:

(defun org-babel-shell-initialize ()
  "Define execution functions associated to shell names.
This function has to be called whenever `org-babel-shell-names'
is modified outside the Customize interface."
  (interactive)
  (dolist (name org-babel-shell-names)
    (eval `(defun ,(intern (concat "org-babel-execute:" name))
	       (body params)
	     ,(format "Execute a block of %s commands with Babel." name)
	     (let ((shell-file-name ,name)
                   (org-babel-prompt-command
                    (or (alist-get ,name org-babel-shell-set-prompt-commands)
                        (alist-get t org-babel-shell-set-prompt-commands))))
	       (org-babel-execute:shell body params))))
    (eval `(defalias ',(intern (concat "org-babel-variable-assignments:" name))
	     'org-babel-variable-assignments:shell
	     ,(format "Return list of %s statements assigning to the block's \
variables."
		      name)))
    (eval `(defvar ,(intern (concat "org-babel-default-header-args:" name)) '()))))

Do you think there is a way to find that place?  AFAIU, all elements in 
the function definition could be variables in the form that is evalled.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 17:10:20 +0200

> Date: Thu, 05 Jan 2023 14:27:41 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: mardani29 <at> yahoo.es, yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org
> 
> 
> >> What is missing in the five-line patch that does this?  With the 
> >> recipe, the file in which org-babel-execute:sh was defined 
> >> (ob-shell.el) is opened, and the function definition is displayed.  I 
> >> don't think we can do much better (e.g. reliably find the place where 
> >> the function was defined).
> >
> > Why not?  A function definition usually has some specific keywords in 
> > it.  It is true that someone could have obfuscated the code which 
> > generates a function to the degree that it would be infeasible to 
> > recognize, but we don't need to support such arbitrary measures, we only 
> > need to support what's really being used.  IOW, "reliably" doesn't need 
> > to mean with 110% reliability.
> 
> Hmmm, you mean try to find heuristically where e.g. in the ob-shell.el 
> file the org-babel-execute:sh function was defined?

Yes.

> The function body is this:
> 
> (lambda
>    (body params)
>    "Execute a block of sh commands with Babel."
>    (let
>        ((shell-file-name "sh")
>         (org-babel-prompt-command
>  	(or
>  	 (alist-get "sh" org-babel-shell-set-prompt-commands)
>  	 (alist-get t org-babel-shell-set-prompt-commands))))
>      (org-babel-execute:shell body params)))
> 
> and it has been created here:
> 
> (defun org-babel-shell-initialize ()
>    "Define execution functions associated to shell names.
> This function has to be called whenever `org-babel-shell-names'
> is modified outside the Customize interface."
>    (interactive)
>    (dolist (name org-babel-shell-names)
>      (eval `(defun ,(intern (concat "org-babel-execute:" name))
>  	       (body params)
>  	     ,(format "Execute a block of %s commands with Babel." name)
>  	     (let ((shell-file-name ,name)
>                     (org-babel-prompt-command
>                      (or (alist-get ,name org-babel-shell-set-prompt-commands)
>                          (alist-get t org-babel-shell-set-prompt-commands))))
>  	       (org-babel-execute:shell body params))))
>      (eval `(defalias ',(intern (concat "org-babel-variable-assignments:" name))
>  	     'org-babel-variable-assignments:shell
>  	     ,(format "Return list of %s statements assigning to the block's \
> variables."
>  		      name)))
>      (eval `(defvar ,(intern (concat "org-babel-default-header-args:" name)) '()))))
> 
> Do you think there is a way to find that place?

Well, searching for the regexp "defun .*org-babel-execute:" would have
done that, right?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 15:13:52 +0000

>
> Well, searching for the regexp "defun .*org-babel-execute:" would have 
> done that, right?
>

In this specific case, yes.  But in general?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 18:49:54 +0200

> Date: Thu, 05 Jan 2023 15:13:52 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: mardani29 <at> yahoo.es, yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org
> 
> 
> >
> > Well, searching for the regexp "defun .*org-babel-execute:" would have 
> > done that, right?
> >
> 
> In this specific case, yes.  But in general?

I hope that in a more general case we could use something similar,
since every definition of a function should start from "defun "
followed by some part of its name, right?

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

From: Jean Louis <bugs <at> gnu.support>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 5 Jan 2023 20:00:50 +0300

* Ihor Radchenko <yantar92 <at> posteo.net> [2023-01-05 10:57]:
> Recently, we have stumbled upon a situation when showing function code
> is not only useful, but one of the few sane ways to examine it [3].
> Functions that are not directly written in the source but rather
> generated programmatically cannot currently be easily examined using
> built-in help functionality (using describe-function or other means).
> The help buffer only links to the (point-min) in the library defining
> the generated function - not very helpful. In contrast, helpful extracts
> function body from symbol function slot.

> Would it be possible to provide function body info via *Help* system in
> Emacs?

That would be helpful. 

When there is some on the fly defined function I have used
`symbol-function' function to extract data and save the function in the file for
later examination.

;;; SAVE FUNCTION

(defun save-function ()
  "Saves function at point"
  (interactive)
  (let ((function (function-called-at-point)))
    (when (and (symbolp function)
	       (y-or-n-p (format "Save `%s'" (symbol-name function))))
      (save-function-1 function))))

(defun save-function-1 (function)
  (let* ((fun (symbol-function function))
	 (type (car fun))
	 (file (concat rcd-temp-file-directory
		       "function-" (symbol-name function) ".el")))
    (cond ((eq type 'lambda) (setq fun (append (list 'defun function) (cdr fun))))
	  ((eq type 'closure) (setq fun (append (list 'defun function) (nthcdr 2 fun)))))
    (message (string-to-file-force (prin1-to-string fun) file))))

(defun save-function-delete ()
  (interactive)
  (save-function)
  (beginning-of-line)
  (mark-sexp)
  (delete-active-region))

Then I would get this result, for example:

  -rw-r--r--   1  668 Jan  5 19:54 function-hyperscope-add-new-note-hyperdocument.el

with body being:

(defun hyperscope-add-new-note-hyperdocument nil (interactive) (let* ((parent (hyperscope-set-parent-or-select)) (markup (hyperscope-markup-select)) (related-person-by-parent (if parent (progn (hyperscope-related-person-id parent)))) (related-person (if (and related-person-by-parent (y-or-n-p (format "Is Hyperdocument related to `%s'? " (cf-people-name related-person-by-parent)))) (progn related-person-by-parent))) (prompt (format "New `%s' hyperdocument name: " type-name)) (name (rcd-ask prompt)) (hyperdocument (hyperscope-add-generic name "" markup id nil parent nil nil nil related-person))) (hyperscope-ring hyperdocument) (hyperscope-revert hyperdocument)))

Which I know is not very readable, but is still something useful.

Thus the help buffer shall try to find function in source, but if it
is not there, it shall at least show it's definition by using
`symbol-function'.

Problem is with byte-compiled functions:

(symbol-function 'rcd-iso-date) ➜ #[0 "\300\301!\207" [format-time-string "%Y-%m-%d"] 2]

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 5 Jan 2023 20:03:03 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2023-01-05 11:11]:
> You basically ignore the valid objections voiced against such a
> feature, and present a specific case where (a) the source code is
> extremely short, and (b) the existing Help facilities are less than
> helpful because they have a deficiency.  How does it follow from the
> specific use case you present that we must show the source code in
> Help buffers?

I have understood that as a button, hyperlink to source, like

ignore is an interactive byte-compiled Lisp function in ‘subr.el’.

whereby ‘subr.el’ would be the button to the source, and if it can't
be found in the file, then temporary buffer may be displayed to tell
what or how function is defined, like by using `symbol-function'
function. 

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 5 Jan 2023 20:04:40 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2023-01-05 11:33]:
> > From: Ihor Radchenko <yantar92 <at> posteo.net>
> > Cc: 60568 <at> debbugs.gnu.org
> > Date: Thu, 05 Jan 2023 08:20:21 +0000
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> Would it be possible to provide function body info via *Help* system in
> > >> Emacs?
> > >
> > > Provide how?
> > 
> > For example, clicking source code link for function without definition
> > may display a new separate buffer with function body stored in the
> > function symbol.
> 
> That is less desirable, IMO, then teaching Help commands to be smarter
> with showing the source code.  One of the main reasons to go to the
> source code is to examine the surrounding code, and consider the
> function in its context.  This will be impossible with your proposal.

It would be better to find the place where generated functions have
been generated.

But not bad, to show how function looks like in same time.

1. Help buffer, with button link

2. Link goes to source, but if it does not find function, it shows
   where it was generated and pops up temporary buffer with function
   definition using `symbol-function'

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 05 Jan 2023 20:44:21 +0000

[Message part 1 (text/plain, inline)]

>>> Well, searching for the regexp "defun .*org-babel-execute:" would have 
>>> done that, right?
>>
>> In this specific case, yes.  But in general?
>
> I hope that in a more general case we could use something similar, since 
> every definition of a function should start from "defun " followed by 
> some part of its name, right?
>

Not always, I can imagine functions defined with fset for example.

What about the attached patch?  It seems to work well.

[Try-to-find-where-dynamically-defined-functions-were.patch (text/x-diff, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 08:35:02 +0200

> Date: Thu, 05 Jan 2023 20:44:21 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
> 
> > I hope that in a more general case we could use something similar, since 
> > every definition of a function should start from "defun " followed by 
> > some part of its name, right?
> >
> 
> Not always, I can imagine functions defined with fset for example.
> 
> What about the attached patch?  It seems to work well.

SGTM.  With which cases did you test this?

Adding Stefan, in case he has any comments.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Jean Louis <bugs <at> gnu.support>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 08:39:30 +0000

Jean Louis <bugs <at> gnu.support> writes:

> with body being:
>
> (defun hyperscope-add-new-note-hyperdocument nil (interactive) (let* ((parent (hyperscope-set-parent-or-select)) (markup (hyperscope-markup-select)) (related-person-by-parent (if parent (progn (hyperscope-related-person-id parent)))) (related-person (if (and related-person-by-parent (y-or-n-p (format "Is Hyperdocument related to `%s'? " (cf-people-name related-person-by-parent)))) (progn related-person-by-parent))) (prompt (format "New `%s' hyperdocument name: " type-name)) (name (rcd-ask prompt)) (hyperdocument (hyperscope-add-generic name "" markup id nil parent nil nil nil related-person))) (hyperscope-ring hyperdocument) (hyperscope-revert hyperdocument)))
>
> Which I know is not very readable, but is still something useful.

Try `pp' to auto-format the body.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, mardani29 <at> yahoo.es,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 09:11:02 +0000

[Message part 1 (text/plain, inline)]

>>> I hope that in a more general case we could use something similar, 
>>> since every definition of a function should start from "defun " 
>>> followed by some part of its name, right?
>>
>> Not always, I can imagine functions defined with fset for example.
>>
>> What about the attached patch?  It seems to work well.
>
> SGTM.  With which cases did you test this?
>
> Adding Stefan, in case he has any comments.
>

Mainly with the original recipe and some variants of it.

I attach a slightly improved version of the patch.

[Try-to-find-where-dynamically-defined-functions-were.patch (text/x-diff, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 11:44:10 -0500

> One of the discussed features was displaying function source code right
> in *Help* buffers. This feature usefulness have been objected at that
> time, on the grounds that showing function code may be too long and
> cause large *Help* buffers.

FWIW, I find myself regularly jumping to `M-x ielm` to look at the
`symbol-function`, so I would actually appreciate a button in the *Help*
buffer to display the actual value in the `symbol-function` slot.
This would also bring `describe-function` a bit closer to
`describe-variable`, which I think is good.

> 1. emacs -Q
> 2. M-: (require 'ob-shell)
> 3. <F1> f org-babel-execute:sh <RET>
> 4. Click on the source code link in *Help* buffer
> 5. Observe point jumping to (point-min) with no obvious way to find the
>    function definition.

We have `definition-name` for that.
I.e. `org-babel-shell-initialize` should arguably do

    (put 'org-babel-execute:sh 'definition-name 'org-babel-shell-initialize)

so that step 4 above jumps to `org-babel-shell-initialize`.

The patch below does that, along with saving some kittens.


        Stefan


diff --git a/lisp/org/ob-shell.el b/lisp/org/ob-shell.el
index 4a60186cd5d..5f7373c3faa 100644
--- a/lisp/org/ob-shell.el
+++ b/lisp/org/ob-shell.el
@@ -74,20 +74,25 @@ org-babel-shell-initialize
 is modified outside the Customize interface."
   (interactive)
   (dolist (name org-babel-shell-names)
-    (eval `(defun ,(intern (concat "org-babel-execute:" name))
-	       (body params)
-	     ,(format "Execute a block of %s commands with Babel." name)
-	     (let ((shell-file-name ,name)
-                   (org-babel-prompt-command
-                    (or (alist-get ,name org-babel-shell-set-prompt-commands)
-                        (alist-get t org-babel-shell-set-prompt-commands))))
-	       (org-babel-execute:shell body params))))
-    (eval `(defalias ',(intern (concat "org-babel-variable-assignments:" name))
-	     'org-babel-variable-assignments:shell
-	     ,(format "Return list of %s statements assigning to the block's \
+    (let ((fname (intern (concat "org-babel-execute:" name))))
+      (defalias fname
+        (lambda (body params)
+	  (:documentation
+           (format "Execute a block of %s commands with Babel." name))
+	  (let ((shell-file-name name)
+                (org-babel-prompt-command
+                 (or (alist-get name org-babel-shell-set-prompt-commands)
+                     (alist-get t org-babel-shell-set-prompt-commands))))
+	    (org-babel-execute:shell body params))))
+      (put fname 'definition-name 'org-babel-shell-initialize))
+    (defalias (intern (concat "org-babel-variable-assignments:" name))
+      #'org-babel-variable-assignments:shell
+      (format "Return list of %s statements assigning to the block's \
 variables."
-		      name)))
-    (eval `(defvar ,(intern (concat "org-babel-default-header-args:" name)) '()))))
+	      name))
+    (funcall (if (fboundp 'defvar-1) #'defvar-1 #'set) ;Emacs-29
+             (intern (concat "org-babel-default-header-args:" name))
+             '())))
 
 (defcustom org-babel-shell-names
   '("sh" "bash" "zsh" "fish" "csh" "ash" "dash" "ksh" "mksh" "posh")

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 60568 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, yantar92 <at> posteo.net,
 mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 12:27:30 -0500

>>> Not always, I can imagine functions defined with fset for example.

I'd consider that an error.
`defalias` on the other hand is indeed a normal and common case.

>>> What about the attached patch?  It seems to work well.
>> SGTM.  With which cases did you test this?
>> Adding Stefan, in case he has any comments.

SGTM as well.  I do have some comments, see below.

> +(defun help-function-def--find-probable-definition-place (fun)

Can we shorten the name using "guess" i.s.o "find-probable"?
Also, this should be in `find-func.el` rather than in `help-mode.el`, no?

> +  (save-excursion
> +    ;; Build a list of strings with the symbols (and strings) of FUN.
> +    (let ((names
> +           (mapcar (lambda (el)
> +                     (concat
> +                      "\\_<"
> +                      (regexp-quote (format "%s" el))

I think you want "%S" rather than "%s".

> +                      "\\_>"))
> +                   (flatten-tree (symbol-function fun))))

- We probably want to use `advice-cd*r` so as to flatten the actual
  function definition rather than the combination of its definition with
  the various pieces of advice that are currently applied.
- The above works for non-compiled functions but for byte-compiled
  functions we need an ad-hoc version of `flatten-tree` which extracts
  the constants from the constant vector of bytecode objects (also
  recursively since bytecode objects tend to contain other bytecode
  objects).
  For native-compiled functions, we may be able to get some kind of
  "constant vector" as well, but I don't think that's currently
  accessible from ELisp.  We should ask Andrea.

> +          ;; Exclude symbols that are 3 characters or less.
> +          (when (> (length el) 9)

If we filter them out when constructing `names`, we can use a comment
where the number matches the number used in the code :-)

> +                    ;; Determine the beginning position of that
> +                    ;; function.
> +                    (goto-char (point-min))
> +                    (when (catch 'found
> +                            (while (re-search-forward
> +                                    (concat "\\_<"
> +                                            (regexp-quote result)
> +                                            "\\_>"))
> +                              (when (string= (lisp-current-defun-name)
> +                                             result)
> +                                (throw 'found t)))
> +                            (throw 'found nil))
> +                      (beginning-of-defun)
> +                      (cons result (point)))))))))))))

Can't we use `find-function-noselect` here?  Or maybe just return the
function name and let the caller then use `find-function-noselect`.

> @@ -281,7 +366,31 @@ help-function-def--button-function
>              (unless (= (point) position)
>                (push-mark nil t))
>              (goto-char position))
> -        (message "Unable to find location in file")))))
> +        (let ((probable-definition-place
> +               (help-function-def--find-probable-definition-place fun)))
> +          (when probable-definition-place
> +            (goto-char (cdr probable-definition-place)))
> +          (let ((help-buffer-under-preparation t))
> +            (help-setup-xref (list #'help-function-def--button-function
> +                                   fun file)
> +		             (called-interactively-p 'interactive))
> +	    (with-help-window (help-buffer)
> +	      (insert (substitute-command-keys
> +                       (format "Function %s could not be found in `%s'.\n\n"
> +                              fun (file-name-nondirectory file))))
> +              (setq help-mode--current-data (list :symbol fun
> +                                                  :file file))
> +	      (save-excursion
> +	        (re-search-backward
> +                 (substitute-command-keys "`\\([^`']+\\)'")
> +                 nil t)
> +	        (help-xref-button 1 'help-function-def fun file))
> +              (when probable-definition-place
> +                (insert (substitute-command-keys
> +                         (format "It was probably defined by `%s'.\n\n"
> +                                (car probable-definition-place)))))
> +	      (insert "Function definition:\n\n")
> +	      (insert (pp-to-string (symbol-function fun))))))))))

Please move this to a separate function.

Also, I'm not completely convinced what you do with the *Help* buffer
here is the UI we'll want, really.  But I don't have a good idea for
what to replace it with (yet), so we can start with that and tweak
it later.


        Stefan

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60568 <at> debbugs.gnu.org, yantar92 <at> posteo.net, Eli Zaretskii <eliz <at> gnu.org>,
 mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 22:52:32 +0000

>>>> What about the attached patch?  It seems to work well.
>>>
>>> SGTM.  With which cases did you test this?
>>> Adding Stefan, in case he has any comments.
>
> SGTM as well.
>

TBH, I'm not sure this is useful anymore, if the 'definition-name' slot is 
supposed to be used for such functions (which I didn't know).  WDYT?

>> +(defun help-function-def--find-probable-definition-place (fun)
>
> Can we shorten the name using "guess" i.s.o "find-probable"?
>
> Also, this should be in `find-func.el` rather than in `help-mode.el`, 
> no?
>

Yes and yes.

>> +                   (flatten-tree (symbol-function fun))))
>
> - We probably want to use `advice-cd*r` so as to flatten the actual 
> function definition rather than the combination of its definition with 
> the various pieces of advice that are currently applied.
>

You mean, (flatten-tree (advice--cd*r (symbol-function fun))), right?

>
> - The above works for non-compiled functions but for byte-compiled 
> functions we need an ad-hoc version of `flatten-tree` which extracts the 
> constants from the constant vector of bytecode objects (also recursively 
> since bytecode objects tend to contain other bytecode objects).
>
> For native-compiled functions, we may be able to get some kind of 
> "constant vector" as well, but I don't think that's currently accessible 
> from ELisp.  We should ask Andrea.
>

Are such dynamically defined functions not always non-compiled, by 
definition?  At least with the original recipe in this feature request, 
(symbol-file 'org-babel-execute:sh) returns "lisp/org/ob-shell.elc", so it 
has been created by a byte-compiled function.

>> +          ;; Exclude symbols that are 3 characters or less.
>> +          (when (> (length el) 9)
>
> If we filter them out when constructing `names`, we can use a comment 
> where the number matches the number used in the code :-)
>

Oh yes ;-)

>> +                    ;; Determine the beginning position of that
>> +                    ;; function.
>> +                    (goto-char (point-min))
>> +                    (when (catch 'found
>> +                            (while (re-search-forward
>> +                                    (concat "\\_<"
>> +                                            (regexp-quote result)
>> +                                            "\\_>"))
>> +                              (when (string= (lisp-current-defun-name)
>> +                                             result)
>> +                                (throw 'found t)))
>> +                            (throw 'found nil))
>> +                      (beginning-of-defun)
>> +                      (cons result (point)))))))))))))
>
> Can't we use `find-function-noselect` here?  Or maybe just return the 
> function name and let the caller then use `find-function-noselect`.
>

Indeed!

>> @@ -281,7 +366,31 @@ help-function-def--button-function
>>              (unless (= (point) position)
>>                (push-mark nil t))
>>              (goto-char position))
>> -        (message "Unable to find location in file")))))
>> +        (let ((probable-definition-place
>> +               (help-function-def--find-probable-definition-place fun)))
>> +          (when probable-definition-place
>> +            (goto-char (cdr probable-definition-place)))
>> +          (let ((help-buffer-under-preparation t))
>> +            (help-setup-xref (list #'help-function-def--button-function
>> +                                   fun file)
>> +		             (called-interactively-p 'interactive))
>> +	    (with-help-window (help-buffer)
>> +	      (insert (substitute-command-keys
>> +                       (format "Function %s could not be found in `%s'.\n\n"
>> +                              fun (file-name-nondirectory file))))
>> +              (setq help-mode--current-data (list :symbol fun
>> +                                                  :file file))
>> +	      (save-excursion
>> +	        (re-search-backward
>> +                 (substitute-command-keys "`\\([^`']+\\)'")
>> +                 nil t)
>> +	        (help-xref-button 1 'help-function-def fun file))
>> +              (when probable-definition-place
>> +                (insert (substitute-command-keys
>> +                         (format "It was probably defined by `%s'.\n\n"
>> +                                (car probable-definition-place)))))
>> +	      (insert "Function definition:\n\n")
>> +	      (insert (pp-to-string (symbol-function fun))))))))))
>
> Please move this to a separate function.
>

Sure.

>
> Also, I'm not completely convinced what you do with the *Help* buffer 
> here is the UI we'll want, really.  But I don't have a good idea for 
> what to replace it with (yet), so we can start with that and tweak it 
> later.
>

Okay.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 60568 <at> debbugs.gnu.org, yantar92 <at> posteo.net, Eli Zaretskii <eliz <at> gnu.org>,
 mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Fri, 06 Jan 2023 19:36:04 -0500

>>>>> What about the attached patch?  It seems to work well.
>>>> SGTM.  With which cases did you test this?
>>>> Adding Stefan, in case he has any comments.
>> SGTM as well.
> TBH, I'm not sure this is useful anymore, if the 'definition-name' slot is
> supposed to be used for such functions (which I didn't know).  WDYT?

If you look at the code of `find-func.el` you'll see that we already
rely on heuristics, so it seems like a natural complement.
But I agree that `definition-name` is usually preferable since it's more
reliable.  Still most people don't know `definition-name`, so it can
still be helpful.

>> - We probably want to use `advice-cd*r` so as to flatten the actual
>> function definition rather than the combination of its definition with the
>> various pieces of advice that are currently applied.
> You mean, (flatten-tree (advice--cd*r (symbol-function fun))), right?

Yes.

>> - The above works for non-compiled functions but for byte-compiled
>> functions we need an ad-hoc version of `flatten-tree` which extracts the
>> constants from the constant vector of bytecode objects (also recursively
>> since bytecode objects tend to contain other bytecode objects).
>>
>> For native-compiled functions, we may be able to get some kind of
>> "constant vector" as well, but I don't think that's currently accessible
>> from ELisp.  We should ask Andrea.
>
> Are such dynamically defined functions not always non-compiled, by
> definition?

No.  They can be defined by macros rather than functions in which case
they'll usually be compiled.  Or they may be closures defined locally
within another defun, in which case again they'll usually be compiled.
[ E.g. with the patch to `ob-shell.el` that I sent, the
`org-babel-execute:sh` is byte-compiled.  ]

> At least with the original recipe in this feature request,
> (symbol-file 'org-babel-execute:sh) returns "lisp/org/ob-shell.elc", so it
> has been created by a byte-compiled function.

The `ob-shell.el` code in master creates the functions at run time via
`eval`, so they're created while loading `ob-shell.elc` but
they're interpreted.  With my patch, they're just closures so their body
is compiled when `ob-shell.el` is compiled.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: gregory <at> heytings.org, yantar92 <at> posteo.net, 60568 <at> debbugs.gnu.org,
 mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 08:55:38 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 60568 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,
>   yantar92 <at> posteo.net,  mardani29 <at> yahoo.es
> Date: Fri, 06 Jan 2023 19:36:04 -0500
> 
> >>>>> What about the attached patch?  It seems to work well.
> >>>> SGTM.  With which cases did you test this?
> >>>> Adding Stefan, in case he has any comments.
> >> SGTM as well.
> > TBH, I'm not sure this is useful anymore, if the 'definition-name' slot is
> > supposed to be used for such functions (which I didn't know).  WDYT?
> 
> If you look at the code of `find-func.el` you'll see that we already
> rely on heuristics, so it seems like a natural complement.
> But I agree that `definition-name` is usually preferable since it's more
> reliable.  Still most people don't know `definition-name`, so it can
> still be helpful.

Maybe people will know better if definition-name would be documented.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: yantar92 <at> posteo.net, mardani29 <at> yahoo.es,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 09:42:51 +0000

>> If you look at the code of `find-func.el` you'll see that we already 
>> rely on heuristics, so it seems like a natural complement. But I agree 
>> that `definition-name` is usually preferable since it's more reliable. 
>> Still most people don't know `definition-name`, so it can still be 
>> helpful.
>
> Maybe people will know better if definition-name would be documented.
>

I think the place where it should be documented is the suggested *Help* 
screen, with a sentence like "To ensure an accurate identification of the 
place where `frobnicate' was defined, the definition-name slot of the 
`frobnicate' symbol should be set ."

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 11:32:14 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> 1. emacs -Q
>> 2. M-: (require 'ob-shell)
>> 3. <F1> f org-babel-execute:sh <RET>
>> 4. Click on the source code link in *Help* buffer
>> 5. Observe point jumping to (point-min) with no obvious way to find the
>>    function definition.
>
> We have `definition-name` for that.
> I.e. `org-babel-shell-initialize` should arguably do
>
>     (put 'org-babel-execute:sh 'definition-name 'org-babel-shell-initialize)
>
> so that step 4 above jumps to `org-babel-shell-initialize`.
>
> The patch below does that, along with saving some kittens.

Thanks!

> +    (funcall (if (fboundp 'defvar-1) #'defvar-1 #'set) ;Emacs-29
> +             (intern (concat "org-babel-default-header-args:" name))
> +             '())))

Why '()?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 13:14:56 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> If you look at the code of `find-func.el` you'll see that we already
>> rely on heuristics, so it seems like a natural complement.
>> But I agree that `definition-name` is usually preferable since it's more
>> reliable.  Still most people don't know `definition-name`, so it can
>> still be helpful.
>
> Maybe people will know better if definition-name would be documented.

May it also be a declare form?
Or is there an exhaustive list of symbol properties used by Emacs?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, mardani29 <at> yahoo.es,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 13:38:22 +0000

Gregory Heytings <gregory <at> heytings.org> writes:

>> Maybe people will know better if definition-name would be documented.
>>
>
> I think the place where it should be documented is the suggested *Help* 
> screen, with a sentence like "To ensure an accurate identification of the 
> place where `frobnicate' was defined, the definition-name slot of the 
> `frobnicate' symbol should be set ."

But is it of interest for _users_? I'd rather see it in Elisp manual.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es, monnier <at> iro.umontreal.ca,
 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 15:55:05 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, gregory <at> heytings.org,
>  60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
> Date: Sat, 07 Jan 2023 13:14:56 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> If you look at the code of `find-func.el` you'll see that we already
> >> rely on heuristics, so it seems like a natural complement.
> >> But I agree that `definition-name` is usually preferable since it's more
> >> reliable.  Still most people don't know `definition-name`, so it can
> >> still be helpful.
> >
> > Maybe people will know better if definition-name would be documented.
> 
> May it also be a declare form?
> Or is there an exhaustive list of symbol properties used by Emacs?

See the node "Standard Properties" in the ELisp manual.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es, monnier <at> iro.umontreal.ca,
 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 16:00:14 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
> Date: Sat, 07 Jan 2023 13:38:22 +0000
> 
> Gregory Heytings <gregory <at> heytings.org> writes:
> 
> >> Maybe people will know better if definition-name would be documented.
> >>
> >
> > I think the place where it should be documented is the suggested *Help* 
> > screen, with a sentence like "To ensure an accurate identification of the 
> > place where `frobnicate' was defined, the definition-name slot of the 
> > `frobnicate' symbol should be set ."
> 
> But is it of interest for _users_? I'd rather see it in Elisp manual.

Yes, IMO it should be documented in the ELisp manual.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, mardani29 <at> yahoo.es,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 14:04:13 +0000

>>> Maybe people will know better if definition-name would be documented.
>>
>> I think the place where it should be documented is the suggested *Help* 
>> screen, with a sentence like "To ensure an accurate identification of 
>> the place where `frobnicate' was defined, the definition-name slot of 
>> the `frobnicate' symbol should be set."
>
> But is it of interest for _users_? I'd rather see it in Elisp manual.
>

It should be documented in the Elisp manual, indeed.  What I said was a 
bit unclear: I meant that a reminder should be displayed in the *Help* 
buffer.  With this, Elisp programmers who are not aware of that subtlety 
would become aware of it.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, mardani29 <at> yahoo.es,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 15:07:33 +0000

Gregory Heytings <gregory <at> heytings.org> writes:

>>
>> But is it of interest for _users_? I'd rather see it in Elisp manual.
>>
>
> It should be documented in the Elisp manual, indeed.  What I said was a 
> bit unclear: I meant that a reminder should be displayed in the *Help* 
> buffer.  With this, Elisp programmers who are not aware of that subtlety 
> would become aware of it.

Then, may "13.4 Defining Functions" be a good place to link to this
subtlety?

The documentation for `defalias' is not really very clear, even now,
when I am aware about the issue herein:

     The proper place to use ‘defalias’ is where a specific function or
     macro name is being defined—especially where that name appears
     explicitly in the source file being loaded.  This is because
     ‘defalias’ records which file defined the function, just like
     ‘defun’ (*note Unloading::).

     By contrast, in programs that manipulate function definitions for
     other purposes, it is better to use ‘fset’, which does not keep
     such records.  *Note Function Cells::.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es, monnier <at> iro.umontreal.ca,
 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 17:14:02 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
>  60568 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
> Date: Sat, 07 Jan 2023 15:07:33 +0000
> 
> Gregory Heytings <gregory <at> heytings.org> writes:
> 
> >>
> >> But is it of interest for _users_? I'd rather see it in Elisp manual.
> >>
> >
> > It should be documented in the Elisp manual, indeed.  What I said was a 
> > bit unclear: I meant that a reminder should be displayed in the *Help* 
> > buffer.  With this, Elisp programmers who are not aware of that subtlety 
> > would become aware of it.
> 
> Then, may "13.4 Defining Functions" be a good place to link to this
> subtlety?
> 
> The documentation for `defalias' is not really very clear, even now,
> when I am aware about the issue herein:
> 
>      The proper place to use ‘defalias’ is where a specific function or
>      macro name is being defined—especially where that name appears
>      explicitly in the source file being loaded.  This is because
>      ‘defalias’ records which file defined the function, just like
>      ‘defun’ (*note Unloading::).
> 
>      By contrast, in programs that manipulate function definitions for
>      other purposes, it is better to use ‘fset’, which does not keep
>      such records.  *Note Function Cells::.

FWIW, I don't see anything unclear here.  Moreover, what does defalias
have to do with the issue of links to code of generated functions?

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es, monnier <at> iro.umontreal.ca,
 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 15:19:12 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Then, may "13.4 Defining Functions" be a good place to link to this
>> subtlety?
>> 
>> The documentation for `defalias' is not really very clear, even now,
>> when I am aware about the issue herein:
>> 
>>      The proper place to use ‘defalias’ is where a specific function or
>>      macro name is being defined—especially where that name appears
>>      explicitly in the source file being loaded.  This is because
>>      ‘defalias’ records which file defined the function, just like
>>      ‘defun’ (*note Unloading::).
>> 
>>      By contrast, in programs that manipulate function definitions for
>>      other purposes, it is better to use ‘fset’, which does not keep
>>      such records.  *Note Function Cells::.
>
> FWIW, I don't see anything unclear here.  Moreover, what does defalias
> have to do with the issue of links to code of generated functions?

The above says that `defalias' "records which file defined the
function". It appears to be related to what we are discussing here -
locating the function definition.

However, the present manual description does not talk what "records"
refers to. I presume that the records are to be used by *Help* system.
If so, it also makes sense to elaborate. Either here, or in other node
linked from here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es, monnier <at> iro.umontreal.ca,
 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 17:23:01 +0200

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: gregory <at> heytings.org, monnier <at> iro.umontreal.ca, 60568 <at> debbugs.gnu.org,
>  mardani29 <at> yahoo.es
> Date: Sat, 07 Jan 2023 15:19:12 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Then, may "13.4 Defining Functions" be a good place to link to this
> >> subtlety?
> >> 
> >> The documentation for `defalias' is not really very clear, even now,
> >> when I am aware about the issue herein:
> >> 
> >>      The proper place to use ‘defalias’ is where a specific function or
> >>      macro name is being defined—especially where that name appears
> >>      explicitly in the source file being loaded.  This is because
> >>      ‘defalias’ records which file defined the function, just like
> >>      ‘defun’ (*note Unloading::).
> >> 
> >>      By contrast, in programs that manipulate function definitions for
> >>      other purposes, it is better to use ‘fset’, which does not keep
> >>      such records.  *Note Function Cells::.
> >
> > FWIW, I don't see anything unclear here.  Moreover, what does defalias
> > have to do with the issue of links to code of generated functions?
> 
> The above says that `defalias' "records which file defined the
> function". It appears to be related to what we are discussing here -
> locating the function definition.

Tangentially at best.

> However, the present manual description does not talk what "records"
> refers to. I presume that the records are to be used by *Help* system.
> If so, it also makes sense to elaborate. Either here, or in other node
> linked from here.

We must find a better place.

And the main problem is not where to document this (its natural place
is where all the standard properties are described), the main problem
is how to index it so that people could easily find it.  Also, where
else to mention that property in the manual, in related context.  We
don't seem to have anything about generating code...

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Sat, 07 Jan 2023 10:44:07 -0500

>> The patch below does that, along with saving some kittens.
> Thanks!

As always, my patch is 100% untested.

>> +    (funcall (if (fboundp 'defvar-1) #'defvar-1 #'set) ;Emacs-29
>> +             (intern (concat "org-babel-default-header-args:" name))
>> +             '())))
>
> Why '()?

No idea.  I just tried to preserve the part of the code I didn't feel
like changing.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: yantar92 <at> posteo.net
Cc: 60568 <at> debbugs.gnu.org, gregory <at> heytings.org, monnier <at> iro.umontreal.ca,
 mardani29 <at> yahoo.es
Subject: Re: bug#60568: [FR] 30.0.50;
 Help buffers and function bodies for generated functions
Date: Sat, 07 Jan 2023 19:59:22 +0200

> Cc: gregory <at> heytings.org, mardani29 <at> yahoo.es, monnier <at> iro.umontreal.ca,
>  60568 <at> debbugs.gnu.org
> Date: Sat, 07 Jan 2023 17:23:01 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > However, the present manual description does not talk what "records"
> > refers to. I presume that the records are to be used by *Help* system.
> > If so, it also makes sense to elaborate. Either here, or in other node
> > linked from here.
> 
> We must find a better place.
> 
> And the main problem is not where to document this (its natural place
> is where all the standard properties are described), the main problem
> is how to index it so that people could easily find it.  Also, where
> else to mention that property in the manual, in related context.  We
> don't seem to have anything about generating code...

I believe I found a good place for that, please take a look at the
emacs-29 branch.

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

From: Ihor Radchenko <yantar92 <at> posteo.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 60568 <at> debbugs.gnu.org
Subject: Re: bug#60568: [FR] 30.0.50; Help buffers and function bodies for
 generated functions
Date: Thu, 12 Jan 2023 10:40:21 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> The patch below does that, along with saving some kittens.
>> Thanks!
>
> As always, my patch is 100% untested.
>
>>> +    (funcall (if (fboundp 'defvar-1) #'defvar-1 #'set) ;Emacs-29
>>> +             (intern (concat "org-babel-default-header-args:" name))
>>> +             '())))
>>
>> Why '()?
>
> No idea.  I just tried to preserve the part of the code I didn't feel
> like changing.

I went with "nil".

Applied, onto main. All the tests are passing.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ecb62e2e3

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

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