Implement lightweight trie-based Compose Key for QMK.

[agdphd]

Description

Implement a knockoff of the Linux compose key which can emit a specified string (including Unicode if support is compiled in) when the user hits a new modifier COMPOSE followed by a configurable sequence of keys. Distinct from the Leader Key in two ways:

• No timeouts--purely based on sequence of keypresses
• Prints the specified string as soon as a complete sequence is keyed

Changes are mostly isolated to a new key processor which:

• Holds a global static search trie for compose codes (learning enough C to write a prefix trie to run on a keyboard was definitely a fun weekend project :)
• When COMPOSE is pressed, starts a state machine to search the trie with subsequent keypresses, which
  • Exits whenever the user misses a prefix, emitting the last keypress to the rest of the processing stack
  • Exits when the user completes a code, printing the corresponding string
  • Exits when the user hits COMPOSE again
• Configuration is via a very simple DSL with a compiler implemented in the qmk binary under the new command qmk compose, which generates a C file that statically initializes the user's compose sequence trie.

I have added test coverage in /tests/basic and confirmed that make test:basic passes. (make test:all seems to be broken at master.) I have also tested this on my Gergo with the Linux Unicode string printer.

New files list copyright of Google LLC instead of me per https://opensource.google/docs/patching/.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• Leader key improvements? #586

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[drashna]

New files list copyright of Google LLC instead of me per opensource.google/docs/patching.

I'm not sure that this actually applies here,

Also, this seems to be a similar implementation to leader keys.

Also, nice on the additional tests

[agdphd]

Here's the relevant section of the Google guidelines: https://opensource.google/docs/patching/#license-headers-and-copyright-notices

In particular, for the new files, "Googlers should add Google’s copyright notice (or a “The Project Authors” style copyright notice) to new files being added to the library if permitted by the project maintainers."

The code is, of course, offered under the GPLv2 and may be used by the project as with any other contribution--it's just copyright of Google instead of me personally.

And yeah, this is similar to leader key, but it's sequence-based rather than time-based and supports arbitrarily long command sequences at relatively low per-keypress byte cost. I haven't yet taken on the whole project, but I plan to migrate most of my existing Linux .XCompose (hundreds of sequences, some as long as five or six keypresses) to this framework and expect it to fit comfortably on my Gergo.

[tzarc]

https://opensource.google/docs/patching/#license-headers-and-copyright-notices

When contributing to third-party projects, Googlers do not need to add Google’s copyright notice when authoring patches to existing files. Googlers should add Google’s copyright notice (or a “The Project Authors” style copyright notice) to new files being added to the library if permitted by the project maintainers.

Any file that has already been published with a copyright notice attached to it must include that copyright notice when the file, or any portion thereof, is added to any project.

[tzarc]

Seems you've force-pushed the previous Google LLC copyright notices back into your PR.

[agdphd]

Ugh, sorry, looks like I made a mess of things while trying to catch up to master. I think I have things figured out now...

[agdphd]

Note that this is not currently working--it crashes my keyboard on boot when the compose sequence trie is large :( I'll update here when I get it figured out.

[agdphd]

OK, this now actually works on my Gergo, with a trie of ~100 compose sequences: https://github.com/agdphd/qmk_firmware/blob/argd/keyboards/gergo/keymaps/argd/compose.conf

[theol0403]

I imagine you have already seen it, but since #8359 hasn't been mentioned in this PR I thought it would be a good idea to link it, so people can compare the implementation (assuming they do the same thing).

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[stale]

Thank you for your contribution!
This pull request has been automatically closed because it has not had activity in the last 30 days. Please feel free to give a status update now, ping for review, or re-open when it's ready.