Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

try to fix extended char handling in NSEvent #50

Merged
merged 1 commit into from
Sep 19, 2024

Conversation

rmottola
Copy link
Member

Issue described in #49

I found out that sometimes XLookupString returns more than one char for a single key, which does not make much sense for Latin1.
So I suspect I am getting back UTF-8 in that case and indeed, interpreting that string as such works!

Looks like X11 got "extended" here beyond the Spec that says Latin1 only. The question remains why it is happening for characters contained in Latin1?
Last found is that €, not contained in Latin1 gets not back.

However I think this "hack" is pretty safe, since if only one char is returned, Latin1 is used as per-spec.

…s (even for characters that representable in Latin1) so try our best to interpret them
@rmottola
Copy link
Member Author

Addendum. Actually also € works! It is returned as 3 chars and is interpreted correctly.
What confused me is that its value for ukeys (that is without modifiers) is 'e', while for è keys and ukeys are both 'è'

@rmottola
Copy link
Member Author

Tried on Linux where I had no issues and continue having no issues with Italian keyboard.

Would you mind testing e.g. with German keyboard?

Copy link
Member

@fredkiefer fredkiefer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to test, whether we could switch to NSUTF8StringEncoding even when there is just one character. But as I didn't find the time to do so, it is probably better just to merge this change.

@fredkiefer fredkiefer merged commit 4e3ca27 into master Sep 19, 2024
4 checks passed
@rmottola
Copy link
Member Author

@fredkiefer if you want somehow create a TODO and work with this on the next hacking session together or if I should test a patch for you, I'm available! In the meanwhile we see if this change creates issues.

@rfm
Copy link
Contributor

rfm commented Sep 19, 2024

I think the change is good. If the data is utf-8 a single byte is guaranteed to be correct latin1. If the data is latin1, it's either got the top bit set (and would be invalid utf-8) or it hasn't (and it's the correct ASCII value). So it seems very safe to me.

@rmottola
Copy link
Member Author

@rfm thanks for you opinion, I was a bit wary about this because it is somehow against documentation of X11 and I saw 2 or 3 bytes and was attempted at trial-and-error, but it is safe for 1byte.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants