bug#46627: [PATCH] Add new help command 'describe-command'

[Eli Zaretskii <eliz@gnu.org>]

> Cc: larsi@gnus.org, stefan@marxist.se, rms@gnu.org, 46627@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.