Fix deviations from EurKEY 1.3 specifications and add better support for ISO keyboards

[NMAC427]

Hi! Thank's for this great repo. I discovered that the keylayout file contained some minor errors in the α and √ dead key layers. More specifically, the ∡, ₊ and ″ symbols were either misplaced or missing. Additionally, on an US keyboard that uses the ISO layout, the `~ key moves between the left shift and z key. In its place there should be a §± key. That way the EurKEY layout remains consistent with what is printed on the keys. This was not the case (instead both keys were exactly the same and produced `~) so I decided to fix this as well.

[sonicdoe]

Thanks for the kind words and for opening this pull request!

Regarding ∡, I cherry-picked your fix to 14ed4398f580d17daaa0d33ec0d358deb240e670 and also removed the character from the caps lock key map.

Regarding ₊ and ″, I think these are both due to the same misunderstanding. eurkey-layout-complete.pdf specifically calls out „ and “ for mapping these, but your commit maps these characters to ". Logically, I think this makes more sense, but perhaps we could fix the original layout here too.

Regarding the sameness between ANSI and ISO, that was an intentional decision. The specification doesn’t have any guidance regarding ISO layouts and I don’t want one key to suddenly move just because the user switches keyboards, so I mapped both of them to the same characters.

Of course, this is not consistent with what is printed on the keys, but I think this is an acceptable trade-off, especially for users of a custom keyboard layout (where the layout often deviates from the printed keycaps). Furthermore, not all (physical) ISO layouts have a §± key there; for example, the German layout has a ^° key.

Finally, regarding the help key, I cherry-picked your commit to 1510ddac69bad4f3e1d601702880db2453c8bcaf. Out of curiosity, do you still have a keyboard with a Help key or do you use it in another way?

[NMAC427]

I just double checked and the specifications and what you say is indeed true. To me it very much looks like an issue caused by "smart quotation marks" („ and “ are the correct quotation marks in German that's why many text editors tend to replace "" with them). All other mac implementations of EurKEY also differ in this aspect from the specifications. I sent out an email to the creator of EurKEY to get his feedback on this issue. I'll let you know as soon as I get a response.

Regarding the ANSI / ISO differences: The reasoning behind why I suggested moving the `~ key and putting a §± key in its place was because that's how they are positioned in Apples ISO US-layout (neither Windows nor Linux does this). I assume that Apple decided to do this because it is more ergonomic to reach down with your pinky than it is to reach up.

As you know, this is remapping is done on the key code level. This means, that the only two viable solutions are to either have a duplicate key when using an ISO keyboard (this is the solution you chose) or letting macOS do it's thing and have the key move. I absolutely understand the reasoning behind your decision, and as someone who uses a (Swiss) German layout himself I am OK with the layout not matching what's printed on the key caps (I'm still trying to get used to z and y being switched). However, I would argue that in this case it actually does make more sense to do it the Apple way:

1. If you previously used the Apple US layout on a ISO keyboard, all the keys on the default and shift level are still in the same location.
2. If you have a physical Apple ISO keyboard with the US layout printed on it (or a British Apple keyboard), the printed letters are still correct.
3. All other EurKEY implementations for macOS do it this way. -> Better consistency.
4. In case a user wants the the `~ key to be int the traditional ANSI location, they can run the "Keyboard Setup Assistant" (sudo open /System/Library/CoreServices/KeyboardSetupAssistant.app/Contents/MacOS/KeyboardSetupAssistant) and then select ANSI as their layout. This makes it so that the `~ key switches its position with the §± key. For more details take a look at this StackOverflow post.

I think the best solution would to do it the Apple way and then adding a section to the README that explains how you can change the position the keys using the Keyboard Setup Assistant. But in the end the decision is up to you.

Regarding the help key: I think Apple stopped producing keyboards that have a help key in 2007. I don't own a keyboard that features a help key, but after all, having it theoretically working doesn't do any harm. I guess the main reason I added it was so that this repository matches the other EurKEY repos. I believe that because your implementation is for version 1.3, has by far the best icon and your keylayout file is way cleaner than the other ones, makes this repository a great candidate to be the new reference implementation for macOS with the hope of eventually making it available through brew.

[sonicdoe]

I’m with you that this seems like a smart quotation mistake. I took a look at EurKEY for Windows which, as far as I know, was developed by the author himself, and AltGr+M+" is mapped to ₊ there as well. I’m guessing it’s the same for AltGr+Shift+M+", but unfortunately that entire layer doesn’t work on my system. Anyway, I have cherry-picked your changes to 65a330e7d4c534359c88258a5c95a155ec7cdf34 and 2aac60bdb89480c5a363778eba4e888d32f7c4b3.

Regarding ANSI and ISO, your suggestion using Keyboard Setup Assistant intrigued me, but it seems like it doesn’t work for my use case. When open-ing the assistant, it immediately exits. I guess this is due to me using a Magic Keyboard by Apple which properly communicates its type to macOS, so macOS doesn’t even let me reconfigure the keyboard type.

I believe that because your implementation is for version 1.3, has by far the best icon and your keylayout file is way cleaner than the other ones, makes this repository a great candidate to be the new reference implementation for macOS with the hope of eventually making it available through brew.

Thank you! That was indeed my goal with this implementation, and I hope to make it available through Homebrew too.