Re: keyboard input broken for certain extended characters

[Fred Kiefer]

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 ‚keys‘ value gets set 
in th event and how is it treated later in the application.

Hope this helps,
Fred 

> Am 12.09.2024 um 00:27 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> 
> Hi,
> 
> I follow up on this delicate topic.
> A compliation of this issue is not only LANG, but its combination with export 
> XMODIFIERS="@im=kinput2"
> Unsetting XMODIFIERS makes things work better.
> 
> However, eitout it, I tried debugging thigns with fred, checking Key events.
> 
> 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
> 
> 
> But If I press "à" 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:è ukeys:è
> 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:è ukeys:è
> 
> 
> so key up is different (and seemingly incorrect) from key dow, which at a 
> first glance is confusing, do you agree?
> 
> A "technical" reason is apparent in XIMputServer.m for loopupStringForEvent
> 
> 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 "à" is a character perfectly represented by Latin-1 
> why isn't it working?
> 
> 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.
> 
> 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:Ã ukeys:Ã
> 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:Ã ukeys:Ã
> 
> 
> now it is consistent! (and doesn't work at all). So it looks that getting an 
> ISOLatin1 string for something simple as à doesn't work.
> 
> https://github.com/gnustep/libs-back/blob/master/Source/x11/XIMInputServer.m#L158
> 
> 
>       /* Always returns a Latin-1 string according to the manpage */
>       count = XLookupString (event, buf, BUF_LEN, &keysym, NULL);
>       if (count)
>     {
>       keys = [[[NSString alloc] initWithBytes: buf
>                        length: count
>                      encoding: NSISOLatin1StringEncoding] autorelease];
>     }
> 
> 
> looks fine for me! do you spot the bug? or can't we trust this code?
> 
> Riccardo