Feature request: Hyper, MEH and Copilot

[nicenemo]

I would like to add a few defines for combinations of modifiers, such as

• HYPER (Shift, Control, Alt and Gui)
• MEH, the same but without GUI

Based on an earlier version of the related merge request:

• Define a COPILOT key

For all combinations an all left and an all right should exist, e.g. LHYPER and RHYPER

For all combinations a variant with a key should exist, e.g. LHYP(key) and RHYP(key)

Proper documentation should be provided.

This allows:

• for easy starting of office programs on Windows. Microsoft redefined 'Hyper' as the 'OfficeKey' and it allows you to start office programs out of the box, e.g. Hyper X for Excel and Hyper O for Outlook. Hyper L starts the LinkedIn webpage. When office is not installed the web version will be started.
• Easy definition of Function key layers with modifiers that do not interfer with any programs
• Easy adding a copilot key to a keyboard

[caksoylar]

In order to understand the scope of changes that should go into something like #2341, I think it would be helpful to elaborate a bit more on this issue. Specifically, I am curious on how you think a new approach with specific defines like suggested would improve upon the status quo of combining individual modifier functions+modifier keycodes to achieve the same function. As far as I can tell, the issue definition doesn't address this specifically.

This is documented in https://zmk.dev/docs/codes/modifiers#modifier-functions, with examples showing combinations of modifiers. Do you think improving the docs on the existing approach would help? For example, we could add pointers on defining Hyper modifier and modifier functions that people could use in their keymaps.

[urob]

I don't have an opinion on MEH and HYPER.

But I see merit in adding a copilot key. The main argument here is that users don't need to know what it maps to in order to productively use it. (This is different to HYPER etc, which still require knowledge of what modifiers they map to in order to define shortcuts using them on the OS side).

[lesshonor]

(This is different to HYPER etc, which still require knowledge of what modifiers they map to in order to define shortcuts using them on the OS side).

As stated previously, (left) HYPER is the "Office" key; by your logic it has equal-if-not-greater merit.

Regardless of whether additional keycodes are added: I think it's very reasonable to document Microsoft's use of LS(LC(LA(LGUI))) as "the Office key" and LS(LG(F23)) as "the Copilot key" in the Modifiers page, similar to how a few keycodes have macOS/iOS-specific footnotes.

[urob]

I agree that the same logic applies to HYPER, though calling it (or aliasing it with) OFFICE may be even better for that purpose.

The point I was trying to make is that I see (more) merit in having a COPILOT key than exposing all possible modifier combinations, which OP motivates with allowing things like LSG(F23) and defining custom shortcuts. Having access to the various modifier combinations still requires users to "know" what combination they want (in which case, they may as well use the existing modifier functions which are convenient enough to use).

On the other hand, exposing a COPILOT key instead of the suggested LSG eliminates the need for users to know the technical details of how Microsoft defines it.

[Nick-Munnich]

HYPER commonly gets used outside of office for user defined shortcuts, to avoid conflicts due to the number of modifiers. I agree that a dedicated COPILOT key could be valuable. I don't see any value in defining modifier combinations for 2 modifiers, and am neutral towards MEH but don't see the value in other triple-modifier combinations.

[nicenemo]

I Use MEH for some shortcuts because Microsoft claimed hyper as the office key.

I have a copilot alias of in my personal zmk-config repo

[nicenemo]

In order to understand the scope of changes that should go into something like #2341, I think it would be helpful to elaborate a bit more on this issue. Specifically, I am curious on how you think a new approach with specific defines like suggested would improve upon the status quo of combining individual modifier functions+modifier keycodes to achieve the same function. As far as I can tell, the issue definition doesn't address this specifically.

This is documented in https://zmk.dev/docs/codes/modifiers#modifier-functions, with examples showing combinations of modifiers. Do you think improving the docs on the existing approach would help? For example, we could add pointers on defining Hyper modifier and modifier functions that people could use in their keymaps.

Defining Hyper and MEH etc also makes it easier to usein keyboard editor, I would think.

[Nick-Munnich]

Thinking on this some more, I think it would make more sense for the defines to be either a part of or something akin to urob's zmk helpers. I'm not sold on having this directly in ZMK as it's mostly a convenience thing, but it would work nicely as an optional convenience add-on.

It might be nice to document certain keyboard shortcuts such as copilot or unicode input in the ZMK docs somewhere without any source changes, though. "OS Software Aliases", perhaps.

[caksoylar]

The copilot key combination can be documented as an example under modifier functions.

[nguyendown]

Users can easily define C macros in their keymap. This feature is unnecessary.

I don't think we should use any copyrighted/brand names in the document either.

[nicenemo]

I do understand the argument against Copilot. That would also fly for the Windows key.

Regarding these defines, QMK has them. QMK even has two modifier combinations like I had in my original proposal.

Yes users can define a lot in their keymap. That is how this started. The keyboard setup I use, uses the same defines from my keymap, not from this proposal.

As stated earlier, I only think for keyboard editors having such defines by default would make it a bit easier. I am happy to use my defines in my keymap. I lf anybody wants to take this further go ahead.

[Nick-Munnich]

I would suggest taking your earlier PR and turning the content into a [ZMK module](https://zmk.dev/docs/features/modules), moving the docs changes into the readme. Then you could also add the 2 and 3 modifier combinations back. Once we have a centralised place to collect modules, it could then be listed under there so that interested users can find it. What would be your thoughts on that solution?