[Zirias]

In case someone wonders what's "special" about it:

user perspective: As far as I know, it's the only tool offering somewhat reliable emoji input using faked X11 keyboard events. "x11-emoji-picker" comes close, but delegates faking events to "xdotool", with weird consequences like having to restart it to direct emojis to a different window ;)

hacker perspective: It directly integrates xcb in a different event loop (here based on pselect()) and actually works – xcb is IMHO pretty great except for pretty much enforcing its own async model, internally using poll() and reading from the X server into buffers at many occassions, hidden from the consumer. If all your app does is communicate with the X server, you just happily use xcb's model. As soon as you need different things (e.g. local timers), you have a problem. The typical way to address that is dedicating another thread to xcb (AFAIK also done that way by toolkits offering an X11 backend). I hated that idea enough to be stubborn about doing it directly in my main thread, and with quite some trial-and-error, finally succeeded.

[1oooqooq]

why not use xcompose?

[kragen]

i do love me some xcompose (https://github.com/kragen/xcompose) but being able to see the possible options is pretty nice

[Zirias]

Not sure you really mean the compose mechanism provided by Xlib (and xkbcommon etc ...)? If so, this wouldn't work for all these emojis that are represented by grapheme clusters, ZWJ-sequences or are just "qualified". The result of a compose sequence is limited to a single "key symbol", which can only encode a single unicode codepoint.

Even for those emojis consisting of a singe codepoint, it would really miss the point. There are LOTS of emojis available, an emoji keyboard (or emoji picker) shows them organized in groups and allows searching for them.

[kragen]

actually it's possible to send multiple key symbols from a compose sequence; i have sequences for 'n’t ', ' — ' (with thin spaces), ' the ', ' The ', ' and ', ' I’m ', etc. see https://github.com/kragen/xcompose/blob/master/dotXCompose#L...

but i agree that compose is not a great user experience

[keybored]

> If so, this wouldn't work for all these emojis that are represented by grapheme clusters, ZWJ-sequences or are just "qualified". The result of a compose sequence is limited to a single "key symbol", which can only encode a single unicode codepoint.

I use the compose key as an abbreviation expander among other things. So far this works fine in all applications.

Though I don’t know if we’re talking about something beyond typing the XCompose sequence on the keyboard. If we’re talking about sending programmatic keypresses to applications like in this submission then I don’t know.

[account42]

> The result of a compose sequence is limited to a single "key symbol", which can only encode a single unicode codepoint.

Not true even if some broken toolkits impose that limitation.

[Zirias]

Thanks for the pointer, this made me have another closer look at xkbcommon's API. Probably not too relevent for the tool I'm currently writing, but I'll keep that in mind: Instead of a key symbol, you can also obtain an utf-8 encoded string. Nice.

Still, in practice, it will only work with some applications...

[1oooqooq]

i enter the five emojis i ever need to use by pressing <multikey>+u and then typing the emoji word. i think i can use skin color thumbs up just fine.

but yeah, no search. but also no extra windows. when i asked i assumed compose + something like an IME could solve both with the search/window being optional.

[Zirias]

Xcompose only offers sequences started with the "compose" key (whatever it is mapped to) and resulting in a single X key-symbol, so to type an emoji needing multiple uniciode codepoints that way, you'd have to enter multiple "compose sequences". Whatever you describe here is not simple Xcompose. AFAIK, GTK offers entering unicode codepoints in a similar way ...

Of course you can do a lot of things with "input methods" (like popping up some "picker" only when wanted). But then you'll depend on X clients being aware of them in some way, e.g. by implementing the XIM protocol. Lots of applications have that (even xterm), so it might be what you prefer and that's fine. My method with faked key press events is definitely hacky, but will work with any X client, that's the point of it ;)

[kps]

> Xcompose only offers sequences started with the "compose" key (whatever it is mapped to)

Not correct. For example, on my usual keyboard layouts¹, I use sequences starting with <dead_A> and <dead_U> for superscripts and subscripts.

> and resulting in a single X key-symbol

Also not correct. I certainly have a few non-single-keysim entries in my .Xcompose, e.g. <Multi_key> <R> <2> ↦ ℝ².

¹ https://github.com/datatravelandexperiments/kps-keyboard-lay...

[keybored]

Indeed. In my experience you can use whatever mappings you want. Just grab a writing script that you never type in and go ham : `<Ethiopian_B> …` (Note: made up keysym).

[numpad0]

Are there any major apps that don't support XIM? An IME is required for CJK languages, so there shouldn't be apps that meet (in common use && have CJK users && not supporting IME) criteria.

Implementation is beyond my ability, but if en-US locale were to finally adopt IME, I think it should be semi-trivial to include an optional dictionary file trained with emoji :tofu_on_fire: notation.

[twic]

> and resulting in a single X key-symbol

¯\_(ツ)_/¯

(or, as it's spelled through my .XCompose, shift-altgr 3 3)

I think there was a time when compose sequences could only emit a single character, at least in some contexts. But as far as i can tell, every text box in every app on my machine supports multi-character sequences.

[nextaccountic]

What is multikey?