Re: [PATCH] speed commands: error message when a key is not associated with a command

[Ihor Radchenko]

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Ihor Radchenko writes:
>
>> Note that speed commands are not only decided by
>> org-speed-command-activate. Any function in org-speed-command-hook can
>> trigger speed command. Throwing an error in org-speed-command-activate
>> can potentially shadow other functions in the hook.
>
> Ah, I see... I had not taken into account what you mention.
>
> But, if I have understood correctly how this hook works, each associated
> function has its "independence", right? I mean, if I have
> org-speed-command-activate and org-babel-speed-command-activate
> associated to this hook, and I bind the "K" key to an action in
> org-babel-key-bindings, but that key does not is associated with any
> action in org-speed-commands, then the error message would only be
> displayed in the proper context, that is, if I hit K at the beginning of
> the headline or any location defined for org-use-speed-commands.

You are mostly correct, with one potential caveat.
Consider a user who wants to define extra speed command that should run
at the beginning of level 1 headlines. This context also matches the
context of org-babel-speed-command-activate and your proposed patch will
make it harder for the user to achieve the described behaviour.

On the other hand, the user could simply add to front of the
org-speed-command-hook given that blocking behaviour of
org-babel-speed-command-activate is well-documented.

> Another possibility I can think of is, instead of returning an error
> message: just do nothing when a wrong key is pressed. Something, maybe,
> like this (I suppose that the same should be done in each function added
> to the hook):

This would not solve the problem of shadowing.
It may be better idea to provide a custom variable controlling
org-babel-speed-command-activate: do nothing or throw an error.
This custom variable should also be described in the docstring of
org-speed-command-hook to warn about potential shadowing.

To summarise, your idea will be reasonable if:
1. The new behaviour can be customized
2. The new behaviour is documented in org-speed-command-hook

Best,
Ihor