Key repeat for macro

[soraxas]

Does it make sense to enable certain macro key to inherent the key-repat features from typical keyboard/OS?

For example, following vim convention, I have e maps to C-right and w maps to macro of tapKeySeq C-right right. (in some vim-like keymap that I had setup)

The e works creat and it repeats while holding. The w, on the other hand, will only executes once (which makes perfect sense!! esp. given with what macro can do).

Perhaps having some setting in agent that can enable key-repeat feature per macro would be nice (key-repeating would only happen if the same macro is not already running).

[kareltucek]

What exactly is the question?

I don't think Laszlo will be enthusiastic about making such feature part of agent and the core engine (i.e., of regular actions, part of the binary serialization format, etc).

Regarding me, I don't want to make this firmware dependent on custom Agent - because it would bring great deal trouble for both me and for users.

On the other hand, if you are asking if I am willing to merge a macro command which will make this possible, then yes, it makes sense to me. (Something like autorepeat tapKey space, which would block for as long as the key is held. I think I am also fine with giving it 2 bits in macro-scope of the state if you want to make it work with backward jumps.)

[kareltucek]

(I am not a huge fan of configuring it somehow globally as a property of a macro, because such setting would be less "transparent" and harder to find. I thing keeping this feature inside of the macro language is ideal.)

[soraxas]

I see, your proposal sounds like a good idea and I will look into it.

It's interesting how you've mentioned the memory constraints in the other issue, and indeed we should try to constrain our memory layout. I am not too familiar with embedded programming, but would there be a smarter way to "only pay for what you use" within the macro (to reduce the overall memory layout)?

For example, we currently keep track of currentIfShortcutConditionPassed, currentIfSecondaryConditionPassed, and potentially autorepeat state in all macro state, regardless of whether the macro is using ifShortcut, ifSecondary, autorepeat etc.

Every additional feature increases the memory layout by 255x (max macro num), even though maybe only a few macros uses these features and need to keep track of these states.

---

Proposal: Could we only allocate memory when any of these tokens are first encountered in the macro, such that we dynamically increases that macro's memory usage only when it's necessary (i.e. only when those actions appear in the macro)?

We can then free them after the macro finishes. If no memory is available, we will then throw an error and ignore the macro request.

A potential downside is that running malloc on key-press might slow down the response time. And whenever there is dynamic memory allocation in programs, there are potential memory leaks. And I'm not sure if embedded device even uses malloc for these use-cases

[kareltucek]

Every additional feature increases the memory layout by 255x (max macro num), even though maybe only a few macros uses these features and need to keep track of these states.

This holds only for macro metadata (i.e., things in macro_reference_t). Macro engine has its own state pool, which features something like 16 states. (This way, a single macro can also have multiple running instances.)

but would there be a smarter way to "only pay for what you use" within the macro (to reduce the overall memory layout)?

There are some things to notice:

• the : 1 behind bools - it actually makes the compiler save them into a bitmap

• things in the structs are sorted by size - this reduces padding inserted by compiler, while not voiding memory alignment for bigger types.

• the union in action-scope part of the state - it shares the underlying memory, so as long as you need to keep state only across single action, memory is not that big deal.

---

Proposal: Could we only allocate memory when any of these tokens are first encountered in the macro, such that we dynamically increases that macro's memory usage only when it's necessary (i.e. only when those actions appear in the macro)?

Which tokens do you mean? If we are still talking about currentIfShortcutConditionPassed etc flags, then just keeping information about "having this and that stashed elsewhere" would be much more costly than current state of affairs.

If we are talking the string token parsing, I believe there is no need to actually copy the strings.

A potential downside is that running malloc on key-press might slow down the response time. And whenever there is dynamic memory allocation in programs, there are potential memory leaks. And I'm not sure if embedded device even uses malloc for these use-cases

I am not aware of malloc being used in UHK firmware at all, and am not sure if it is actually desired. Static allocation has some benefits:

• it guarantees that all features will be available.
• it is deterministic
• allows you to pack things in memory very tightly

Downsides of dynamic allocation:

• nondeterminism
• you never know when you will run out
• requirement on being able to allocate chunks of different sizes brings nontrivial overhead and neccesity to deal with actual memory layout of the heap.

---

Generally, we still have enough memory reserve to use when there is a good reason to do so, just not enough for the standard I-have-an-infinite-heap-and-don't-fear-to-use-it programming style.