Re: Current mode command discovery

[Stefan Monnier]

>>> It reminds me of the disabled-command-function machinery, or at least the
>>> concept. Maybe there's a decent way to leverage the two concepts into a
>>> similar UI pattern?
>
> Yes, that makes sense.  If we do add a "Really execute this command from
> this other mode?" thing, then being able to permanently disable the
> warning, like with disabled commands, would be nice.
>
>> Talking about integration with other pre-existing functionality: how
>> 'bout merging the new command enable functionality with the
>> `menu-enable` symbol property?
>
> That does seem natural, doesn't it?
>
> However, I'm not quite sure about the proposed usages for using
> completion-predicate for commands that are currently not usable.  In
> menus, the commands are still there -- they're just greyed out, so you
> can tell that if you just do something (mysterious), then they'll be
> enabled.
>
> In `M-x' completion, that's not really a natural...  thing?  (Unless
> using a display method that displays all completions, no matter what the
> predicate, but sort/display/colour them differently, as Eli suggested.)

I think that goes back to my point about defining what the
"completion-predicate" means.  I don't think it should mean "don't list
me in M-x" but something more like "doesn't make sense to use now in
this way".  Then the UI is free to decide to still show it but greyed
out, or to not show it at all, or to show it but "further down" or
something, and different UIs can make different choices.
[ BTW, maybe the predicate should take an extra arg indicating telling
whether we want to know if the command would be meaningful when run
from `M-x` or when run from a menu or when run from a key (in case we
want to "grey out" bindings in things like `<prefix> C-h`).  ]

It makes sense for M-x to "not list it at all" yet for the menu bar to
still show it (as greyed out) because the circumstances are different
(the fact that the entry is present in the menu is proof that the
command is sometimes relevant, just not currently).


        Stefan