bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#46627: [PATCH] Add new help command 'describe-command'
Date: Sun, 21 Feb 2021 19:36:17 +0200

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sun, 21 Feb 2021 11:01:11 -0600
> Cc: rms@gnu.org, larsi@gnus.org, 46627@debbugs.gnu.org
> 
> So I type `C-h a foobar RET'.
> 
> Now I realize I want to look for "foobaz", so `C-h a foobaz RET'.
> 
> Now I realize that oops, I meant "barsnaz", etc.
> 
> Typing this at a prompt is often faster for me.  In particular, I don't
> need to rewrite everything for minor changes.
> 
> Yes, I can be smarter and say `C-h a M-p DEL z RET', but I think we can
> agree that `DEL z TAB' is less typing.

No, I think you are splitting hair.  Typing one more key justifies a
whole new command?  Really?

And I'm not even talking about the display you get with "C-h a", which
is much more informative than what completion shows.

> (BTW, with many completion frameworks you don't even need the TAB.)

We are talking about features that are built-in.  Otherwise, why did
we add a new command for getting help on commands, when it's so easy
to get it from other completion frameworks?

> Plus I often look only for names, and don't need to waste screen real
> estate on documentation (which I would using apropos).

Displaying completion candidates doesn't use any screen estate?

> I don't see that we need to agree about the relative efficiency of these
> workflows.  We can and do support both workflows well.

See my other message: building a discovery subsystem starting from
completion reinvents the wheel, and begins from an inferior starting
point.  If that's not an argument worth considering, from the project
management POV, then I don't know what is.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]