Re: Smarter M-x that filters on major-mode

[Lars Ingebrigtsen <larsi@gnus.org>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Would extending the object (and stash it in the seventh slot) make
> sense?  It'd make the bytecode massively incompatible with previous
> versions, but it generally is pretty incompatible.

That was a rabbit hole I don't really want to go down --
`make-byte-code' has a

(make-byte-code ARGLIST BYTE-CODE CONSTANTS DEPTH &optional DOCSTRING
INTERACTIVE-SPEC &rest ELEMENTS)

signature, which makes it non-trivial to extend with another parameter,
especially with how it's called.

So instead I made INTERACTIVE-SPEC be a cons cell, where the first
element is the spec itself and the second is the modes list.

With that, I've now got a functioning Emacs, and I'm using
gnus-summary-mode as the test subject: `M-x gnusTAB' now gives me 200
fewer things to read through when issues in the Gnus group buffer.  :-)

I guess I could take this to a branch...  but...  the changes seem kinda
straighforward, so I'm not sure that's worth it, and by pushing directly
to the trunk, people can get started with
`C-M-% ^  (interactive RET   (command the-correct-mode RET'-ing as they
want, and then see `M-x TAB' grow progressively shorter each time...

Two things: 1) I'm slightly worried that this change will affect the native
branch (so I've added Andrea to the CCs), and 2) I'm not sure whether to
use `derived-mode-p' or not in the `M-x' default predicate:

(defun command-for-mode (symbol)
  "Say whether SYMBOL should be offered as a completion.
This is true if it's a command and the command modes match the current
major mode."
  (and (commandp symbol)
       (or (null (command-modes symbol))
           (member major-mode (command-modes symbol)))))

`derived-mode-p' would be more accurate, but is also kind of slow?
Hm...  pre-compute stuff?  Cache?  Hm...

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