Eli Zaretskii <eliz@gnu.org> schrieb am So., 24. Dez. 2017 um 20:35 Uhr:

> Date: Sun, 24 Dec 2017 19:28:07 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: 29837@debbugs.gnu.org
>
> If I try to select utf-16 I get this
>
> set-keyboard-coding-system: Unsuitable coding system for keyboard: utf-16
>
> and I used tab completion to find which other coding systems were
> available but all the ones beginning utf-16 that I tried return the
> same message.

Oh, I now recollect that Handa-san said at some point that keyboard
input doesn't support UTF-16...

How do other macOS programs read UTF-16 keyboard input? Maybe you
could use the same way to read the sequences, and then decode them
internally as UTF-16 using coding.c facilities, and feed them into the
Emacs event queue? Just a thought.

IIUC Emacs receives the input as a single UTF-16 string (in insertText), then iterates over the UTF-16 code units, converting each into an Emacs event. That's wrong, no matter whether the input comes from the character palette or from the keyboard; normal keyboard layouts just happen to not contain non-BMP characters. The loop needs to account for surrogates.

As a small optimization (which is warranted because the function is probably called on every keystroke), this should use [NSString getCharacters:range:] to copy all the UTF-16 code units to a buffer first, to avoid repeated calls to characterAtIndex.