Currently the input.key command only accepts one single key argument in the format of the uinput code from the linux kernel. It's pretty awkward and I think could be a lot more useful
It would be good to:
Let people use actual characters instead of key codes, like key:a instead of key:123, and have human readable aliases for special keys like {space} and {enter}
Allow multiple keys in a single input.key command, like **key:asdf to input all 4 keys in sequence
Maybe it could go even further than this, and a simple macro language could be created that also includes stuff like shorthand for pressing the same key multiple times a[10] and delays
Some thoughts about implementation:
The new implementation should still support the original one with a single uinput key code
Should the keys be delimited? eg. a,s,d,f instead of asdf. Not as nice to write and more storage taken, but I'm sure easier to parse and simple to maintain backward compatibility with old implementation
If the "macro language" is implemented, it will need some planning around what special characters to use, escaping etc.
It's also occurred to me that this is technically an arbitrary code execution vulnerability. Do we want to close that up? Probably simple as not allowing switch to console if the menu core is open (unless allow_commands is enabled)
Currently the input.key command only accepts one single key argument in the format of the uinput code from the linux kernel. It's pretty awkward and I think could be a lot more useful
It would be good to:
Maybe it could go even further than this, and a simple macro language could be created that also includes stuff like shorthand for pressing the same key multiple times a[10] and delays
Some thoughts about implementation:
It's also occurred to me that this is technically an arbitrary code execution vulnerability. Do we want to close that up? Probably simple as not allowing switch to console if the menu core is open (unless allow_commands is enabled)