From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#71117: 30.0.50; output of describe-function Date: Tue, 28 May 2024 18:25:05 -0400 Message-ID: References: <24a8c119-5b86-46f0-bbf0-e9d9d5b77713@easy-emacs.de> <87ikz5g2ou.fsf@gmail.com> <86sey966x1.fsf@gnu.org> <87ikz5v65p.fsf@gmail.com> <86h6ep5cbq.fsf@gnu.org> <86ikyxu7br.fsf@gnu.org> <87r0dl4mqd.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33361"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , andreas.roehler@easy-emacs.de, 71117@debbugs.gnu.org To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 29 00:26:23 2024 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 1sC5Gx-0008Oh-JB for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 May 2024 00:26:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sC5GV-0006MH-AR; Tue, 28 May 2024 18:25:55 -0400 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 1sC5GT-0006LY-0i for bug-gnu-emacs@gnu.org; Tue, 28 May 2024 18:25:53 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sC5GS-0002Nb-Oh for bug-gnu-emacs@gnu.org; Tue, 28 May 2024 18:25:52 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sC5Gb-0007eK-Tq for bug-gnu-emacs@gnu.org; Tue, 28 May 2024 18:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 May 2024 22:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71117 X-GNU-PR-Package: emacs Original-Received: via spool by 71117-submit@debbugs.gnu.org id=B71117.171693512529336 (code B ref 71117); Tue, 28 May 2024 22:26:01 +0000 Original-Received: (at 71117) by debbugs.gnu.org; 28 May 2024 22:25:25 +0000 Original-Received: from localhost ([127.0.0.1]:60556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sC5G1-0007d5-58 for submit@debbugs.gnu.org; Tue, 28 May 2024 18:25:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sC5Fy-0007co-P9 for 71117@debbugs.gnu.org; Tue, 28 May 2024 18:25:23 -0400 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 1sC5Fi-0002K7-PV; Tue, 28 May 2024 18:25:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=8EemK2cyaza3nVvGh0+wcX9RJpQQo0qOkyn2bLx2wKY=; b=L6CHVLyFw2vcVo/N91yO BBKLN2GpzsAThHjx0iSqwxse7iMowFYA7ulY1sWtOy1fW38sxwJkDxcjpXHRaeigSZSgssrHvxr1d Iaj6a+BOCfT56m0Vf5XTt/HooKeb4R1j0xKT6192TwwOtJDPQ0L2qo/O4LvRLzX3gXvFvX811gUWz BYzeRSkUTrT8GeC64wadwuzuek/HPgmIi4kl4oiNyUj8YDt7AAYGIb1A9RqcthjniHQ+QQqMRhEYB qjRqtSR0hRBqjXFhv0xS3y9yNDqiF6NF5mGMPNpc4u5M5pt/TWY0sHAq+T8IYe5X5PuMxfnSP9mLq PyeQZ2NuP6cLpw==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sC5Fh-0006jP-N4; Tue, 28 May 2024 18:25:05 -0400 In-Reply-To: <87r0dl4mqd.fsf@gmail.com> ("=?UTF-8?Q?K=C3=A9vin?= Le Gouguec"'s message of "Wed, 29 May 2024 00:04:26 +0200") 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:286128 Archived-At: K=C3=A9vin Le Gouguec writes: > Andrea Corallo writes: > >> Eli Zaretskii writes: >> >>>> From: Andrea Corallo >>>> Cc: K=C3=A9vin Le Gouguec , >>>> 71117@debbugs.gnu.org, >>>> andreas.roehler@easy-emacs.de >>>> Date: Tue, 28 May 2024 13:44:33 -0400 >>>>=20 >>>> >> Were you thinking of a command that specifically targets the symbol= from >>>> >> a displayed *Help* buffer, so the user would do e.g. >>>> >>=20 >>>> >> C-h v VAR RET ; shows *Help* for VAR >>>> >> C-h SOMETHING ; finds source for VAR >>>> >>=20 >>>> >> where C-h SOMETHING's implementation would do (a smarter version of) >>>> >> (with-current-buffer "*Help*" >>>> >> (help-view-source)) >>>> >>=20 >>>> >> ? >>>> > >>>> > Yes, exactly. >>>>=20 >>>> Something like the attached? >>>>=20 >>>> It makes C-h z FUNCTION find the source for FUNCTION. >>> >>> I might be mistaken, but I don't think this is what I had in mind. >> >> You are not. >> >>> My use case is exactly like described above: I type "C-h v" or "C-h >>> f", which displays the *Help* buffer in the other window. Then I want >>> to go to the source where the variable or function are defined, but >>> without the need to switch to the window showing *Help*. >> >> The attached is my understanding of what we want (still using C-h z). >> K=C3=A9vin's mail make me suspect I've been too naive but anyway =F0=9F= =98=85... > > I don't actually have concrete examples where my allegedly-not-so-smart > serving suggestion might fail =F0=9F=98=89 The best I can come up with are > what-ifs, e.g. "what if a user advises describe-* functions to rename > *Help* buffers to something non-standard like *Help *"; my answer > then would be "describe-* commands could set some variable, > e.g. last-help-buffer, that 'C-h z' could then consult". > > That's if we cared to support this kind of edge case, of course. I thought about the variable but I didn't like to have to maintain a status more (ie clean the variable when *Help* is killed). OTOH in help-fns-tests.el we already have a good number of hard-coded '*Help*' around, so I think the current status quo is that we don't care. > Re. the binding: if we are entering "Do Something With That Help Buffer > I Just Invoked"-land, I wonder if we should stop at view-source; I could > imagine users wanting to do other useful things like goto-info or > customize. In which case maybe we can find a mnemonic prefix to tuck > all these actions? > > Thinking of e.g. 'C-h 4' (for the "other-window" connotation) or 'C-h H' > (for "current _H_elp buffer"); help-find-source would then be bound to > 'C-h 4 s', for example. > > (info-other-window currently hogs 'C-h 4 i' unfortunately=E2=80=A6 though > nowadays 'C-x 4 4 i' also works, and 'C-x 4 i' is currently free =F0=9F= =A4=94 > > 'C-x 4 h' is also free to use as a prefix, but maybe a bit of a > fingerful) > > Don't give too much weight to my ramblings; I find 'C-h z' a bit > cryptic, but I don't know that my alternatives are better. I think those are actually good points, 'C-h z' is not very nice and 'C-h 4 s' would be probably easier to remember as 's' has the same meaning in the *Help* buffer it-self. Andrea