Parametrizable smart macros: brainstorm for future specification

General
9

Couple of ideas:

A slightly modified suggestion from @maexxx in My thoughts as a new user (UHK80) - #30 by maexxx

In this case, macros would allow referencing custom strings.

[original by Max, edited by me] You would bind something like “Macro: send_windows_unicode” with “Macro parameter 1: 0 0 a 1” to a key. For different keys, it would always map to the same macro, but different hex code parameter. In the macro, you’d need to be able to do tapKeySeq CS-u $macroArg.1 enter.

This way tapKeySeq CS-u $macroArg.1 enter would be interpretted as tapKeySeq CS-u 0 0 a 1 enter.

  • Pros: simple to implement, simple to use, cheap to evaluate (probably), extremely powerful
  • Cons: imagine I use this approach to bind greek alphabet via alt codes. Now I have a keymap full of hex values with no way to identify them and no way to add any explanatory note to them.

My notes:

  • I am thinking about extending the argument with some kind of “type” information. This would allow attaching a label to any key (another popular feature), It would also allow us to have types like “Unicode char as hex key sequence”, for which Agent could take a unicode character (e.g., emoji), but would serialize it as the relevant key sequence (e.g., 0 0 a 1), thus allowing Agent to show it as an actual unicode char.

  • Does anyone have a strong opinion on correctness of the words “param” vs “arg” in these contexts? (I take them as interchangeable, but am not sure how correct that is)

I like this idea in this modified form, but am wondering if we can come up with some ways to improve it and get rid of the drawbacks of this solution.

Laszlo’s suggestion:

i envision a fixed number of typed macro arguments per macro, which would be described as one line per argument in the beginning of the macros. agent would parse this format to construct the gui for arguments, making their usage very user friendly

@arg keyId first
@arg string second
randomCommand @first
// rest of the macro
  • Pros: user friendliness
  • Cons:
    • it is not clear what the “type” should be referencing. I would like the solution to be more general than what a macro variable can contain, so this should not be the macro variable type.
    • named nature of the arguments adds an indirection layer, which translates to complexity of implementation as well as costly evaluation.
    • assume the user has already bound and parametrized many keys with such a macro. Now, what does happen / should happen when the user changes order, or types, or names of the variable declarations?

At the moment, I am not finding this feasible. Too complex on both Agent and firmware side, contains inconsistencies and unsolved scenarios. But I like some of its aspects, and so have posted it for inspiration.

Any opinions or new ideas?

1 Like