Feature: emoji (linux CS-u) via parametrized macro template

[kareltucek]

Edit: Looks I was very naive about how windows altcodes work, and so this only works with Linux and uCodeOf.

---

This simple example allows you to bind an emoji alt code onto a key (since firmware 16.0.0 / Agent 9.0.0).

tapKeySeq uCodeOf(&macroArg.1)

Then, when binding the macro to a key, just click the [...] icon and copy paste your emoji or any other unicode character.

That’s it.

For those interested, a short comment on things shown above follows. You can see there:

• macro parametrization - how any macro can be parametrized per binding site.
• unicode handling - Agent now accepts unicode characters in macro actions, and firmware can parse these in certain contexts.
• template expansion of - internally, I have added a new mechanism of string interpolation that allows doing code substitutions. Besides the $macroArg.1 expansion, altCodeOf is handled by parsing the argument and expanding it into the corresponding keyId sequence, so the line internally becomes something like tapKeySeq pLA np1 np2 np8 np0 np7 np8 rLA before the tapKeySeq starts actually processing it. Following expansions are built in atm:
  • altCodeOf - for windows style alt code, including leading alt key, typed as a decadic number using the numpad scancodes. doesn’t work.
  • uCodeOf - for linux style “alt” codes - actualy Ctrl+Shift+u codes - typed as regular hexadecimal value using regular scancodes.
  • decCodeOf and hexCodeOf - these produce just the numeric part of the expansion, so that the user can compose similar unicode sequences that use custom trigger keys.

[pcooke9]

I’m not sure why, but when I try your example by pasting in the $macroArg.1 field, it outputs :. If I use a normal macro with tapKeySeq pLA np1 rLA, it gives a proper . I tried with several emojis, etc., but it’s the wrong output no matter what I use .

Using FW v16.0.0 and Agent v9.0.0, and as usual, I’m on Win 11. Any ideas? I don’t use alt codes very often, so I may just be doing something dumb . I just wanted to try this out.

[kareltucek]

Please give a full example of a working macro and the corresponding emoji.

[pcooke9]

It’s likely this parametrization stuff is just a little over my head, and I don’t know what I’m doing. I’m also pretty tired, so I’ll look a little deeper in the next day or so.

[kareltucek]

Nono, this is probably a firmware bug. The setup looks just fine. I use linux, so I had stitched the windows version based on available resources, and may have done so incorrectly.

Please provide the working tapKeySeq macro so that I have a reference to compare to.

[pcooke9]

tapKeySeq pLA np1 rLA is a smiling face, and tapKeySeq pLA np3 rLA is a heart. Those work from a regular macro. I’m typing from phone on my way to bed, so I hope that’s useful. The holidays have kicked my butt this year, so I’ll get back to ya after a few hours of sweet black nothingness…

[ubuntudroid]

Lovely! How would I get this to work on macOS?

[pcooke9]

I tried again today using the © “Copyright Sign” (alt code is Alt+0169):

•Manually typing it in works fine. Produces the correct © “Copyright Sign”.
•Using a macro with tapKeySeq pLA np0 np1 np6 np9 rLA also produces the correct © “Copyright Sign”.
•Using a macro with tapKeySeq altCodeOf(©) produces the ⌐ “Reversed Not Sign” (alt code is Alt+169).
•Using a ParametrizableEmoji macro with © pasted in the $macroArg.1 field also produces the ⌐ “Reversed Not Sign”.

---

And again using the € “Euro Sign” (alt code is Alt+0128):

•Manually typing it in works fine. Produces the correct € “Euro Sign”.
•Using a macro with tapKeySeq pLA np0 np1 np2 np8 rLA also produces the correct € “Euro Sign”.
•Using a macro with tapKeySeq altCodeOf(€) produces ¼ “Vulgar Fraction One Quarter” (alt code is Alt+0188).
•Using a ParametrizableEmoji macro with € pasted in the $macroArg.1 field also produces ¼ “Vulgar Fraction One Quarter”.

---

I tried both increasing and removing my keystroke delay (usually set to 10ms) to see if that was the issue, but there was no change.

[maexxx]

I think it’s the leading 0 that needs to be present. Win alt codes come in two varieties if I remember correctly. The one you want always start with a leading 0.

[pcooke9]

I usually just use the Character Map app, or the emoji picker, so I’m not too fluent with alt codes, unicodes, etc.. In fact, last night, I just learned that you could use Alt+x to type unicode characters in Windows .

[maexxx]

IIRC, with leading zero means Unicode; without leading zero it refers to codes on some Windows code page.

[Tunney]

I don’t think that it is possible. I am also on a Mac. I think the only way to do emojis is via the emoji keyboard, or using the FN/Global key, that I don’t think is reproducible outside of Apple hardware.

Could be wrong though.

[kareltucek]

@pcooke, does that work with unicodes higher than 255 for you?

E.g., č = 269, or = 128519

