[Top][All Lists]

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

RE: Leaving out non-applicable commands on Mx

From: Drew Adams
Subject: RE: Leaving out non-applicable commands on Mx
Date: Sat, 9 Jan 2016 11:27:47 -0800 (PST)

> > And that's also a feature of some "advanced completion
> > systems".  But it should not (except by user option) be
> > the default behavior. The default behavior should be all
> > candidates matching the input patterns and the completion
> > predicate - no other "helpful" filtering unless requested
> > by the user.
> Emacs already contains a feature that filters out many defined
> functions from M-x. It’s called (interactive). Functions that are not
> declared interactive are not offered as completion candidates, and in
> fact cannot be executed with M-x.

You are repeating what I said.  I said that it already filters
using the predicate appropriate for `M-x' (which is `commandp').

(And in the text you responded to I explicitly said "and the
completion predicate" - which for `M-x' is `commandp'.)

> This proposal takes (interactive) to a new level, by allowing authors
> to specify conditions under which a function should be considered
> interactive.

Authors can already do that for any command they author that
reads command names using completion.  They can restrict the
candidate commands to any set they like, using an appropriate

That's different from saying that `M-x' should restrict
candidates to only commands that an Emacs developer has
decided, a priori, are the only ones appropriate for the
current context (e.g. mode, buffer, visibility spec, phase
of moon, ... whatever).

The predicate appropriate for `M-x', which can be used in
various ways by users and in many different contexts, is

But nothing prevents an author from defining a different
command name-reading command that uses a different predicate.

And nothing prevents an author from defining a minibuffer
key that filters `M-x' candidates further (letting the user
decide whether to narrow choices that way).

And nothing prevents an author from binding
`minibuffer-completion-predicate' to a predicate of choice.
Or of binding a completion key (even `TAB') to a command
like `minibuffer-complete' but that uses a different
predicate or that binds `minibuffer-completion-predicate'.

There are all kinds of ways for an author to impose a
different set of command-name completion candidates.

reply via email to

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