Allow easy switching/cycling between Unicode input modes

[vomindoraan]

Note: drashna:make_unicode_init has been merged into this as #4325 will likely be merged soon.

If you are reviewing this, click here to view the changes from that branch to this one. Those are the actual changes that this PR will introduce once #4325 is merged.

The old changes are available on vomindoraan:cycle_unicode_input_mode_new_backup.

---

Using a board with multiple OS's is a common occurrence. This adds an easy, declarative way of choosing and switching between Unicode input modes when you move from OS to OS. Here's how:

1. Add your preferred input modes to your config.h as follows: #define UNICODE_SELECTED_MODES UC_WINC, UC_LNX.
2. Use the keycode UC_MOD (and optionally UC_RMOD) to switch between modes.

If you select more than two modes, QMK will go through them cyclically, in the order they were specified, starting with the first. UC_MOD cycles forward and UC_RMOD cycles in reverse. For example:

#define UNICODE_SELECTED_MODES UC_WINC, UC_LNX, UC_OSX
// with UC_MOD:   UC_WINC → UC_LNX → UC_OSX → UC_WINC → …
// with UC_RMOD:  UC_WINC → UC_OSX → UC_LNX → UC_WINC → …

As a consequence, you don't need to call set_unicode_input_mode() in eeconfig_init_user() anymore if you're using this feature, since the input mode will automatically be initialized to the first one you specified in the list (but you still can if you want to).

The changes are written to EEPROM by default. This means that you only need to switch the input mode when changing machines, as the last picked mode will be stored between uses on the same OS. You can disable this by adding #define UNICODE_CYCLE_PERSIST false to your config.h. Do this if you want to conserve your EEPROM, or want the board to always boot with the first input mode in your list. You can then call persist_unicode_input_mode() yourself if you want to save the input mode on demand.

Note: This PR only adds new functionality and shouldn't change existing Unicode behavior.

To-do

• Update docs
• Add new quantum keycodes for the behavior

[bit-shifter]

Konstantin - this looks to provide the exact functionality that I need for unicode input mode cycling.

Is there anything that I can do to help get it over the line?

[vomindoraan]

@bit-shifter I need to add the new functionality to the docs, but that shouldn't be a problem as it'll more or less be a copy-paste of the description I wrote in the PR comment. Just need to get around to doing it.

Other than that I've been thinking about adding a predefined keycode that calls cycle_unicode_input_mode() so that users don't have to make one themselves. I assume you would benefit from something like this?

[drashna]

Other than that I've been thinking about adding a predefined keycode that calls cycle_unicode_input_mode() so that users don't have to make one themselves. I assume you would benefit from something like this?

Honestly, I think that we need keycodes for all of the Unicode modes.

[vomindoraan]

That sounds good too. Have keycodes that change to a specific input mode — as well as one that cycles through a predefined set of input modes selected by the user (the most common use case being toggling between two modes).

Should there be a keycode for persist_unicode_input_mode() as well, in case the user opts to disable writing cycle changes to EEPROM by default? Or is that use case niche enough that it doesn't warrant a keycode of its own?

[vomindoraan]

I've separated this from the changes in #4217 and have rebased the branch onto the latest master.

If someone else could test it, that'd be much appreciated 😄

[drashna]

Wouldn't it be better default behavior to default all modes?

[vomindoraan]

No, the default should be that the feature is disabled by default — that way it's opt-in only. This minimizes the chance of anything breaking. For example, if it were enabled by default, some boards that are close to the firmware size limit would break because the feature uses extra memory (namely the selected array).

[vomindoraan]

These changes have been incorporated into #4325.