Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS: Ctrl+L with Ergo-L keyboard layout doesn't produce a ctrl encoding #5448

Closed
mitchellh opened this issue Jan 31, 2025 · 8 comments · Fixed by #5738
Closed

macOS: Ctrl+L with Ergo-L keyboard layout doesn't produce a ctrl encoding #5448

mitchellh opened this issue Jan 31, 2025 · 8 comments · Fixed by #5738
Labels
input Keyboard or mouse input os/macos
Milestone

Comments

@mitchellh
Copy link
Contributor

Steps to reproduce:

  1. Install Ergo-L: https://ergol.org
  2. Launch Ghostty
  3. Run any keyboard input tracker, i.e. kitty +kitten show_key -m kitty (or any other)
  4. Switch to Ergo-L
  5. Ctrl+L (On US physical: Ctrl+H)

Notice the control key doesn't show up.

I've tracked this down to the code below, but this code exists for a reason. We should investigate why we do this, fix this, and ensure we don't regress the reason we did this in the first place.

// This is a hack. libghostty on macOS treats ctrl input as not having
// text because some keyboard layouts generate bogus characters for
// ctrl+key. libghostty can't tell this is from an IM keyboard giving
// us direct values. So, we just remove control.
var modifierFlags = event.modifierFlags
modifierFlags.remove(.control)

@guidoschmidt
Copy link

guidoschmidt commented Feb 1, 2025

The line you mention above (modifierFlags.remove(.control)) actually also removes all kind of Ctrl + key combinations for me, e.g. writing zig b and use Ctrl + e to accept the auto completion to zig build. Or using Ctrl + w to remove the previous word.

Commenting out that line and doing a fresh build solved that for me, so seems to be not only related to Ergo-L. But as you mentioned, probably the removal of Ctrl had some purpose?

Though I'm actually using a Capslock key mapped onto Tab, you can set that up in macOS System Settings via Customise modifier keys.

@aurelberra
Copy link

Hello! I am using Ergo-L on macOS and I can confirm that I have lost all the usual Ctrl shortcuts in Ghostty with the latest update: Ctrl+a, Ctrl+e, Ctrl+c, etc.

@hbish
Copy link

hbish commented Feb 3, 2025

Can confirm the same issue when using latest version of Ghostty with workman keyboard layout. So not just isolated to Ergo-L.

@pfaure
Copy link

pfaure commented Feb 3, 2025

qwerty-lafayette here, I can confirm the same for any Ctrl combo.

@matklad
Copy link

matklad commented Feb 3, 2025

+1, version 1.1.0 of Ghostty is not really usable with Workman layout. Here's how I downgraded to 1.0.1:

cd ~/Downloads/
curl  https://raw.githubusercontent.com/Homebrew/homebrew-cask/99378d4eaa63a12947b8eccd526a6d9d27564cce/Casks/g/ghostty.rb > ghostty.rb
brew uninstall ghostty && brew install --cask ./ghostty.rb

@mitchellh mitchellh added this to the 1.1.1 milestone Feb 3, 2025
@00-kat
Copy link
Contributor

00-kat commented Feb 4, 2025

P.S.: "I also have this issue"1/"Please fix it!"/"Will this be fixed"2 type posts aren't helpful and send an unnecessary email notification to all subscribers; consider using the 👍 reaction instead :)

Footnotes

  1. It has already been established that many people are having this issue, and that this is in fact a real issue, with seemingly most non-US keyboard layouts, in [macOS] Ctrl key not working anymore in 1.1.0 (for all non-US layouts?) #5487 and the Discord help post I linked there.

  2. Not happened yet, and hopefully doesn't happen 🤞

mitchellh added a commit that referenced this issue Feb 13, 2025
Fixes #5448

We previously removed the ctrl modifier for text commit (IME-style)
to workaround a libghostty quirk (as noted in the comment in the diff).
But this broke other keyboard layouts.

This commit attempts to clean this up slightly -- but not completely --
by removing that hack, and only modifying the ctrl behavior for the
UCKeyTranslate call.

Long term, I plan to remove UCKeyTranslate completely, as noted in the
todo comment already written just below this diff.

This fixes the aforementioned issue and hopefully doesn't regress any
other behavior. I tested the following:

  1. Dvorak Ctrl characters
  2. Ergo-L Ctrl characters
  3. US standard Ctrl characters
  4. Japanese IME input Ctrl input to modify IME state
mitchellh added a commit that referenced this issue Feb 13, 2025
Fixes #5448

We previously removed the ctrl modifier for text commit (IME-style) to
workaround a libghostty quirk (as noted in the comment in the diff). But
this broke other keyboard layouts.

This commit attempts to clean this up slightly -- but not completely --
by removing that hack, and only modifying the ctrl behavior for the
UCKeyTranslate call.

Long term, I plan to remove UCKeyTranslate completely, as noted in the
todo comment already written just below this diff.

This fixes the aforementioned issue and hopefully doesn't regress any
other behavior. I tested the following:

  1. Dvorak Ctrl characters
  2. Ergo-L Ctrl characters
  3. US standard Ctrl characters
  4. Japanese IME input Ctrl input to modify IME state
@mikejmz24
Copy link

@mitchellh, after installing Ghostty version 1.1.1, I lost my Nvim motions involving ctrl.
Can I configure any settings to bring back the behavior I have before the latest update?

@mitchellh
Copy link
Contributor Author

I'm looking into this now, please go to #5743

@ghostty-org ghostty-org locked as resolved and limited conversation to collaborators Feb 13, 2025
@ghostty-org ghostty-org locked as resolved and limited conversation to collaborators Feb 13, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
input Keyboard or mouse input os/macos
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants