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

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

bug#46627: [External] : bug#46627: [PATCH] Add new help command 'describ


From: Drew Adams
Subject: bug#46627: [External] : bug#46627: [PATCH] Add new help command 'describe-command'
Date: Mon, 1 Mar 2021 16:13:33 +0000

> There is no need to count.  You just keep typing TAB until you get
> what you want.  When it alternates between all functions and only
> commands, you'll see the number of completions change in an obvious
> way.
> 
> Another advantage is that this gives you both completion spaces
> in every command that reads a function name, not only in
> describe-function.
> 
> We should try this and see what it is like, then judge it.

Having a general ability to switch or transform
the domain of candidates - that is, the initial
set (after filtering with the PREDICATE arg)
before any user filtering by minibuffer input -
is indeed a fine feature.

Icicles has such a toggle, bound to `C-$' during
completion.  It toggles between using the initial
set and the initial set "transformed" in some way.

The default transformation is to remove duplicate
candidates.  (Duplicate candidates can be useful,
in general.)  A given command can define its own
transformation function for this, and bind it to
variable `icicle-transform-function'.

But for something like `C-h f', it makes sense to
have a prefix arg limit the candidates to commands.
For that, there's no need to wait for a general
transform-toggle feature.

And it makes sense to also have a separate command,
`describe-command'.  And to have a prefix arg to it
extend the candidate set to include all functions
(a reverse of the swap of the previous paragraph).
___

As for letting `TAB' switch completion tables or
otherwise transform the initial candidate set:
that too is a possibility.  I'd agree that trying
such ideas and seeing what people think can be a
useful experiment.

Personally, I'd prefer that such trials be done
in the form of 3rd-party efforts.  See what kind
of use and feedback it results in outside Emacs.

"Trials" in Emacs itself are not so great, IMO.
Someone puts something on a branch and invites
trial and feedback.  But the only people who try
it are Emacs Dev aficionados who build Emacs or
pull stuff from Git etc.  That's more for large
developments, like bidi support.

Wrt TAB as a key for this: Sure, try it.  But a
priori I'm not in favor of reusing TAB this way.
TAB should be for something that will be used a
lot and that needs to be quick.  That's not the
case here.

As an example, Icicles, like vanilla Emacs, uses
TAB to complete, but repeating TAB then cycles
among the candidates.  That's an operation that
you can repeat often and quickly.

Emacs's own binding of TAB to scroll *Completions*
is not a good key choice, IMO.  Much better for
scrolling *Completions* is to use the usual keys:
`C-v' and `M-v'.  (It's natural for them to scroll
*Completions* and not the minibuffer itself.)
Icicles does that.

But again - the kind of idea you suggested is just
what we need more of: ideas about extending or
otherwise improving user interaction with the set
of completion candidates.

And again, I agree that the right approach wrt
such ideas is for people to try them out and
provide feedback.  I'd sooner see that happen
with a 3rd-party library than with an Emacs
branch, but I suppose that's a detail. 

reply via email to

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