Hitting auxiliary descriptor limit again

[lobre]

A few months back, I reported an issue that led to the increase of the auxiliary descriptor limit.

4101a4b

However, I see today that I am hitting that limit again. I don’t know if it is my configuration which is too complex for keyd's purpose, or if I implemented things in a complex manner.

I think it can mainly be due to two things:

• I like having two behaviours for a key, one on tap and another on hold. This requires remapping pretty much the whole keyboard for layers on which I want to do it.
• And linked to the previous one, I use the pattern of overloadi with timeout a lot, so that I can repeat keys without triggering the "hold" effect.

So this leads to things like:

q = overloadi(q, timeout(q, 250, S-q), 100)
w = overloadi(w, timeout(w, 250, S-w), 100)
e = overloadi(e, timeout(e, 250, S-e), 100)
r = overloadi(r, timeout(r, 250, S-r), 100)
t = overloadi(t, timeout(t, 250, S-t), 100)
y = overloadi(y, timeout(y, 250, S-y), 100)
u = overloadi(u, timeout(u, 250, S-u), 100)
i = overloadi(i, timeout(i, 250, S-i), 100)
o = overloadi(o, timeout(o, 250, S-o), 100)
p = overloadi(p, timeout(p, 250, S-p), 100)

Would that be an option to increase the limit to 512, or are there other mitigation strategies that I can follow?

I can share more of my configuration if needed.

[lobre]

I also realize that I like having different areas of the same layer doing various things. For instance, my last idea was to have space as a navigation layer. On that layer, I have a mix of keys that will trigger super and other alt. On that occasion, I cannot simply use a global modifier, and I need to redefine also the full layer manually to apply the effect for each key.

I don’t know if keyd will be able to improve those situations in the future. I resist but I am often tempted to implement my configuration with a template preprocessor to reduce the amount of boilerplate that I have. That would be great to have a way to abstract natively in keyd. However, I am not sure this would help reduce the number of descriptors.

[Nekotekina]

I'm working on C++ port, this kind of numeric limitation issues will be fixed very easily. I mostly do it for myself, no idea if other devs will agree to porting, in that case I'll just keep working on my fork.
https://github.com/Nekotekina/keyd/tree/master
keyd-project/keyd-fork#3

[rvaiya]

Apologies for the belated response, I have been dealing with a few private matters.

I am hitting that limit again. I don’t know if it is my configuration which is too complex for keyd's purpose, or if I implemented things in a complex manner.
...

This seems like a reasonable use case. I have increased the limit in the latest commit.

I don’t know if keyd will be able to improve those situations in the future. I resist but I am often tempted to implement my configuration with a template preprocessor to reduce the amount of boilerplate that I have. That would be great to have a way to abstract natively in keyd. However, I am not sure this would help reduce the number of descriptors.

I have some ideas about this for the next major version which I will hopefully have more time to work on in the coming weeks. It might be worth creating a dedicated thread about it if you wish to discuss it further.

I'm working on C++ port, this kind of numeric limitation issues will be fixed very easily.

The limitations are carefully considered. Rewriting keyd in another language is unnecessary and has nothing to do with the issue. Dynamic allocation can also be done in C and was deliberately avoided as a design decision for a number of reasons.

[Nekotekina]

The limitations are carefully considered. Rewriting keyd in another language is unnecessary and has nothing to do with the issue. Dynamic allocation can also be done in C and was deliberately avoided as a design decision for a number of reasons.

Can you elaborate? It has a lot to do with the issue, and numerous other issues I've found in the source code.

[rvaiya]

Can you elaborate? It has a lot to do with the issue, and numerous other issues I've found in the source code.

Static allocation allows for keyd to be run in environments (e.g microcontrollers) with tight memory constraints. C++ does not make dynamic allocations easier, it just hides those allocations (which were deliberately avoided).

The vast majority of users will never run into the limits that have been set, and those that do often are usually abusing a feature to do something it wasn't intended to do (I have encountered this numerous times). What you perceive to be 'issues in the code' are likely intentional design decisions. In the rare event that a limit actually merits being increased, this can be done trivially.

[Nekotekina]

Rewriting keyd in another language is unnecessary

First, it's not a rewriting, because C++ is mostly compatible with current C code.

Static allocation allows for keyd to be run in environments (e.g microcontrollers) with tight memory constraints.

You use calloc as well. Just error-prone. C++ doesn't really do anything that would make microcontrollers impossible. Exceptions and RTTI are easily disabled, some features may be simply avoided if it makes problems.

C++ does not make dynamic allocations easier

Absolutely wrong statement. It makes many things very, very easy and safe.

The vast majority of users will never run into the limits that have been set

You want to torture someone who hits them to go through all the process of increasing limits where you could just have neat std::vector<>?

those that do often are usually abusing a feature to do something it wasn't intended to do

How is this related to anything? You deliberately limit your tool to punish someone who might have generated a big config for whatever reason?

[rvaiya]

It seems you are committed to maintaining a C++ fork. That is your prerogative, but I have no interest in engaging in a language war or having a lengthy debate about every design decision.

You deliberately limit your tool to punish someone who might have generated a big config for whatever reason?

Since you are no longer engaging in good faith and appear to have accelerated development of your fork since posting your comment, I am locking this thread.