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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60568 <at> debbugs.gnu.org
Subject: 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.

Previous Next

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