Incomplete support of dead keys on non U.S. QWERTY Keyboard on OS X

Update:

OK I tried on Windows and the problems doesn't occur.

Unfortunately, it is 😞

(Minecraft 1.5)

Oops, sorry I forgot to update the affected versions...

Can anyone experiencing this issue try the new launcher https://mojang.com/2013/06/minecraft-snapshot-13w25a/ with 1.5.2 or even the current snapshot ?

I tried with the Launcher in Dev 0.9.5 and 13w25c. The dead keys have now absolutely no effects.

Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Is this still a concern in the current Minecraft version *14w11b / Launcher version 1.3.11 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

This bug is still present, and it's impossible to get the ~ which is very important for the console and command block!!!

Why is the status is “Resolved” ? It is not...

It is (it was now) "Awaiting Response".

Reopened, Thanks.

Oups sorry, I forgot it was “standard procedure“ to solve them with no response 😉

Affects 1.8.8 and 15w31c, on OS X 10.10.4. Dead keys are completely ignored. Tested with U.S. and a custom keylayout on an English/international hardware keyboard.

Same as @Fenhl, OSX 10.10.4 and German keylayout.

It's impossible for me to produce a ~ character. Very annoying for commands...
Why are they nobody assigned on this very important bug?
Oh yeah... the answer is “OS X” I guess...

Zeccotine Leonov: Try alt+cmd+n.

Thanks that works. The normal alternative way to produce a ~ is alt-n.
However... I still not understand why after 2.5 years, they still don't care about it. If it's just a Java version problem I would understand and wait for the native launcher. If it's LWJGL then... that's a bummer, but at least let us know...

Affects 15w35b. I was unable to find a related issue on the LWJGL issue tracker.

Thanks for the research and the info, Fenhl!

Affects 15w45a.

Affects 15w49a.

Affects 15w50a.

Affects 15w51b.

Affects 16w02a.

Affects 16w03a.

Affects 16w04a.

Affects 16w05b.

Affects 16w06a.

Affects 16w07a.

Affects 16w07b.

Affects 1.9-pre1.

Affects 1.9-pre3.

Affects 1.9-pre4.

Affects 1.9.1-pre3.

Affects 1.9.2.

Affects 16w20a and OS X 10.11.4.

Affects 1.10 - What a surprise

It also happens with the mac Australian keyboard format with ´˜ and some others.

It's just any keyboard with deadkeys 🙂

Yup. My usual dead keys are things like option-u e becoming ë (on Dutch layout, but seems to be a universal Mac thing). In Minecraft the dead key is completely ignored, making just e. If I set it to US International "e becomes e as well (otherwise literally "e).

In normal applications the (option-e/u/i/whatever style) dead key inserts the accent as if on top of a space, highlighted in dark yellow. The next key then inserts that character into the highlighted accent if deemed possible (restricted to Latin 1, it seems, covering most realistic use cases). If not deemed possible, the highlighted accent will remain on the space and the new character is inserted after it, like ´r although Unicode can do ŕ (or résümȩ̊́́́̌.́́́ for that matter). Adding an accent to an accent has the same effect, finalizing the first one on a space and highlighting the new one after it. US International is a little different in that something like " first inserts " rather than ¨, and adding a space will maintain " but something like e becomes ë.

Ideally all of this behavior would be captured but I'd be happy if at least the end result became the same.

I can't let an external program write "~" or "@" in Minecraft. In all other programs it works. Is this the bug I'm searching for?

I have another program (GeoGebra) that runs similar to Minecraft (process name is also "javaw.exe") and in it it works, too. So it's not a problem with Java.

Also in Snapshot 17w06a

also in snapshot-17w16a

Ah, Mojang, this is really important for spanish people, it's difficult to communicate without accents 😞

17w17b too

17w18a too
someday this will be fixed

I'll note that this works fine on Windows (Spanish (Spain) keyboard layout which I sometimes use in addition to English (US)). As previously mentioned, this is probably an issue with whatever native libraries LWJGL uses; LWJGL/lwjgl#50 and d3254e0 may be related. I don't own a mac, so I can't check for a root bug with LWJGL, but I might be able to create a minimal test case (eventually) that someone who does have one can use to get data for a bug report. It also might be that this is fixed within LWJGL3 (MC currently uses LWJGL 2).

What are you trying to say? That may be the problem of the mac? I was looking over what LWJGL is, but it's for developers

also in 1.12-pre2

Also in 1.12-pre3 😞

4 years...

If the bugs was on Windows it would have been long fixed.

The joy of Java which emulates a machine that doesn't even exist for the purpose of a multi-plaftorm which obviously isn't even guaranteed.

also 1.12.2-pre1

This appears to be fixed in 17w43b, at least for my custom keylayout.

Yeah Fixed for me to. I guess that's the update to the LWJGL 3.x that did the tricks. Finally...

But Polish characters can be created by pressing ~ and one of this characters: e,o,a,s,z,x,c. ~ and U doesn't work to cerate €.