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:09:59 +0200 Message-ID: <83a62xxuzs.fsf@gnu.org> References: <87fscpifdw.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="457"; 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:10:30 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 1pDLKY-000ARr-9T for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Jan 2023 09:10:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pDLKC-000867-EP; Thu, 05 Jan 2023 03:10:08 -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 1pDLK6-00085k-Hg for bug-gnu-emacs@gnu.org; Thu, 05 Jan 2023 03:10:06 -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 1pDLK6-0003KJ-3D for bug-gnu-emacs@gnu.org; Thu, 05 Jan 2023 03:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pDLK5-0002A7-IY for bug-gnu-emacs@gnu.org; Thu, 05 Jan 2023 03:10: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:10: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.16729061938292 (code B ref 60568); Thu, 05 Jan 2023 08:10:01 +0000 Original-Received: (at 60568) by debbugs.gnu.org; 5 Jan 2023 08:09:53 +0000 Original-Received: from localhost ([127.0.0.1]:50182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDLJx-00029f-Aa for submit@debbugs.gnu.org; Thu, 05 Jan 2023 03:09:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDLJv-00029S-AS for 60568@debbugs.gnu.org; Thu, 05 Jan 2023 03:09:51 -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 1pDLJp-0003Iq-Qx; Thu, 05 Jan 2023 03:09:45 -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=5MlZ/Y2vfpUvLYwizp0Ii0wsy1Wa/hNb2xtIO0rKPOw=; b=T5J9A7T8whzM cTcFT+vdjbxtad4iyBDUZ1nbY3zlP7VjKgn8YW1TJejxXbcSm4durZ5F00AuIXrvBcRsedNcHuT/b gu1F6j5k1fL00vXo7mCHH0XCtGZCeYg5CLvLUsSj6i82ovZIoug4ioJJl0ga2tC6TSyiATSOLrrqL Sbxxuqotu5qdCwDv84Goca7olqh1U4a+BhrzOXYi/qTZwLwvXZHe2xzw2mBbWKP5iUFGd/rX7r4V5 O4clMbBj88YOGIHJLLoRlTfskudsqlGS/1h4EXNnXiuzIl4wy9xn2TAZpXDKNuM9oErwHShEhDbQU zXVyUuGtYeWerTwnK0c59Q==; 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 1pDLJp-0007Eb-9b; Thu, 05 Jan 2023 03:09:45 -0500 In-Reply-To: <87fscpifdw.fsf@localhost> (message from Ihor Radchenko on Thu, 05 Jan 2023 07:56:11 +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:252568 Archived-At: > From: Ihor Radchenko > 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. f org-babel-execute:sh > 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.