Re: keyboard input broken for certain extended characters

My impression is that you  are looking in the wrong spot for your =
problem. Normally one would only use the values from a key pressed to =
insert text anywhere. So the current behaviour here, though somewhat =
strange, should yield the expected results. What you should focus on is, =
what =E2=80=9Akeys=E2=80=98 value gets set in th event and how is it =
treated later in the application.

Hope this helps,
Fred=20

> Am 12.09.2024 um 00:27 schrieb Riccardo Mottola =
<[email protected]>:
>=20
> Hi,
>=20
> I follow up on this delicate topic.
> A compliation of this issue is not only LANG, but its combination with =
export XMODIFIERS=3D"@im=3Dkinput2"
> Unsetting XMODIFIERS makes things work better.
>=20
> However, eitout it, I tried debugging thigns with fred, checking Key =
events.
>=20
> For simple "a" key we get:
> 2024-09-11 23:13:43.028 Ink[2352:100713] XKeyEvent keyCode 26
> 2024-09-11 23:13:43.028 Ink[2352:100713] unicode modifiers: 0
> 2024-09-11 23:13:43.028 Ink[2352:100713] unicode no modifiers: 0
> 2024-09-11 23:13:43.028 Ink[2352:100713] process_key_event: keys:a =
ukeys:a
> 2024-09-11 23:13:43.097 Ink[2352:100713] XKeyEvent keyCode 26
> 2024-09-11 23:13:43.097 Ink[2352:100713] unicode modifiers: 0
> 2024-09-11 23:13:43.097 Ink[2352:100713] unicode no modifiers: 0
> 2024-09-11 23:13:43.097 Ink[2352:100713] process_key_event: keys:a =
ukeys:a
>=20
>=20
> But If I press "=C3=A0" we get:
> 2024-09-11 23:19:51.042 Ink[2352:100713] XKeyEvent keyCode 22
> 2024-09-11 23:19:51.042 Ink[2352:100713] unicode modifiers: 0
> 2024-09-11 23:19:51.042 Ink[2352:100713] unicode no modifiers: 0
> 2024-09-11 23:19:51.042 Ink[2352:100713] process_key_event: keys:=C3=A8 =
ukeys:=C3=A8
> 2024-09-11 23:19:51.125 Ink[2352:100713] XKeyEvent keyCode 22
> 2024-09-11 23:19:51.125 Ink[2352:100713] unicode modifiers: 0
> 2024-09-11 23:19:51.125 Ink[2352:100713] unicode no modifiers: 0
> 2024-09-11 23:19:51.125 Ink[2352:100713] process_key_event: keys:=C3=83=C2=
=A8 ukeys:=C3=83=C2=A8
>=20
>=20
> so key up is different (and seemingly incorrect) from key dow, which =
at a first glance is confusing, do you agree?
>=20
> A "technical" reason is apparent in XIMputServer.m for =
loopupStringForEvent
>=20
> There, KeyPress isprocessed with Xutf8LookupString if available, but =
KeyUp with XLookupString.
> Why? Xutf8LookupString is defined per manpage only for key down! =
Idisynchrasies of X11.
> However XLookupString is specified to return ISO Latin1 and string =
conersion is done with that. Since "=C3=A0" is a character perfectly =
represented by Latin-1 why isn't it working?
>=20
> Is conversion not working or something different in Press/Release? I =
changed the code so UTF8 is not used and Latin1 is used both in KeyPress =
and KeyRelease.
>=20
> 2024-09-12 00:24:31.333 Ink[6233:100667] XKeyEvent keyCode 30
> 2024-09-12 00:24:31.334 Ink[6233:100667] unicode modifiers: 0
> 2024-09-12 00:24:31.334 Ink[6233:100667] unicode no modifiers: 0
> 2024-09-12 00:24:31.334 Ink[6233:100667] process_key_event: keys:=C3=83 =
ukeys:=C3=83
> 2024-09-12 00:24:31.423 Ink[6233:100667] XKeyEvent keyCode 30
> 2024-09-12 00:24:31.423 Ink[6233:100667] unicode modifiers: 0
> 2024-09-12 00:24:31.423 Ink[6233:100667] unicode no modifiers: 0
> 2024-09-12 00:24:31.423 Ink[6233:100667] process_key_event: keys:=C3=83 =
ukeys:=C3=83
>=20
>=20
> now it is consistent! (and doesn't work at all). So it looks that =
getting an ISOLatin1 string for something simple as =C3=A0 doesn't work.
>=20
> =
https://github.com/gnustep/libs-back/blob/master/Source/x11/XIMInputServer=
.m#L158
>=20
>=20
>       /* Always returns a Latin-1 string according to the manpage */
>       count =3D XLookupString (event, buf, BUF_LEN, &keysym, NULL);
>       if (count)
>     {
>       keys =3D [[[NSString alloc] initWithBytes: buf
>                        length: count
>                      encoding: NSISOLatin1StringEncoding] =
autorelease];
>     }
>=20
>=20
> looks fine for me! do you spot the bug? or can't we trust this code?
>=20
> Riccardo