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: Sun, 28 Feb 2021 19:27:11 +0200 Message-ID: <83v9acm7bk.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15641"; 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 Sun Feb 28 18:28:13 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 1lGPrY-0003yC-ND for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Feb 2021 18:28:12 +0100 Original-Received: from localhost ([::1]:37906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGPrX-0006Lh-Nu for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Feb 2021 12:28:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33860) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lGPrN-0006JE-Bj for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2021 12:28:01 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35577) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lGPrN-0006yq-3t for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2021 12:28:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lGPrN-0007Mf-In for bug-gnu-emacs@gnu.org; Sun, 28 Feb 2021 12:28: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: Sun, 28 Feb 2021 17:28: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.161453326428287 (code B ref 46627); Sun, 28 Feb 2021 17:28:01 +0000 Original-Received: (at 46627) by debbugs.gnu.org; 28 Feb 2021 17:27:44 +0000 Original-Received: from localhost ([127.0.0.1]:47123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGPr2-0007M7-Pz for submit@debbugs.gnu.org; Sun, 28 Feb 2021 12:27:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGPr1-0007Lv-4t for 46627@debbugs.gnu.org; Sun, 28 Feb 2021 12:27:39 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52367) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGPqu-0006lv-Ja; Sun, 28 Feb 2021 12:27:32 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3303 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lGPqg-0005S3-CQ; Sun, 28 Feb 2021 12:27:19 -0500 In-Reply-To: (message from Dmitry Gutov on Sat, 27 Feb 2021 22:38:31 +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:201017 Archived-At: > Cc: larsi@gnus.org, stefan@marxist.se, rms@gnu.org, 46627@debbugs.gnu.org > From: Dmitry Gutov > Date: Sat, 27 Feb 2021 22:38:31 +0200 > > > We are not ignoring the current practices. We are saying that people > > who want their discovery based on completion will find the solution in > > the completion alternatives we have already in Emacs, and if that > > still doesn't fit the bill, in the 3rd-party packages out there. > > 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. > > I > > think Emacs provides, and will continue providing, ample > > infrastructure for such extensions, and that's enough, IMO. There's > > no reason we should feel obliged to develop these features in Emacs. > > We will never be able to satisfy everyone there anyway. > > I believe the argument is that we can improve the default experience by > enacting some minor changes which correspond to what we know about how > users discover new commands (or functions) or remember existing ones. > And do that without pulling in major new functionality or features from > third-party packages (which goes against the "lean core" concept which > you probably know I prefer). 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. > There were also suggestions for admittedly more invasive changes (like > doing a bunch of renames in the standard library) which seem to have all > been rejected by the leadership. I understand the reluctance to change > things, but the argument about Emacs's extensibility and the 3rd party > ecosystem wouldn't apply to it either because no matter how convenient > and slick an external package might make completion experience, if the > functions are irregularly named, that will remain a problem anyway. How is this relevant to the issue at hand? > So you might disagree on whether this feature is important. But I hope > you can see how some aspects of the "whole new discovery framework" > (which I'm saying isn't new) cannot be effectively enacted by 3rd party > code without help from us here. 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, or extend existing completion-related commands with the goal of providing discovery through them.