From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#60568: [FR] 30.0.50; Help buffers and function bodies for generated functions Date: Thu, 05 Jan 2023 10:32:05 +0200 Message-ID: <835ydlxtyy.fsf@gnu.org> References: <87fscpifdw.fsf@localhost> <83a62xxuzs.fsf@gnu.org> <877cy1ie9m.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2560"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60568@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 05 09:32:46 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pDLg6-0000T8-4R for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Jan 2023 09:32:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pDLfQ-00046a-EZ; Thu, 05 Jan 2023 03:32:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDLfO-00043W-B0 for bug-gnu-emacs@gnu.org; Thu, 05 Jan 2023 03:32:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pDLfN-0000mA-Tg for bug-gnu-emacs@gnu.org; Thu, 05 Jan 2023 03:32:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pDLfN-0002ko-Lg for bug-gnu-emacs@gnu.org; Thu, 05 Jan 2023 03:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 08:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60568 X-GNU-PR-Package: emacs Original-Received: via spool by 60568-submit@debbugs.gnu.org id=B60568.167290751910576 (code B ref 60568); Thu, 05 Jan 2023 08:32:01 +0000 Original-Received: (at 60568) by debbugs.gnu.org; 5 Jan 2023 08:31:59 +0000 Original-Received: from localhost ([127.0.0.1]:50208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDLfK-0002kW-T8 for submit@debbugs.gnu.org; Thu, 05 Jan 2023 03:31:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDLfJ-0002kK-OL for 60568@debbugs.gnu.org; Thu, 05 Jan 2023 03:31:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDLfE-0000lK-Bz; Thu, 05 Jan 2023 03:31:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=39MDWpKYQ9aQ+iPa0Ijfj1ps+ta42k7SP0GpLn1Ftmw=; b=Is967UJOPVNc ChCHUbeoBQt+IHBdTMYtGC2B3GNrKWgWgMUEAoxiLFmjKSZ8xx/AbK9JgjOuvxt+ec1mtL023fPSr aDAvVAIjC3V8HndRJ3tCsttNqGp46bHowt5dblBCVqBqWv7XuG904V69G/mSO6EWXbmc3LP8LILiv XVvcisuC1JbNUz1FYWJrVvYnU2PdA2ozUTxremHn334k/srBPP6oKXnsVetRfBkHaE+Gya4JtYEZU YZhdzqGKERl6oC2+i3NW7glG8XufX0kdIhnJdLDoBujIUmNWuSR4D6+yr5MkJJiH/k7ecKsyJxh47 mSNO6DxbyX9u6Pp3LJ3PfA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDLfC-0000yQ-Gd; Thu, 05 Jan 2023 03:31:51 -0500 In-Reply-To: <877cy1ie9m.fsf@localhost> (message from Ihor Radchenko on Thu, 05 Jan 2023 08:20:21 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252572 Archived-At: > From: Ihor Radchenko > Cc: 60568@debbugs.gnu.org > Date: Thu, 05 Jan 2023 08:20:21 +0000 > > Eli Zaretskii 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.