[rfc] How should scripts providing their own key bindings be handled?

[ghost]

Lua scripts might want to provide new key bindings for functionality they add. What should be done if these conflict with the user's bindings?

Currently, we try to be clever. Scripts can add key bindings with mp.add_key_binding("key", "name", callback). (This will map the named key to a Lua callback.) If the user has the key already mapped in his input.conf, the user's binding is mapped. The idea is that a script won't just override the user's bindings, similar as if a new mpv default key binding had been added.

The user can remap a scripts key by binding a key to a command sending the script a message:

KEY script_message lua/scriptname name

Where name is the second parameter passed to mp.add_key_binding. But maybe this is too roundabout and complicated.

Further, the user probably has no idea that his own bindings are overriding the script's, and will probably wonder why the script apparently isn't working. On the other hand, if the default were to override the user's binding, the user obviously can't rebind the keys. Or the script would have to provide its own complicated mechanism to customize key bindings.

A script can also override a user's binding with mp.add_forced_key_binding. This is mostly intended for situations when the script wants exclusive input in temporary situations (like capturing mouse events when the OSC is visible). But this will probably lead to chaos when some script authors use add_forced_key_binding for normal bindings.

With the OSC, there's a further complication: the OSC binds the mouse_move pseudo-key to show the OSC when the mouse is moved. Now if the user bound the mouse_move pseudo-key to ignore for whatever reason, this will practically disable the OSC, because the user's binding takes priority. (And this actually happens; see near the bottom of issue #597.)

So, does anyone have a good idea how this should be handled? Or am I overthinking this?

[ChrisK2]

A script should never randomly override any keybindings. I suggest that a script will just provide additional input commands, which the user then has to bind to a key on his own.

Edit: This will make new scripts a bit harder to use, but I guess that's still better than when a user has to figure out why (some) of his keybindings are suddenly not doing anymore what they used to.

[ghost]

I suggest that a script will just provide additional input commands, which the user then has to bind to a key on his own.

Currently they do. See that business about script_message. I could probably remove the script name from it to make it less convoluted, but adding "top level" commands won't work. (For one, when reading the user's input.conf, the scripts aren't even loaded yet, and the input.conf parser would print errors about unknown commands.)

[ghost]

Well, apparently nobody has an idea, so I'm closing this.

I'll probably have to think of something myself.

[weedy]

Spit out a notice to OSD for probably 2 times osd-duration.

lua script $HOME/.mpv/lua/X conflicts with bindings in $HOME/.mpv/X (probably input.conf)
Ignoring lua bindings

[ghost]

Good idea, but with the current scheme, shadowing other keys could be both wanted or unwanted.

Surely you don't want message spam if you intentionally remapped some keys.

[weedy]

At which point I would edit my bindings or the lua script.
You would never ship Lua scripts that conflict with default bindings.
Lua script authors should try and do the same.

[kevmitch]

You would never ship Lua scripts that conflict with default bindings.

We already do. in TOOLS/lua/cycle-deinterlace-pullup.lua

The reasoning being that this "enhances" the existing keybinding.