Limit what M-x TAB lists?

Limit what M-x TAB lists?

[Lars Ingebrigtsen]

Here's today's unrealistic idea: Wouldn't it be nice if `M-x fooTAB' was
more useful?

For instance, if I type `M-x vc-dTAB' in this buffer, I get the
following: 

Possible completions are:
vc-default-check-headers 	vc-default-mark-resolved
vc-default-revision-completion-table 	vc-delete-file
vc-diff 	vc-dir
vc-dir-delete-file 	vc-dir-find-file
vc-dir-find-file-other-window 	vc-dir-hide-state
vc-dir-hide-up-to-date 	vc-dir-ignore
vc-dir-isearch 	vc-dir-isearch-regexp
vc-dir-kill-dir-status-process 	vc-dir-kill-line
vc-dir-mark 	vc-dir-mark-all-files
vc-dir-menu 	vc-dir-mode
vc-dir-next-directory 	vc-dir-next-line
vc-dir-previous-directory 	vc-dir-previous-line
vc-dir-query-replace-regexp 	vc-dir-refresh
vc-dir-search 	vc-dir-show-fileentry
vc-dir-toggle-mark 	vc-dir-unmark
vc-dir-unmark-all-files 	vc-dir-unmark-file-up

Out of all this, I think there's two actual commands I can use here --
the rest are just commands bound to keystrokes in VC mode.

It would be really nice for discoverability if only those two applicable
commands were listed.

And it doesn't really seem unachievable.  There's oodles of ways of
achieving this that would require more or less work.

1) Just make M-x list ;;;###autoloaded functions.

That would require us adding those cookies to more functions, though.

2) New form like (command-interactive 'vc-mode "p")

This would say "this command is only valid in VC mode buffers", so it
would not be listed by M-x in other modes.  This would be pretty
flexible, but would be a lot of code churn.  But it wouldn't require a
global Armageddon date, but one could add this at leisure, and M-x would
gradually become nicer.

3) New form like (global-interactive "p")

Kinda like the opposite of 2), but here we mark commands as being
global.  It would be less churn, but be more Armageddon-ey.  Unless we
add cookies per file that says that "this file is now new-style".  Kinda
like

(pragma (local-interactive 'vc-mode))

at the start or something.

The added bonus of both 2) and 3) might be that commands would refuse to
run unless called in the right mode buffers.  Which might mean fewer bug
reports down the line.

There's a bunch of commands (like `quit-window') that apply to many
(special) modes, but we could figure something out for those, too...

(Oops.  I almost ran `M-x quit-window' in this buffer.  I wonder what
would have happened...)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Limit what M-x TAB lists?

[Stefan Monnier]

> Here's today's unrealistic idea: Wouldn't it be nice if `M-x fooTAB' was
> more useful?

Yes.  I rewrote M-x in Elisp, partly to try and make it easier for
people to try and tweak it.

> 2) New form like (command-interactive 'vc-mode "p")

More generally, move the "sanity checks" performed at the beginning of
some commands to a special place so they can be run without actually
calling the function.  IOW add a "callable" predicate alongside the
interactive-spec that M-x could then use to filter out
inapplicable commands.

Of course, this will require many changes in many packages before it
becomes really useful.

> 1) Just make M-x list ;;;###autoloaded functions.
> That would require us adding those cookies to more functions, though.

Not good enough.  Many commands are very useful via M-x but only after
loading a particular mode (those commands only make sense in that mode,
of course).

Maybe a related approach is to use a fancier analysis that tries to
figure out "would this command always be available in this context?" (as
opposed to being available because of some unrelated buffer having
caused some packages to be loaded).

Other ways we could try and improve M-x:
- Move to the beginning of the list, those commands that start with the
  same prefix as the current major mode.
- Move to the end of the list those commands that are accessible via
  a key-binding (and the shorter the key-binding, the further towards
  the end).


        Stefan

Re: Limit what M-x TAB lists?

