Re: Current mode command discovery

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> writes:

> With the short list presented by `M-S-x', it does seem more important
> that the commands that show up are highly relevant.  In `list-bookmark',
> I see some stuff in the completion list that I wonder about:
>
> - `digit-argument'.  Should it be in `M-x', or is it more like
>   `mwheel-scroll'?  Should it be in `M-S-x'?
>
> - `negative-argument', I can see why one would keep it in `M-x', I
>   guess, but in `M-S-x'?

Yes, these don't seem useful to list, and they'll appear in all the
modes...  however, perhaps they should have a `ignore' completion
predicate.  That is,

`M-x digit-argument'

never seems to actually do anything?  Are there cases where doing that
would do anything useful?

> - Finally, `forward-button' and `backward-button'.  But I can't find who
>   binds it?  In any case, it doesn't seem relevant to this mode.
>   I guess it should be the responsibility of the mode to unbind any such
>   commands.

It's from this:

(defvar tabulated-list-mode-map
  (let ((map (make-sparse-keymap)))
    (set-keymap-parent map (make-composed-keymap
                            button-buffer-map
                            special-mode-map))

I don't know the logic behind binding the button commands in all
tabulated list modes -- do tabulated lists usually have buttons in them?
Sounds pretty odd...

>> `ignore' shows up here, because we've bound `h' to `ignore' as a way to
>> disable that key binding.  That doesn't sound kinda non-ideal -- it
>> should be unbound instead.
>
> True.  But it would be good to find a general solution (third-party
> developers will use it even if we fix eww).

Actually, I had bound `h' to `ignore' here locally, because I was always
hitting `h' in eww buffers.  :-) 

> One idea is to a special list of commands that `M-S-x' specifically
> always ignores (and add `ignore' to it).

Since it's never useful to `M-x ignore', adding completion predicate to
it would probably be fine.

> Naming is hard... here are some ideas (none of them very good):
>
> - execute-extended-command-here
> - execute-extended-command-narrow
> - execute-extended-command-mode
> - execute-extended-command-local

Hm...  those doesn't seem all that much more logical.

> (BTW, why is `execute-extended-command' not just `execute-command'?
> I'm not suggesting that we change it, it just seems like a strange choice.)

I don't know, but perhaps we don't have to keep the
"execute-extended-command" bit in this new command?  So we could go for
a different name like...  `execute-relevant-command'...

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