The test runs for a long time, so it might be a good idea to split it into a separate Workflow

I have no experience with Rust no_std and don't know how to implement it.

TL;DR: I believe this would require an API break to implement.

Let's ignore no_std for the moment. How would you implement this "normally"? This has to return Option<&'static str> (and this is publically reachable via Keysym::name(). So, the only possibility is to have some kind of static, huge string table (well, it could be lazily initialised, but this is still complicated).

This in contrast to the API from xkbcommon which gets a buffer as its argument and writes the string into that. Thus, no 'static (in Rust-speak) is involved.

Can't the static str get generated dynamically? Something like this:

fn name() -> Option<&'static str> {
    static RESULT: [u8; 3] = [97u8, 98u8, 99u8];
    core::str::from_utf8(&RESULT).ok()
}

The values of the RESULT buffer would have to get calculated. I guess the (big) downside of this is that there is more and more static memory getting allocated and never freed

This would require a massive table for computation that would surely bloat the program. Just returning names like this is enough; we don't have to be concerned about the entirety of Unicode.

We could also add a new method that handles Unicode, but returns Cow<'static, str> instead. This would only be enabled on an alloc feature.

For the tests, try running the test cases in parallel with rayon. It should speed things up.

Something like this:

That RESULT can only store a single value. As a caller, I can keep references to multiple names at once: let foo = [k1.name(), k2.name(), k3.name()];. Thus, to be sound, RESULT may no longer be modified after it was filled once (since the borrow is 'static and thus effectively forever).

Okay, returning names for keysyms representing Unicode codepoints will not be part of this PR.

I used rayon for the test. The tests are failing right now, because the newest keysyms were not yet added to this crate. Once #26 gets merged, it should succeed. This will happen on a regular basis, but the output of the test lists the differences.

The test is ignored per default and does not run in the CI workflow, because running the test still takes around 5 mins. Unfortunately we have to install xkbcommon even if the test is ignored. This adds around 2 min to the time the workflow takes to complete.

I think the PR is ready to be reviewed

Please rebase on #26

Sure, it has been rebased