Re: Current mode command discovery

[Dmitry Gutov <dgutov@yandex.ru>]

On 17.02.2021 13:30, Lars Ingebrigtsen wrote:
> Note: THIS IS NOT A DISCUSSION ABOUT M-X.
> 
> Óscar Fuentes <ofv@wanadoo.es> writes:
> 
>> That would be very interesting, but AFAIU with the current
>> implementation it has some problems.
>>
>> It would miss some candidates which belong to the current mode although
>> they are not marked as mode-specific because they are also applicable to
>> other contexts. This would be confusing for the user.
>>
>> So we need a mechanism for saying `foo-bar-command' belongs to
>> `foo-mode', but it is not specific of that mode.
> 
> Yes, that's a problem.
> 
> Hm...  there's two obvious sources if information about what commands
> "belong" to a mode: There's the key bindings, and then there's the new
> mode tagging.  We could perhaps use both in this new command?  I.e., if
> somebody has gone to the trouble to add a command to the keymap of the
> mode, then it's probably pretty useful for that mode?

If someone annotated a command with applicability conditions, we should 
probably combine them with 'or' (like if it has both (declare (modes 
...)) and (declare (completion ...))). Having a command belong to a 
keymap could be a new implicit applicability condition.

> A more serious problem that this brings up is the problem with
> non-mode-specific predicates: They don't convey any information about
> why the predicate is t/nil.  Say you have
> 
> (defun foo-spiffy-command ()
>    (declare (predicate my-clever-predicate-p))
>    (interactive))
> 
> When listing mode-specific commands, and this predicate returns t,
> should it be included?  Yes?  No?  There's no way of saying, really...
> 
> So: Tagging by mode conveys more information to the system than just
> having predicates, and we can use that.  This also means that
> 
>    (declare (modes ...))
> 
> should be implemented differently than it is today (which is just
> slapping a predicate onto the symbol-plist).

Moving the checking logic inside the read-extended-command-predicate 
implementation seems logical. (declare (modes ...)) would just add a tag 
to the command, with natural possibility to add other tags, which a 
different read-extended-command-predicate could use.