Simplifying the Star key behavior for better cross-platform support

[fenixero]

I've been looking into implementing Engram-es both in QMK and as native keyboard layouts for Windows, macOS, and Linux, as well as using it with typing practice software such as Keybr or Type Fu.

While doing so, I found that the current behavior of the ☆ (Star) key presents an interoperability problem.

Currently, Star acts as a special composition key, allowing combinations such as:

☆ + aeiouAEIOU = áéíóúÁÉÍÓÚ (acute accent)
☆ + nN = ñÑ
☆ + cC = çÇ
☆ + Shift         + [letter] = [letter] with a diaresis/umlaut: ü
☆         + AltGr + [letter] = [letter] with a grave accent: è
☆ + Shift + AltGr + [letter] = [letter] with a circumflex: â

It also provides access to other diacritics through modifiers, including grave accents and circumflex accents.

This is elegant from a layout-design perspective, but it is difficult to implement consistently across different environments.

QMK

Engram-es can be implemented in QMK, but QMK cannot simply tell the operating system that the same dead key should produce an acute accent with vowels, a tilde with n, and a cedilla with c.

The composition therefore has to be handled partly or entirely by the firmware. For example, QMK may need to detect ☆ + n itself and generate ñ.

This works for typing, but applications such as Keybr cannot see the original ☆ + n sequence. They only see the events generated by the firmware.

Supporting this properly in Keybr would therefore require changes to Keybr itself.

Native OS layouts

Native layouts for Windows, macOS, and Linux can potentially implement the Star behavior through custom composition/dead-key rules.

However, this creates a different implementation from QMK. Keybr would also need to understand these custom composition rules rather than its existing conventional dead-key behavior.

As a result, modifying Keybr to support the QMK implementation would not necessarily guarantee that the same solution works with native Windows, macOS, and Linux implementations.

More generally, the current Star behavior makes it difficult for existing typing-training software to represent Engram-es without special support.

Possible simplification

What if Star used only conventional dead-key behavior and ñ were moved to one of its modifier levels?

For example:

☆ + aeiouAEIOU = áéíóúÁÉÍÓÚ (acute accent)
☆ + Shift         + [letter] = [letter] with a diaresis/umlaut: ü
☆         + AltGr = ñ
☆ + Shift + AltGr = Ñ

This would make Star compatible with conventional dead-key mechanisms while making ñ and Ñ regular AltGr characters.

It should make Engram-es considerably easier to implement consistently in QMK and native Windows, macOS, and Linux layouts.

It would also make the layout compatible with software such as Keybr using its existing dead-key and AltGr support, without requiring Engram-es-specific changes to Keybr.

What about the removed diacritics?

The current Star design also provides convenient access to grave accents, circumflex accents, and ç.

These characters are useful when writing other languages, but they are not required for Spanish orthography. Spanish does require the acute accent, ñ, and occasionally the diaeresis (ü).

Therefore, I think it may be reasonable for an explicitly Spanish-oriented Engram variant not to dedicate the base Star combinations to grave accents, circumflex accents, or cedilla. They could still be made available elsewhere in the layout if multilingual input is desired.

Motivation

My main goal is not necessarily to change the ergonomics of Engram-es, but to make it practical to implement and use consistently across:

Windows
macOS
Linux
QMK keyboards
typing-training software such as Keybr or Type Fu

The current Star behavior is possible to reproduce in individual implementations, but each environment may require its own special handling. A simpler definition based on standard dead-key and AltGr behavior could make Engram-es much easier to distribute, maintain, and practice.

I'd be interested to know whether there was a particular ergonomic or linguistic reason for choosing ☆ + n → ñ and ☆ + c → ç, and whether simplifying Star in this way would be worth considering.