With the 'Insert Text' Action inserting the following text
%|% πββοΈ
The cursor is positioned 4 characters further left than it should be.
I'm attaching a reproduction macro.
I don't experience that with Brevis -- Automating Text Expansions with can use either Paste or Insert Text by Typing and handles emojis. Both put the cursor where I expect to see it.
I wonder if you have "Simulate matching deletes before executing" set on the trigger?
I do indeed. That shouldn't be a problem using vanilla KM, right?
Brevis looks pretty wildβ¦
Depends on the trigger. Brevis uses a regex so I don't delete. Maybe post your macro (or a small one showing the same problem) for diagnosis?
The minimal reproduction macro is attached to the OP. 
Ah, missed that, thanks.
Well, I'm getting the expected results (as far as cursor positioning goes) in BBEdit with Unicode (UTF-8) set for the character set. The %|% locates the cursor before the space that sits before the emoji.
But I'm getting what you see in Vivaldi as I type this.
I tried different emoji and different trigger settings without effect. Same with token processing on the Gear menu.
Without the %|% the cursor is positioned following the emoji. Eliminating the space has no effect. So I'm guessing it has something to do with the character width of the emoji (two double wides being four characters).
So %|% seems to presume single character widths.
I tried setting you replacement string as a variable, getting the length with a Filter, pasting the variable, then using a While to execute backspaces for the length of the variable. Close but no cigar:
Thanks so much for looking into this so thoroughly.
This is exactly my assumption. I actually have some software that I've written for personal reasons that was sensitive to certain Emojis with variant selectors. Things like 
.
I think you're right on the money when it comes to what Keyboard Maestro is assuming. Hopefully this can get the attention of one of the devs.
1 Like
What thinketh thou, @peternlewis?
Yes, it does appear to be an issue.
Unfortunately, Emoji are sort of tacked on to Unicode so these issues come up from time to time. Interestingly, if you paste this sequence in to BBEdit for example, you get (as well as the incorrect cursor placement).
And there are invisible characters in there as well so it takes four arrow keys to get across it, so it's impossible the %|% will ever work in all cases.
I will see if I can improve it in the more normal case, but I may not be able to.
If you know the string, you can of course avoid the %|% token and simulate the left arrow keys yourself with
- Repeat N times
Type a Keystroke Left Arrow
(which is all Keyboard Maestro does, except it calculates N for you (incorrectly in this case)).
1 Like
Believe me I sympathize with the frustration of having to deal with this sort of thing. Like I said I'm writing my own software that's sensitive to this stuff and my 'solution' was to write a regex that strips out all characters that can trigger this behavior rather than having to figure out the actual text. Β―_(γ)_/Β―
That said, the problem has to be tractable in some way. Every text box I write in on macOS moves the right number of 'characters' when I press the arrow keys (as you pointed out). Emoji's aren't exactly an edge case (although these 'variant' Emoji's feel more like that than other ones) so it'd be awesome if KM could deal with it.
I wonder if positioning the cursor could be changed to always simulate arrow keys? Then 'all' you would need to do would be to figure out the correct number of 'rendered' characters which feels like it should be possible?
Thanks in advance!
That's how it always works.
Yes, that is correct, βallβ I have to do is figure out how to do that. It's on the list.
I hope that it's clear that I was quoting all there to indicate that it was hiding a ton of work. I appreciate how tricky this is to get right! I'm not at all trying to minimize that.
I wonder if the Keyboard Maestro editor for the macro itself could be used? I just tested it and it looks like the arrow keys work properly in the text field.
Does the text control expose some sort of 'visual character count' method or something?
In the hopes that it might help, this is the elisp code that I have which strips these characters that screw up TTY programs which I think may correspond with characters that shouldn't be counted for arrow key purposes.
(replace-regexp-in-string
"[[:cntrl:]]"
" "
(replace-regexp-in-string
;; Steve Purcell @sanityinc, of course, will be
;; imortalized forever here as the cause of all
;; this grief.
(concat "["
;; variation selectors 1-16
(char-to-string ?\U0000fe00)
"-"
(char-to-string ?\U0000fe0f)
;; variation selectors 17-256
(char-to-string ?\U000e0100)
"-"
(char-to-string ?\U000e01ef)
;; emoji modifiers 1-6
(char-to-string ?\U0001f3fb)
"-"
(char-to-string ?\U0001f3ff)
;; regional indicator symbols A-Z
(char-to-string ?\U0001f1e6)
"-"
(char-to-string ?\U0001f1ff)
"]")
""
(file-name-nondirectory dir-file)))
If the text control doesn't have a visual characters method on it perhaps that could get you somewhat towards not counting the characters that don't 'count'.
Its not the arrow keys not working, it is Keyboard Maestro not counting the characters correctly to know how many arrow keys to simulate.
For example, paste the πββοΈ character in to a Typed String trigger and you will see it counts as 3 characters (for heavens sake don't try to use emoji in Typed String triggers!).
I get it!
I think we're on the same page at this point in terms of the problem that needs to be solved if possible.
laughs maniacally
1 Like
Fixed for the next version.
2 Likes