[RFC] mp.input: allow clients to override console.lua script-opts

[CogentRedTester]

Currently, all input requests are styled the same no matter the source of the request. Users can change style settings using script-opts, but these changes will still apply to requests from all clients. The problem with this approach, is that not all scripts request the same kind of input, so not all will necessarily benefit from the same kind of styling, and some scripts which draw their own UI elements may want console.lua styling to better match their own.

This commit allows a table of script-opt overrides to be passed to mp.input.get() and mp.input.select() under the console_opts key, which console.lua will use instead of the its own. To minimise required changes, metatables are used to allow console.lua to seamlessly fall back on the original script-opts if the client does not provide an override. I have also required that incoming opts have the same type as the existing script-opts, which should prevent any crashes caused by mismatched types.

From looking through the code, I don't believe there are any stateful or cached values based on opts that need to be specially updated, the opts appear to be re-queried any time the console is rendered or a keybind is pressed and any crashes/bugs that might be caused by invalid inputs of the right type would presumably also happen if the user sets script-opts normally. However, I would appreciate a second opinion from someone familiar with console.lua.

[guidocella]

Ref. #16138

I'm not sure if it's desirable to override the user preferences like the font size though?

[CogentRedTester]

I'm not sure if it's desirable to override the user preferences like the font size though?

There are definitely some preferences that are less useful to override, but with the metatable implementation, it would require more code to support a limited subset than to support them all. Or are you referring to the fact that some options may have accessibility reasons for users to override? I can see that argument, but I don't think the solution is to ban changes to some options as some scripts may have legitimate reasons to change them. I would prefer instead to encourage those scripts to expose their own script-opts to change their own defaults.

It would not be difficult to add a (non-overridable) script-opt that allows users to provide a list of script opts that cannot be shadowed, but I'm not convinced its worth the extra complexity.

Ref. #16138

Regarding the solution in the linked issue, overriding script-opts manually in the opened and closed callbacks is an option, but the original styling is still drawn for a fraction of a second initially, and extra care has to be taken to ensure there are no race conditions (the code they presented there could potentially wipe custom options set by other scripts). If this is a desirable feature, I think it makes more sense to do what this PR does.

[guidocella]

Yeah scripts can expose their own script-opts.

That issue made me wonder, is your use case to center the input? If so it's probably better to add a dedicated option. Centering totally breaks log and completions but it's fine if you don't use those, though it's not clear how wide the input line should be.

[CogentRedTester]

I hadn't considered centering actually, I was thinking more things like changing colours to match the colour scheme of the script, changing borders/padding/gaps based on how many select items a script expects to have, or changing exact_match/case_sensitive/history_dedup depending on the context of the input request.

Edit: and of course border/background/font-size styling to make the input request look visually like the other elements a script is drawing on the screen

[guidocella]

Yeah that's fair. We can actually use this in select.lua to make history search exact by default.

I would suggest not mentioning REPL since that's just a leftover of the original name of the script. I removed most references in 9551de6 but apparently I missed my own at the start of the mp.input docs (you can remove that too if you want).

Since we have several -override options maybe this can be named script_opt_overrides? Which also makes it clear that not specified script-opts are untouched.