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#46627: [PATCH] Add new help command 'describe-command' Date: Mon, 01 Mar 2021 08:05:21 +0200 Message-ID: <83k0qr8l3y.fsf@gnu.org> References: <835z2o4fes.fsf@gnu.org> <83k0r1xwyy.fsf@gnu.org> <83blcdxqzy.fsf@gnu.org> <831rd9xox5.fsf@gnu.org> <3801b6be-dd65-c256-6c57-52894fad2b12@yandex.ru> <83pn0tw564.fsf@gnu.org> <83k0r0w2q5.fsf@gnu.org> <83v9acm7bk.fsf@gnu.org> <30bc14e5-febb-aab1-410b-5a56f9fe1843@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10184"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, stefan@marxist.se, rms@gnu.org, 46627@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 01 07:08:12 2021 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 1lGbj2-0002Xl-3g for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Mar 2021 07:08:12 +0100 Original-Received: from localhost ([::1]:37490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGbj1-0005QY-5x for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Mar 2021 01:08:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47206) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGbhv-0004sQ-0n for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 01:07:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36285) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lGbhu-00084y-7T for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 01:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lGbht-000711-Uq for bug-gnu-emacs@gnu.org; Mon, 01 Mar 2021 01:07: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: Mon, 01 Mar 2021 06:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46627-submit@debbugs.gnu.org id=B46627.161457877226891 (code B ref 46627); Mon, 01 Mar 2021 06:07:01 +0000 Original-Received: (at 46627) by debbugs.gnu.org; 1 Mar 2021 06:06:12 +0000 Original-Received: from localhost ([127.0.0.1]:47831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGbh6-0006ze-BD for submit@debbugs.gnu.org; Mon, 01 Mar 2021 01:06:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGbh3-0006zP-9u for 46627@debbugs.gnu.org; Mon, 01 Mar 2021 01:06:11 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39168) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGbgu-0007TH-Sm; Mon, 01 Mar 2021 01:06:03 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1978 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lGbgM-0004JX-5Y; Mon, 01 Mar 2021 01:05:40 -0500 In-Reply-To: <30bc14e5-febb-aab1-410b-5a56f9fe1843@yandex.ru> (message from Dmitry Gutov on Sun, 28 Feb 2021 23:40:06 +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" Xref: news.gmane.io gmane.emacs.bugs:201057 Archived-At: > Cc: larsi@gnus.org, stefan@marxist.se, rms@gnu.org, 46627@debbugs.gnu.org > From: Dmitry Gutov > Date: Sun, 28 Feb 2021 23:40:06 +0200 > > On 28.02.2021 19:27, Eli Zaretskii wrote: > > >> Do you have in mind some particular "completion alternative we have > >> already" for 'describe-command'? > > > > icomplete.el, completion.el, pcomplete.el, and the non-default styles > > in completion-styles-alist come to mind. > > All of these (with possible exception of completion.el, which I'm not > familiar with) determine how completions are shown and/or how matching > is performed, but the total set of completions (completion table) is > determined by the command the user invokes. The completion style does determine the set of candidates, if that's the only aspect you are interested in. And the way the candidates are presented is an important part of how easy and user-friendly discovery is. > So they don't include anything that looks like a replacement for > 'describe-command'. I wasn't talking only about describe-command, not even in particular about it. I was talking about a much more general issue. If describe-command is the only addition, then I have no problems with that; I only care if that command is the tip of a much larger iceberg. > > This loses the context. Minor improvements were not the issue I > > raised, the issue was the perceived attempt to build a significant > > discovery framework based on completion. > > "Significant discovery framework" is something very ill-defined. From > where I'm standing, function and variable discovery based on completion > is already in Emacs, and we sometimes provide minor fixes and > improvement for it (such as this command). Then we are in fact in violent agreement. > Sometimes we do request major changes that would help it as well... That's the issue at hand. I don't think we need or should entertain major changes in that area. > > I have nothing against providing infrastructure for more sophisticated > > completion, I was talking only about adding new commands which aim to > > provide discovery based on completion, > > But which otherwise duplicate existing commands? Duplicate functionality, not commands. > > or extend existing > > completion-related commands with the goal of providing discovery > > through them. > > Do you mean like extensions of the completion-at-point interface with > that aim? I'm curious about possibilities, but so far we haven't really > discussed them here. I don't know what I mean, I will know when actual proposals are brought up.