Expansion Not Working for Unicode Characters in iTerm

I am using a typed string trigger to get the current Chrome Title, and this triggers an Insert Text By Typing action.

This is working fine in all apps (including macOS Terminal), except, in the case of iTerm, if any of the inserted characters is Unicode, iTerm will ring the bell and skip the character.

I have checked all the usual suspects, verified I can paste Unicode text in iTerm just fine, and even did a little experiment with Hammerspoon's hs.eventtap.keyStrokes which worked perfectly fine inserting Unicode chars in iTerm.

Does this work for everyone else?

An example: the Title of this page is "· - Wiktionary", but running the macro in iTerm gives " - Wictionary".

Hey @nkgm,

I'm not seeing this in iTerm2 3.3.0beta10.

Keyboard Maestro properly types:

· - Wiktionary

If I change to “Insert by Pasting” I get the same thing.

What version of iTerm are you using on what version of macOS?

I looked briefly at iTerm's preferences and did NOT find a setting that obviously would affect this, but I might have missed something.


1 Like

After a lengthy email discussion with @peternlewis we managed to track down the root cause. I've been meaning to do a write-up of the resolution a couple of weeks now, so here it is for future reference:

As already mentioned, iTerm worked fine when it was sent Unicode keystrokes by Hammerspoon, so it's not as if iTerm was incapable of it. Keyboard Maestro however, does something more elaborate: it will attempt to find each Unicode character in the currently active Input Source (ie the keyboard layout), and will replay the actual combination of modifier keys and letter required to produce that character.

As Peter puts it:

The difference between Keyboard Maestro’s processing and Hammerspoon is that for keys that can be typed in the current keyboard layout, Keyboard Maestro types them that way, and only for characters that cannot be typed that way does it resort to sending a Unicode character.

Keyboard Maestro it typing the characters as they would be typed on the keyboard, and iTerm is, for reasons of its own choosing, converting them to other behaviours.

For example, the middle dot (·) is typed with option-shift-9 under my current keyboard layout. Instead of sending a simple key event with just the middle dot, KM sends a full blown option-shift-9 to iTerm, which (in my current setup) treats the option key as Esc+:
(Switching this to Normal would fix the issue but is not an option)

At the moment I'm finding it hard to find any practical use for this behavior, but I respect Peter's judgement, and he was even cool enough to include a new preference in the next update addressing this issue:

I have added an undocumented and unsupported hidden preference for the next version, which you can enable with the command:

defaults write com.stairways.keyboardmaestro.engine ForceInsertTextByTypingToUseUnicode -bool YES

For the time being I'm working around the issue by having KM call a hammerspoon://paste-by-typing?text=... URL, and HS will subsequently do the typing.

PS - In case you're wondering why I'm choosing to use the keystroke method instead of paste (which works flawlessly btw), the answer is to avoid littering my clipboard history.

1 Like

You may still prefer your method, but just so you know, after you do a paste you can execute a KM Delete Past Clipboard action, with "0" as the clipboard (meaning current), and this will remove the item just pasted, thus avoiding littering. :wink:

1 Like

I like Alfred for my clipboard history, and AFAIK there's no way of automating the removal of individual clipboard entries there :slight_smile: