How to define a layer for german umlauts?

[lammermann]

I try to define a layer which allowes my qwerty keyboard to use german umlauts, but so far i failed with my config. I tried

(deflayer umlauts
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    ü   _    ö   _    _    _    _
  _    ä   ß   _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _              _              _    _    _
)

But it fails to parse because the umlauts are not defined.

Then I tried this

(deflayer umlauts
  _    _    _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    @ü   _    @ö   _    _    _    _
  _    @ä   @ß   _    _    _    _    _    _    _    _    _    _
  _    _    _    _    _    _    _    _    _    _    _    _
  _    _    _              _              _    _    _
)

(defalias
  ä (unicode ä)
  ö (unicode ö)
  ü (unicode ü)
  ß (unicode ß)
)

But it seems to input something different from the normal umlaut signs that come from a german keyboard. Does anybody know how to archive sending umlauts?

Btw, this is a great project

[jtroo]

This might also be OS dependent, can you share whether you're on Linux or Windows?

[lammermann]

I'm on Linux. The config is encoded in utf8 so i figured (unicode ö) would work. If others have the same problem (greek, kyrilic, japanese, etc) maybe a function like (keycode_from_utf8 ö) would be great.

[jtroo]

I tested copying your defalias section and played around replacing the characters in deflayer with characters copied from here: https://www.ascii-code.com/ .

I only replaced the deflayer characters but not defalias, meaning if the characters were actually different, then there should be a configuration error since the unicode characters are not equivalent. There was not a configuration error; the characters seem to be the same.

I also tried taking the outputs from typing the unicode characters while having kanata running and copy-pasted them back into deflayer, like from the extended ascii website. It was the same result, so the outputs seem to be the same as the extended ascii.

From this testing, I'm not sure what you're seeing when you say:

But it seems to input something different from the normal umlaut signs that come from a german keyboard

Could you say some more about what you're doing/testing as evidence that the outputs are different between a german keyboard and kanata's unicode output?

---

As an aside, something else you can do is to use the german locale for your operating system and make kanata output the relevant AltGr+character combination on your desired layer for the desired key.

[lammermann]

I also tried taking the outputs from typing the unicode characters while having kanata running and copy-pasted them back into deflayer, like from the extended ascii website. It was the same result, so the outputs seem to be the same as the extended ascii.

How did you do this? I thought about doing the same thing to adjust my config. But I don't know very much about keyboards and how exactly they generate keycodes, so I didn't knew where to take the outputs from typing.

Could you say some more about what you're doing/testing as evidence that the outputs are different between a german keyboard and kanata's unicode output?

I have one qwerty keyboard (it's the builtin one on my laptop) for which I run my kanata config. At the same time I have an external german keyboard connected via usb (without kanata config). When I type an ä on my german keyboard in a console window, it writes an ä. When I type an a on my kanata keyboard while the umlaut layer is activated in the same window it does something different: When I use alacritty as console window it seems to enter e4\n (I see e4 in the input line and e4: coomand not found at the output) and when I use kitty as console it opens a kitty builtin program (the unicode input kitten) .

I tested copying your defalias section and played around replacing the characters in deflayer with characters copied from here: https://www.ascii-code.com/ .

I only replaced the deflayer characters but not defalias, meaning if the characters were actually different, then there should be a configuration error since the unicode characters are not equivalent. There was not a configuration error; the characters seem to be the same.

Can you paste the config you used in the chat? Maybe I can use it to tweak my own and make it work.

Thank you so much for your help! Sorry if I ask simple questions with obvious answers. I'm just a complete newbie to keyboard tweaking.

[jtroo]

One issue you're hitting is that the way kanata inputs unicode characters is a "generic" way, which supports accented letters as well as emojis. This method isn't supported by all applications though. The way the operating system does it is that it reads some scancode from the USB keyboard and, depending on your locale, may output different characters for the same USB input.

I recommend you look at gerhard-h's config. As they state, when using the german layout in the operating system, the physical QWERTY key of the opening square bracket [ is actually converted to ß by the operating system. That means the german keyboard and QWERTY keyboard should be sending the same USB input code for the key, but the operating system is translating it.

How did you do this?

I typed the unicode character and copied it back into the config, but that's of no help if you're not able to get the key outputted.

Can you paste the config you used in the chat?

The config I used is not appreciably different from the one you pasted, I think it's issues other than the config that you're hitting.

[gerhard-h]

I use this together with german keyboard layout on windows

(defsrc
  esc       f1
  \         1    2    3    4    5    6    7    8    9    0    [    ]    bspc
  tab       q    w    e    r    t    z    u    i    o    p    ;    =
  caps      a    s    d    f    g    h    j    k    l    grv  '    /    ret
  lsft 102d y    x    c    v    b    n    m    ,    .    -    rsft
  lctl      lmet lalt           spc                           rctl
)

ü (unicode ü) and so on works es expected, but does not allow shift + @ü to be upper case Ü so I use

  ;; ü = ;   
  ;; ö = grv 
  ;; ä = ' 
  ;; ß = [

you can get the codes be running kanata --debug

personally I didn't use a layer for umlauts but tap hold because
a) I didn't like the typing flow interuption of a layer key
b) Uppercase would be a tripple key effort

