alacritty: Inconsistent char output using Alt key binds in macOS
Which operating system does the issue occur on? macOS (10.13.6) Alacritty: 0.2.5
I have following in my settings file
- { key: F, mods: Alt, chars: "\x1bf" }
- { key: I, mods: Alt, chars: "\x1bi" }
Doing a /bin/cat
and typing <kbd>Option</kbd>+<kbd>F</kbd> followed by a <kbd>B</kbd> produces ^[fb
while <kbd> Option </kbd>+<kbd>I</kbd> followed by a <kbd>B</kbd> produces ^[iˆb
I came across this issue while using kakoune editor. I reported the issue there but it seems it is alacritty’s issue (both iTerm & Terminal print ^[ib
)
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 10
- Comments: 62 (20 by maintainers)
Commits related to this issue
- Revert "Kakoune: Remove config" I'm feeling a little curious about that Kakoune is up to and if my shell/terminal issues have been resolved. So far, it seems that Alacritty still has issues when usin... — committed to thorncp/dotfiles by thorncp 5 years ago
- Early implementation of IME Sets whether the window should get IME events. When IME is not allowed, the window won’t receive Ime events, and will receive KeyboardInput events for every keypress inste... — committed to raphamorim/rio by raphamorim a year ago
I just found out about Alacritty, and while excited to use it, found that my fingers have the key bindings so ingrained in them. So, I fixed this problem solely in my
alacritty.yml
file. If this helps anyone else, here is my config. This makes Alacritty behave like Terminal.app. Key repeats and diacritics are all fixed.There may be a few key combinations that others use, is there anyway we can make a standard MacOS config?
Bump: I’ve been running this for a couple of months now with no issues. Is there anything I can do to help get this merged in for good so I can get back to running a vanilla release?
hi, people
@kjmph any news about fix merge?
Hello @jkp, my apologies on my delayed response, I lost steam trying to get winit to accept my patches. They were focused on having virtual keyboards work as well, which the patch didn’t make any worse than what was previously existing. I moved back to Terminal.app myself, maintaining the patches for about a year got time consuming for me.
To make alacritty use mentioned PR you should also apply
If anyone would like to test, the pull request went through a few rounds. I have an open pull request that fixes this issue:
https://github.com/rust-windowing/winit/pull/1449
If anyone can test to provide support for the pull request, there is a single change to alacritty:
This is a duplicate of #1610 .
Ah, so it turns out that these characters have a utf8 length of 2, so that’s why the escape characters aren’t printed.
So the problem is just that when pressing alt and hitting f/i, that it’s putting down modified characters. I think the only way to resolve this problem would be to request with our window library to not send combined characters whenever the alt key is held down and the
alt_send_esc
option is enabled.@kjmph Just built and tested your updated branch and it fixed the
ctl-meta-{foo}
issue. I will keep testing with this branch for a while and report back any new issues I find. Thanks for all your work on this!OK - I added one more line to
window.rs
to hard code.set_option_as_alt(true)
and now this works as expected and I can remove all the custom mappings in my config.I’ll run with this for a while but initially it looks good. One question that you may know the answer to @kjmph - I have some emacs bindings that use both
ctl
andmeta
(eg C-M-) but with this patch it seems that emacs only sees M-\ when I press all three keys together. I captured the events thatalacritty
sees and they look correct:Any ideas whats going on?
Hello @jkp, I live in emacs and running the patch listed in rust-windowing/winit#1449 has covered all emacs bindings that I can realistically test as one person. Would you mind testing out the branch listed in the PR? I can always update against the latest master if you have problems building. I’ve been running the same custom binaries for most of this year, so the branch may need to be refreshed.
yes I am. thanks for your PR. can
winit
distinguish between L-Option, R-Option? If answer is yes, then maybe it’s possible to keep both behavior of alt, i.e.L-Option
can be set to send alt andR-Option
continue to modify characters before sending it toalacritty
(more acting like aAltGr
?This would definitely be configurable.
I’ve created an issue upstream to track a solution for this problem: https://github.com/tomaka/winit/issues/768
so other than filing a bug, what would help motivate them to resolve this faster? 😃