I am getting 4 different behaviors depending on numlock state and leading 0, none of which is the desired one .

[pcooke9]

@maexxx

Win alt codes come in two varieties if I remember correctly.

Looks like you’re probably correct about the Win alt-code variants. The version used seems to be app specific. E.g., Notepad++ app accepts single digit alt-codes (Alt+np1 = ), but Windows Notepad won’t produce anything using single digits.

---

@kareltucek

does that work with unicodes higher than 255 for you?

E.g., č = 269, or = 128519

I am getting 4 different behaviors depending on numlock state and leading 0, none of which is the desired one

Do you mean using Alt+ numpad269, etc., or the Alt+x method? Alt+x method uses unicode hexcodes, not regular Win alt-codes.

As for numlock state, I’m pretty sure Windows is supposed to require numlock to be enabled in combination with Alt+numpad digits in order to produce actual alt-codes. It usually only outputs the numpad navigation stuff otherwise. That doesn’t always seem to be the case though .

Basically, the codes in that example don’t produce the desired results for me either; regardless of using the macros, or when manually typing it in:

•Alt+269 and Alt+0269 both produce what I think is “carriage return” in Windows Notepad and Chrome browser, and produces ♪ in Notepad++ app and on keyboardchecker.com (last key pressed result).

•Alt+128519 produces the number 3 in Windows Notepad and Chrome, and produces • (bullet) in Notepad++ and keyboardchecker.

•Alt+x method produces characters I don’t recognize for 269 and 0269, and does nothing for 128519.

---

Sorry if this is a jumbled mess. This is just one of the most convoluted rabbit-holes I’ve gone down in a while . TBH, I’m no longer sure what’s an actual Win Alt-code or some other dec/hex/unicode, and when/how to use which version. The Windows Character Map’s alt-codes vary wildly from other sources:

So anyway, I’m not sure if I’m entering codes correctly, or if alt-code is always even the proper terminology . If you can offer more specific directions for me to follow, I’m glad to help further. Since there doesn’t seem to be any consistency with how Windows handles the codes, I’m at a loss for where to go from here.

[pcooke9]

So far, the easiest way I’ve found to manually type unicode characters in Win 11 is to use hex-codes via one of the following methods. It still takes some trial-and-error to figure out what to use though:

•For most apps to accept unicode characters via typing, you first have to add a new Windows registry string called EnableHexNumpad. Then you can type unicode characters by using Alt+numpad + followed by the hex values (can’t use regular number row this way). Windows Notepad brings up a link editor when you press numpad +, so you can’t use this method with it.

•In Windows Notepad, you can just enter unicode hex-codes (using regular numbers or numpad) and then press Alt+x. This is the only app I’ve tried that does this (no registry hack needed).

[maexxx]

Yeah, I stand corrected. According to https://altcodeunicode.com/:

If you are new to Alt codes and need detailed instructions on how to use them, please read How to Use Alt Codes to Enter Special Characters. Take note of the brief explanation of the reference list of Alt codes below:

• Alt codes without leading zeroes (Alt nnn) produce characters & symbols based on IBM Code Page 437 / DOS.

• Alt codes with leading zeroes (Alt 0nnn) produce characters & symbols based on Windows Code Page 1252.

• Alt codes without leading zeroes (Alt nnn) and Alt codes with leading zeroes (Alt 0nnn) may produce different, or the same, characters and symbols as can be observed side-by-side in the list below.

So none of them are Unicode, or maybe just where CP-1252 and Unicode match.

It’s difficult.

[maexxx]

And the recommendation for entering unicode is: U+ hexcode Alt+x

This may not work in all applications.

The U+ introductory sequence helps in the case you want any hex digit to be followed directly by a Unicode character - it will mark the beginning of the hex code to be converted when you press Alt+x.

[pcooke9]

@maexxx

The U+ introductory sequence

Leading with U+ doesn’t seem to do anything in Windows. Not in the handful of browsers and text editors I’ve tried, at least.

EDIT:
Actually, scratch that. It does work to mark the beginning of the conversion if you use normal +. I was assuming it was supposed to be numpadPlus, like the EnableHexNumpad method’s Alt + numpadPlus.

Thanks for the link btw.

[kareltucek]

EnableHexNumpad

But with this, alt + numpadPlus + character triggers program’s menu shortcuts, so the thing is unusable in practice .

Do we have any other suggestion or conclusion than that the altCodeOf should be simply removed?

I can add npDecCodeOf and npHexCodeOf so that windows-style mappings can be experimented with, but I am not sure it is worth it at all…

[pcooke9]

I’d suggest to give it a little time to see if anyone else has any feedback, but it does seem like it’s a bit much IMO. Idk why Mac & Windows haven’t straightened this out by now. Honestly, looks like yet another point in Linux’s favor.

Thankfully, the following works fine in Windows Notepad, which is good enough for me ATM .