Nested macros don't work as advertised about kaleidoscope-macrosonthefly

[cdisselkoen]

I've determined that the issue here is that we store macro keystrokes as the mapped key, rather than the "physical key" ((row, col) coordinate). Conversely, we select macro slots based on physical key rather than mapped key. When playing back a macro that contains a MACROPLAY keypress, the following keypress (which is supposed to select a playback slot) is injected with UNKNOWN_KEYSWITCH_LOCATION, and the macro-playback code can't determine which slot should be played.

We have perhaps three options here. There is a relevant philosophical question: when the user records a macro, do they intend to record a series of mapped keypresses, or a series of physical keypresses? If the former, a user who records a macro having the effect (at the time) of, say, "space c tab esc" intends that playing back that macro will always have the effect "space c tab esc" regardless of what those physical keys do or don't do at that later time. If the latter, the user intends that the physical key sequence is recorded, and that playing back that macro is always literally equivalent to playing back that same sequence of physical keypresses. If the keys' effects have changed (due to what layer is active, due to a macro being re-recorded, or anything else), the macro should change too.

1. We could leave things as-is. This would leave all current behaviors intact - specifically, macros play back mapped keypresses, and nested macros do not work. Nested macros would simply not be something we support. We could still "fail intelligently" i.e. just ignore the MACROPLAY and the slot-selection keypress during macro playback (or even not record them in the first place).
2. We could record physical keypresses instead of mapped ones. Nested macros would work as expected. Macros would play back physical keypress sequences. Recording a (row, col) coordinate takes exactly the same amount of space as a mapped key, so it doesn't matter from that perspective. This option does depend on keyboardio/Kaleidoscope#205.
3. We could identify macro slots by mapped key instead of physical key. This wasn't possible until recently, simply because of the sheer number of possible mapped keys (previously, we statically allocated at least a header for every possible macro slot) - but now, I think it should be possible. Nested macros would work as expected, and macros would play back mapped keypresses. A question arises whether we could still use all kinds of keys (even e.g. momentary-layer-switch keys) as macro slots, but I think we could. A more philosophical point, is that with this option, if the user has two keys that map the same (say, two Enter keys, or two Keymap1_Momentary keys as in the default Model 01 firmware, those would now also identify the same macro slot, whereas currently they are separate slots. I'm not sure what is desirable/intuitive here.

Options 2 and 3 seem best to me, but it's unclear to me at the moment which is better or results in the more intuitive behavior for end users.

[algernon]

There are a few issues with the second solution that I can see:

• What happens if the user changes their layout between recording the macro, and trying to use it (for example, by using EEPROM-Keymap & Focus)? In this case, the macro will not map to the same keys anymore.
• Similarly, if a macro is recorded with only the base layer active, playing it back with another layer active (if that is possible, and I think it should be) could also have keys map to different codes than when they were recorded.

The second case is much more likely than the first, likely enough to seriously think about whether recording locations only is sufficient. With the above two scenarios in mind, I think that recording mapped keys is the safest option.

[cdisselkoen]

Yes, that would be the case with the second option. It's a question of whether it's a feature or bug that the macro changes if the underlying keymap or layer changes. Clearly you think it's a bug, and on further thought, I'm inclined to agree; I think recording mapped keys is the more intuitive behavior for most users.

The question remains whether identifying macro slots by mapped keys or by physical locations is better. (I.e. option 1 or 3 above.) Most of the time, I suppose it won't make much difference. One of the most visible consequences of using mapped keys would be that if the user has two keys that map the same (say, two Enter keys, or two Keymap1_Momentary keys as in the default Model 01 firmware), those would now also identify the same macro slot, whereas currently they are separate slots.

I think identifying macro slots by mapped keys is probably acceptable? even if it slightly reduces the number of available slots. Plus, we can support nested macros with option 3 but not with option 1.