Hangs whenever I try to input a diacritic (macOS)

[lbebber]

As soon as I try to type ~, ', etc., I can't type anything on the terminal anymore—it doesn't exactly hang, as I can still select text, resize the window, and stuff, but it stops responding to the keyboard.

[jwilm]

Why did you close this? Is this not an Alacritty issue?

[uvesten]

I could replicate it anyway. Don't know if it's called a 'diacritic', though, but if I try to compose for example 'ë' alacritty hangs on entering '¨'. (Swedish keyboard layout, macOS)

[lbebber]

I was looking into the other issues and found some similar ones (like #170 and #55), and found the pull request that was supposed to fix it (#159), so I decided to close and try and compile again to see if I overlooked something.

It's still not working though—I suppose it's a different issue in the end—so I'm reopening this.

[mnylen]

For me, I'm unable to type dollar sign $ and tilde ~ characters using macOS. Using Finnish layout. Trying to type tilde hangs the process.

[jwilm]

I'll have to figure out how to repro this on my end and look into it. Seems bad.

[lbebber]

If it's any help, you can just set your keyboard to the U.S. International layout, so you don't have to juggle keyboard layouts around (in case you're on a Mac, that is).

[mnylen]

Is there anything I can do to help debug this problem further? Any logs I could provide?

[jwilm]

@mnylen specific instructions on how to reproduce this for someone with a U.S. keyboard would be incredibly helpful (eg. switch to layout X, enter keys x,y,z).

[lbebber]

Hey @jwilm—as I said, you can just switch to the "U.S. International - PC" layout. Then just try to type "~".

[jwilm]

Ah, perfect. Sometimes I just want idiot-proof instructions 😄.

[karlprieb]

Hey guys :) @jwilm thanks for the great work!
Any update on this bug?

Thanks!

[algesten]

The hanging part of this problem is fixed by PR #580. Compose key seems to be sending 0 bytes on the first keypress, which causes the freeze.

However, fixing the freezing, doesn't actually fix the compose key function (ë outputs as e). Though it may be cleaner closing this issue with #580 and open a new issue to track the correct implementation of compose key.

[algesten]

Some further investigation for macOS led me to UCKeyTranslate. I think winit/glutin may be doing the translation from window events to input characters in a too naïve way.

To reiterate stackoverflow:

• Receive key press event for Option-e.
• Call UCKeyTranslate() with the virtual key code (for e), the modifier key state (for Option), and a variable to store the dead key state.
• UCKeyTranslate() outputs an empty string and updates the dead key state.
• Receive key press event for e.
• Call UCKeyTranlate() with the virtual key code (for e) and the variable that holds the dead key state.
• UCKeyTranslate() outputs "é".

Question is where that state is to be held. Winit may be tries to be stateless, but the translation can't be done with less than remembering the dead key.

[jwilm]

@algesten love all the research you're doing into this problem! Thanks so much ❤️ 🌟 😄

As for winit being stateless, I don't think that's strictly true. Some of the logic in the x11 impl of process_event references some window data to translate the x event. If there's state needed to correctly interpret events, I'm sure there would be no resistance to adding it.

[algesten]

@jwilm thanks! i tried looking at a PR for this, but i'm struggling a bit where to start. UCKeyTranslate is part of carbon, not cocoa, and i can't find any rustified carbon more than this which only deals with dates.

i think what i need to do is (and please give me a steer here, if i'm on the wrong path):

1. in winit make thin wrapper only for UCKeyTranslate local to that project.
2. implement some new event type (or extend existing), to notify glutin/alacritty that a dead key has been pressed.
3. in winit redo character translation with UCKeyTranslate and send new event.
4. make PR in winit for sending new event for all platforms (not just macOS).

[mrmekon]

I've been wanting to try Alacritty for a while, and the complete inability to type any symbols has been a slight issue, so I've just had a go at fixing it for Mac. I ended up implementing 'dead keys' and AltGr support, more-or-less, for the Swedish keyboard. This probably works for all latin-based key layouts, but I don't know. It now works beautifully for me, but I may have broken it for everyone else... I don't have a U.S. keyboard to test with.

I think this whole issue is less of a "bug" and more of an inherent lack of support for keyboard layouts, and probably needs some extra thinking around it. I have no idea what happens on any Asian keyboard layouts. Apparently some support chaining multiple dead-keys. This patch doesn't. The presence of AltGr should be autodetected, but I couldn't find any way to do it, so I added it as a config option. Are there any keyboard that have a right-alt AND AltGr? No idea. winit maps raw key codes to conceptual keys (ex: 0x1e => RBracket), which simply isn't true across keyboard layouts, so depending on the VirtualKeyCode enum is dangerous.

Here's what I came up with:

Adding dead keys to winit: mrmekon/winit@f547bba

Adding dead keys and AltGr to Alacritty: mrmekon@eeb8d10

I added dead key state to both winit and alacritty. We all prefer stateless things, but it seems like the right way to go; dead keys are inherently stateful. On the winit site, it needs to keep state to even figure out what character should be generated, and on the alacritty side it needs to keep state to show a placeholder for the deadkey, and replace it when the final character is available.

I implemented drawing the dead key placeholder with ANSI codes. I don't know if that's portable or a good idea... it seems to work in bash and emacs, at least.

You'll probably want to add the new altgr: true option that I added to your alacritty.yml if you're testing it on a non-US layout.

Have a look, test it out, and let me know if you're interested in a PR. If you don't like this approach, feel free to use it as reference for your own implementation.

[mrmekon]

Meh, there's another problem that this doesn't fix. The Alt vs AltGr decision needs to be made in winit, somehow. Macs treat both Option keys like AltGr – they modify the meaning of the character – so winit will always return the ≈ character when you type Option-x. If you're running emacs, it gets M-≈ (or whatever your language does) instead of M-x and obviously doesn't understand it. Without fixing that in winit, you would have to remap nearly every key in alacritty.yml to get Alt- behavior, and the remapping is different for different keymaps.

It's trivial to request the 'unmodified' character with Carbon. It's deciding when and how to pass it down that's the trick. This is really a special requirement that only terminal emulators need... Macs don't typically have the 'alt' concept, except in terminals.

[francesca64]

If anyone's interested in trying out a potential fix for this, I've made a branch here: https://github.com/francesca64/alacritty/tree/macos-kb

Relevant winit PR: rust-windowing/winit#518

[simmel]

dead keys works now (~, ¨, ^ etc) but @, $, |, [ and ] still sends an escape before making them unusable.

kaka:~$ cat -v
^[@^[$^[|^[[^[]´

Adding bindings for them works as a workaround though:

key_bindings:
[…]
  - { key: Key2,     mods: Alt,     chars: "@"                           }
  - { key: Key4,     mods: Alt,     chars: "$"                           }
  - { key: Key7,     mods: Alt,     chars: "|"                           }
  - { key: Key8,     mods: Alt,     chars: "["                           }
  - { key: Key9,     mods: Alt,     chars: "]"                           }

Anything I/we can do to help?

[francesca64]

Anything I/we can do to help?

Of course. You can research the solution to this problem, and then make a PR to winit that implements it.

[chrisduerr]

dead keys works now (~, ¨, ^ etc)

So this issue is resolved. Problems with other characters should probably be handled separately to keep issues small and precise.

[michaelvanstraten]

I still have the same exact issue described.

[daibertdiego]

I'm facing the same issue especially if I type '" (single quotes and right after double quotes). Initially, I thought that this was a problem in my Neovim, but then just using the regular terminal, I saw the freezing happening.