[Lars Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> 2) New form like (command-interactive 'vc-mode "p")
>
> More generally, move the "sanity checks" performed at the beginning of
> some commands to a special place so they can be run without actually
> calling the function.  IOW add a "callable" predicate alongside the
> interactive-spec that M-x could then use to filter out
> inapplicable commands.

Hm, yes, that would be nice.  Then multi-mode commands like
`quit-window' could have a complex predicate that does the right thing,
while very mode-specific commands like `gnus-summary-catchup-to-here'
could have a simple (mode-only) predicate.

If these predicates become very complex, then `M-x fooTAB' would become
exceedingly slow, though...

> Of course, this will require many changes in many packages before it
> becomes really useful.

Yes, but modes could be converted gradually, and things would get better
and better as time passes...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Limit what M-x TAB lists?

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> If these predicates become very complex, then `M-x fooTAB' would become
> exceedingly slow, though...

Instead of a predicate for every function, the usual Emacs idiom of "if
it is a symbol, filter by mode, if it is a function, it must be a
predicate returning non-nil if the command is applicable blah blah...".
I'll bet that 99% of the commands fall in the "symbol" case, which is
fast.

>> Of course, this will require many changes in many packages before it
>> becomes really useful.
>
> Yes, but modes could be converted gradually, and things would get better
> and better as time passes...

I'm definitely interested on this idea. It is annoying (as in "Emacs
looks stupid and counterproductive") to always see useless candidates on
M-x. If you put the underlying machinery in place, I volunteer for the
command hunt.

It would be nice if the annotations were backwards compatible, so they
could be added to external packages without making them incompatible
with past Emacs releases.

Re: Limit what M-x TAB lists?

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Instead of a predicate for every function, the usual Emacs idiom of "if
> it is a symbol, filter by mode, if it is a function, it must be a
> predicate returning non-nil if the command is applicable blah blah...".
> I'll bet that 99% of the commands fall in the "symbol" case, which is
> fast.

Yup.  But perhaps the symbols we want to use here are really mode names?
And mode names are unfortunately also functions...  Hm...

> I'm definitely interested on this idea. It is annoying (as in "Emacs
> looks stupid and counterproductive") to always see useless candidates on
> M-x. If you put the underlying machinery in place, I volunteer for the
> command hunt.

Great!

> It would be nice if the annotations were backwards compatible, so they
> could be added to external packages without making them incompatible
> with past Emacs releases.

Well, if we go with new variations on `interactive', then external
packages could just do something like

(unless (fboundp 'command)
  (defmacro command (&rest args)
    `(interactive ,@(cdr args))))

and then

(defun vc-dir-mark ()
  (command 'vc-dir-mode "p")
  ...)

(defun quit-window ()
  (command (lambda () (..stuff..)) "p")
  ...)
  
Or something.  Would that work, or is `interactive' interpreted even
more specially?  (I.e., before macro expansion...)  Let's see...

(defun foo (arg)
  (command 'bar "p")
  (message "%s" arg))

Yup, seems to work.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Limit what M-x TAB lists?

[Stefan Monnier]

> (unless (fboundp 'command)
>   (defmacro command (&rest args)
>     `(interactive ,@(cdr args))))

I suspect it wouldn't work.

But AFAICT

  (interactive "p" :pred blabla)

