Always apply defaults when creating a screen (the C-side global state
default will not have the intended values without this), and provide a
way to override default values with a new optional parameter
When a key is pressed, text is generated from xkb and attached to the
global key_event variable.
If another key is pressed before ibus replies, this text in global
variable would be overwritten before the processed reply comes in and
the wrong character would be input, as shown in logs with
--debug-keyboard:
Press scancode: 0x19 clean_sym: w composed_sym: w text: w mods: numlock glfw_key: 87 (W) xkb_key: 119 (w)
↳ to IBUS: keycode: 0x11 keysym: 0x77 (w) mods: numlock
Press scancode: 0x20 clean_sym: o composed_sym: o text: o mods: numlock glfw_key: 79 (O) xkb_key: 111 (o)
↳ to IBUS: keycode: 0x18 keysym: 0x6f (o) mods: numlockIBUS processed scancode: 0x19 release: 0 handled: 0
From IBUS: scancode: 0x19 name: w is_release: 0
↳ to application: glfw_keycode: 0x57 (W) keysym: 0x77 (w) action: PRESS mods: numlock text: o
on_key_input: glfw key: 87 native_code: 0x77 action: PRESS mods: 0x0 text: 'o' state: 0 sent text to child
IBUS processed scancode: 0x20 release: 0 handled: 0
From IBUS: scancode: 0x20 name: o is_release: 0
↳ to application: glfw_keycode: 0x4f (O) keysym: 0x6f (o) action: PRESS mods: numlock text: o
on_key_input: glfw key: 79 native_code: 0x6f action: PRESS mods: 0x0 text: 'o' state: 0 sent text to child
Since the whole event is memcpy'd we can just use the text from the
event attached to the reply instead.
The old code would print "\e[22m" if either bold or dim was unset, which
is the "normal, neither bold nor dim" control sequence.
Print that only if neither are set, and instead print "1" and "2" (bold,
dim) values individually.
It is standard to start complete helpers with underscore to avoid
clobbering the function namespace ; like other shells do.
It is ironic for a completion helper to make completion less agreable...
