RE: Ordering of command completions

[Drew Adams <drew.adams@oracle.com>]

> I use Ido+flx. Yes, as you type the number of candidates quickly
> decrease from thousands to dozens, but my experience is that the
> vast majority of candidates are not applicable on the current
> context and they force you to type quite a bit more.

I don't disagree wrt "applicable on the current context", but
I'm wary as to what someone might think that should mean.

I don't think Emacs should be overly ambitious here in excluding
commands.  It should instead exclude only commands that it is
absolutely sure no user would be able to use in the current
context.  What "context" means here is probably the real question.

> Then we have non-predictability. You enable a mode through an
> autoloaded function and suddenly, for the rest of the Emacs
> session, `M-x foo' no longer resolves to the same list of
> candidates where it used to.

You see?  Now that's an example of what I meant by the meaning
of "context" being important.

To me, if you have loaded a library that defines commands that
you can invoke currently (which, a priori is the case for most
commands), then I *want* `M-x' to include those commands when
my input matches their names.

If I load a library (or it is autoloaded) then I expect to be
able to invoke its commands using `M-x'.  I certainly hope
that feature is not removed in favor of some "predictability".

I am becoming more wary of the proposed change...

> > Certainly any command that is bound to a key sequence that
> > is available in the current context should be a candidate.
> > (That's a minimum.)
> 
> IMHO introducing ad-hoc heuristics for *discarding* candidates
> is very risky.

That was my point.  Emacs needs to be very sure that it makes
no sense for a given command to be invoked currently using
`M-x', before it thinks about excluding that command.

A priori, there are very few commands that can reasonably
be excluded, with that in mind.  And in that case, little
is gained, in terms of reducing the supposed "noise".

And something is lost: the user does not see those commands.
S?he may well become confused, and think that this or that
command has not been defined or is no longer supported or...

> OTOH, if it is a matter of sorting the candidates, which is
> what the OP suggested, it is fine.

I see.  I misunderstood.  I asked whether by "noise" what
was meant was a large number of candidates.  I guess the
answer is no.  It is apparently the position of inappropriate
candidates high in the sort order that constitutes "noise",
and not their mere presence.

In that case I have a different objection.  The sorting
being used should be *very clear to users*.  And in
general it should not combine very different criteria,
such as (1) appropriateness (one form of which is what
this proposed feature is about, I guess) and, say,
(2) how recently candidates were used (or some other
sorting criterion, such as alphabetic comparison).

If sorting combines such different criteria then it can
be confusing to users.  This is all the more nefarious if
a measure of "inappropriateness" is applied unbeknownst
to the user.

Picking the right candidates to sort lower according to
the context can be tricky, and once they are sent to the
end of the list a user might well wonder what's going on.

I come back, I think, to what I said in the beginning:
"the answer (IMHO) is better completion behavior."