is treated by all Emacsen (haven't checked XEmacs) identically to

  (interactive "p")

except for a compile-time warning about the extraneous stuff.


        Stefan

Re: Limit what M-x TAB lists?

[Lars Ingebrigtsen]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> (unless (fboundp 'command)
>>   (defmacro command (&rest args)
>>     `(interactive ,@(cdr args))))
>
> I suspect it wouldn't work.

It seemed to work for me.  I put the following in an .el file:

(unless (fboundp 'command)
  (defmacro command (&rest args)
    `(interactive ,@(cdr args))))

(defun foo (arg)
  (command 'bar "p")
  (message "%s" arg))

and byte-compiled it and loaded it in a new Emacs.  `C-u 4 M-x foo' said
"4"...  But perhaps there are other subtle things that don't work?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Limit what M-x TAB lists?

[Lars Ingebrigtsen]

Here's another tweak:

We have (interactive) specs like before, and all those are listed in
M-x.  We add a new (command) spec, and those should be used only for
commands used in modes, like previously discussed.

Here's the tweak: Instead of adding a predicate, we just use the same
syntax as `interactive', i.e., (command "p") or whatever.  `M-x TAB'
will then list all `interactive' functions, plus all `command' functions
that are reachable in current keymaps.  So if we're in a vc-dir-mode
buffer, `M-x vc-dTAB' will list `vc-dir-mark', but otherwise not.

This has the advantage that 1) it's probably easier to implement, and 2)
commands that are available via text-property/overlay keymaps, as well
as minor modes, all do the right thing without any special handling.

And commands like `quit-window' would also "just work", even though it
"belongs" in a lot of different modes.

This is a 97% solution -- I think it almost gets us to where we want to
be.  But there are a handful of commands that are deliberately left out
of keymaps, but may still only be called in certain modes.  For these,
we could have another form that does include the previously discussed
predicate. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Limit what M-x TAB lists?

[Ted Zlatanov]

On Fri, 27 Dec 2013 02:41:58 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> `M-x TAB' will then list all `interactive' functions, plus all
LI> `command' functions that are reachable in current keymaps.  So if
LI> we're in a vc-dir-mode buffer, `M-x vc-dTAB' will list
LI> `vc-dir-mark', but otherwise not.

I like it.  I would sort them separately and put the group of commands
first, so it's two separate groups, not one group sorted by priority.

Ted

Re: Limit what M-x TAB lists?

[Davis Herring]

> It seemed to work for me.  I put the following in an .el file:
> 
> (unless (fboundp 'command)
>   (defmacro command (&rest args)
>     `(interactive ,@(cdr args))))
> 
> (defun foo (arg)
>   (command 'bar "p")
>   (message "%s" arg))
> 
> and byte-compiled it and loaded it in a new Emacs.  `C-u 4 M-x foo' said
> "4"...  But perhaps there are other subtle things that don't work?

It works _only_ when byte-compiled.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Limit what M-x TAB lists?

[Lars Ingebrigtsen]

Davis Herring <herring@lanl.gov> writes:

>> It seemed to work for me.  I put the following in an .el file:
>> 
>> (unless (fboundp 'command)
>>   (defmacro command (&rest args)
>>     `(interactive ,@(cdr args))))
>> 
>> (defun foo (arg)
>>   (command 'bar "p")
>>   (message "%s" arg))
>> 
>> and byte-compiled it and loaded it in a new Emacs.  `C-u 4 M-x foo' said
>> "4"...  But perhaps there are other subtle things that don't work?
>
> It works _only_ when byte-compiled.

I did the same with an un-compiled /tmp/foo.el, and it worked the same.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Limit what M-x TAB lists?

[Tom]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> 
> Here's today's unrealistic idea: Wouldn't it be nice if `M-x fooTAB' was
> more useful?
> 

An alternative approach can be changing the order of items. The more
frequently a command is used the higher it would be listed, so your
most frequently used commands would float to the top of the completion
list and you'd find them easier.

Re: Limit what M-x TAB lists?

[Nix]

On 26 Dec 2013, Tom said this:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Here's today's unrealistic idea: Wouldn't it be nice if `M-x fooTAB' was
>> more useful?
>
> An alternative approach can be changing the order of items. The more
> frequently a command is used the higher it would be listed, so your
> most frequently used commands would float to the top of the completion
> list and you'd find them easier.

FWIW, Icicles can do this (it also fontifies commands you've used at all
differently from those you have not).

(Icicles is so different from normal completion that I'm not even sure I
should be mentioning it. But still.)

-- 
NULL && (void)

RE: Limit what M-x TAB lists?

[Drew Adams]

> > An alternative approach can be changing the order of items.
> > The more frequently a command is used the higher it would be
> > listed, so your most frequently used commands would float to
> > the top of the completion list and you'd find them easier.
> 
> FWIW, Icicles can do this (it also fontifies commands you've
> used at all differently from those you have not).
> 
> (Icicles is so different from normal completion that I'm not
> even sure I should be mentioning it. But still.)

Why not mention Icicles?  It shouldn't be hard to do things in
vanilla Emacs that are similar to Icicles features.  Where
there's a will there's a way.

(And FWIW, Icicles completion is less different from "normal"
completion than is, say, Ido completion.  Icicles completion
is pretty much a superset of "normal" completion.  Unlike Ido,
it uses the minibuffer and *Completions* "normally".  If you
don't hit extra keys then the behavior you get is pretty
"normal".)

First, a comment on the above suggestion that Nix replied to:
IMO, systematically floating more recent inputs to the start
of a completion list would take control away from the user,
unless it it is easy to turn off that behavior (e.g., while
completing).

What Nix says about Icicles is correct.  But the following
info might not be obvious, and it might help in this context.
Items 1-7 are about sorting; 8-9 are about minibuffer
histories.  All of what is said here applies to all kinds of
completion, not just command completion (`M-x').

1. Users control the sort order, and can change it on the fly
at any time.  Likewise, reversing the current sort order.

2. Some sort orders are available as choices for all types of
completion.  Others are specific to particular completion
types (e.g. file-name completion) or even to particular
commands.  It is easy for a command to make use of a given
set of sort orders.

3. You can choose a different sort order (or no sorting) by
cycling among orders or by matching their names using
completion.  You use `C-,' to do this.

Cycling is quick when there are not many orders to choose
from.  Completion can make sense otherwise, and when there
are some orders you do not want to enable.  (Some orders are
more costly in time - they are called out in the doc.)

A user option defines a threshold, at or below which cycling
of sort orders is used by default and above which completion
is used by default.  The default threshold is 7 sort-order
candidates.  A prefix arg flips the behavior: if `C-,' would
currently cycle then it completes instead, and vice versa.

5. In addition to choosing another sort order, you can toggle
between the current sort order and the current alternative
sort order - a quick way to flip between two orders.

You can choose different alternative sort orders in the same
ways you choose the current sort order: cycling or completion.
By default, the alternative sort order puts previously used
inputs first, sorting those candidates and the others
alphabetically.

6. You can easily define additional sort orders or remove
existing sort orders from the base set.

7. You can even combine existing sort orders interactively,
melding them together in various ways.

8. You can toggle the highlighting that Nix mentioned for
previous inputs, anytime from the minibuffer.

9. There are two ways to limit completion candidates to those
that have been input previously:

    * `M-pause' resticts the currently matching candidates to
      ones that have been entered before.
    * `M-h' matches minibuffer content against previous inputs.

More info:

* http://www.emacswiki.org/emacs/Icicles_-_Sorting_Candidates
* http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements

Limit what M-x TAB lists?

[Stephen J. Turnbull]

Lars Ingebrigtsen writes:
 > Here's today's unrealistic idea: Wouldn't it be nice if `M-x fooTAB' was
 > more useful?
 > 
 > For instance, if I type `M-x vc-dTAB' in this buffer, I get the
 > following: 
 > 
 > Possible completions are:
 > vc-default-check-headers 	vc-default-mark-resolved
 > vc-default-revision-completion-table 	vc-delete-file
 > vc-diff 	vc-dir
 > vc-dir-delete-file 	vc-dir-find-file
 > vc-dir-find-file-other-window 	vc-dir-hide-state
 > vc-dir-hide-up-to-date 	vc-dir-ignore
 > vc-dir-isearch 	vc-dir-isearch-regexp
 > vc-dir-kill-dir-status-process 	vc-dir-kill-line
 > vc-dir-mark 	vc-dir-mark-all-files
 > vc-dir-menu 	vc-dir-mode
 > vc-dir-next-directory 	vc-dir-next-line
 > vc-dir-previous-directory 	vc-dir-previous-line
 > vc-dir-query-replace-regexp 	vc-dir-refresh
 > vc-dir-search 	vc-dir-show-fileentry
 > vc-dir-toggle-mark 	vc-dir-unmark
 > vc-dir-unmark-all-files 	vc-dir-unmark-file-up

vc-default-...
vc-delete-file
vc-diff
vc-dir
vc-dir-...

is simple to compute algorithmically (string processing).  It doesn't
do what you want, obviously, but it sure reduces the visual clutter.

Another algorithmic approach would be to mark each symbol defined in a
keymap with the property 'completion-keymap and the keymap (list of
keymaps).  If none of the keymaps in which a symbol is defined are
currently active, filter the symbol out.  Heck, maybe the property is
a premature optimization; perhaps which keymaps bind the function and
whether they are active can be done sufficiently quickly.