oö (tap-hold 140 140 o (macro grv ) ) ;; macro is used to disable key repeat

another idea I had: put all umlauts in the homerow of one side of the keyboard and the layer key on the other side

[j-steinbach]

Not sure if it is still relevant, but Uppercase can also be achieved with a fork. This writes the capital letters when Shift is held.

(defalias
  Ae (unicode Ä)
  Ue (unicode Ü)
  Oe (unicode Ö)
  ae (unicode ä)
  ue (unicode ü)
  oe (unicode ö)
  _ae (fork @ae @Ae (lsft rsft))
  _ue (fork @ue @Ue (lsft rsft))
  _oe (fork @oe @Oe (lsft rsft))
)

I have this on a custom en_DE layer that replaces []\' with üäöß when I need to write in German. The toggle sits on CapsLock.

[gerhard-h]

usesing fork + unicode is the eaiest and maybes the best method to use diacrits that are NOT part of your OS-layout.
But US ctrl+[ is the same as DE ctrl+ü but not the same as ctrl+(unicode ü)

P.S. since the time this article was written not only fork was introduced also deflocalkeys
with a deflocalkey section your config becomes much more readable

(deflocalkeys-win
  -    189
  ü    186
  +    187
  #    191
  ö    192
  ß    219
  ^    220
  ´    221
  ä    222
  <    226
)

[j-steinbach]

That is indeed good to know. However, I don't think I fully understand the deflocalkeys. You seem to suggest that it should be used over the unicode input?

I am using a standard US QWERTY keyboard, and want to add the missing keys from the languages I write in (German, French, Turkish, ..).

• Can I use localekeys as replacement of unicode?
• How do I get the correct base10 OS Code? The documentation only refers to evtest, which obviously only produces the US key codes. I found two possibly related links, kbdlayout and kbdproject, but they don't seem to describe the necessary codes.

[gerhard-h]

deflocalkeys is only usefull when using a non US keyboard layout
You can't define new characters with deflocalkeys. If I would replace all ä with é in my config the keyboard would still output ä, because
ä 222 means "if kanata encounters ä in the config - outside unicode - it treats it as key number 222"

[W-L]

Bit late to the party, but another way of achieving this is to use a diaresis dead-key in a macro. Not sure if this is linux-distro or UK keyboard specific, but for me ralt-[ is a dead-key for diaresis, so umlaute can be used as below with capitals as a tap-hold or fork as others have shown above. The ß character is available as ralt-s, so even simpler than the umlaut with the dead-key.

(defalias

 ;; umlaute
 oe (macro RA-[ o)
 ue (macro RA-[ u)
 ae (macro RA-[ a)
 Oe (macro RA-[ S-o)
 Ue (macro RA-[ S-u)
 Ae (macro RA-[ S-a)
 _oe (tap-hold 200 200 @oe @Oe)
 _ue (tap-hold 200 200 @ue @Ue)
 _ae (tap-hold 200 200 @ae @Ae)
 sz RA-s
 
)

[timhansinger]

Even later to the party.

On macOS the dead-key is RA-u. Therefore you could do this (pressing/unpressing the shift key defines which macro will be used):

  ;; German Umlauts
  oe (macro RA-u o)
  ue (macro RA-u u)
  ae (macro RA-u a)
  Oe (macro (unshift ralt u) o)
  Ue (macro (unshift ralt u) 50 u)  ;; I had to put in a delay of 50ms for u, otherwise it didn't work
  Ae (macro (unshift ralt u) a)
  _oe (fork @oe @Oe (lsft rsft))
  _ue (fork @ue @Ue (lsft rsft))
  _ae (fork @ae @Ae (lsft rsft))
  sz RA-s