In the obscure ui choices department, I am that weirdo who uses openbsd as a desktop system, At one point not thinking I did ctrl+a in a firefox textentry and much to my surprise it did the right thing and moved the cursor to the beginning of the line.
I had no idea using unix vs windows cursor movement was even an option, because linux never picks the correct method, Still have no clue how it is set(a gtk option? but qt apps are set the same.) But salutes to whatever obsd porter picked it, really made my day.
GNOME:
gsettings set org.gnome.desktop.interface gtk-key-theme-name 'Emacs'
or GTK: ~/.config/gtk-3.0/settings.ini
~/.config/gtk-4.0/settings.ini
[Settings]
gtk-key-theme-name = Emacs
I have it enabled but it can be very confusing: depending on whether you're in a text field or not, in say a browser, ^W will mean delete word or close tab. And sure enough closing a tab will sometimes but not always focus the URL box of the previous tab.There used to be an obscure internal GTK setting to properly separate control plane from command plane like on (then named) Mac OS X but IIRC it's long gone / hardcoded to only GTK on macOS.
EDIT: Found it, GTK up to 3 had proper <Primary> vs <Control>. In what I would consider to be a fatal regression, GTK 4 just aliases <Control> and <Primary>, leaving the apps to do the work.
> because linux never picks the correct method
Because linux is not an operating system. A specific operating system will have some specific behaviour.
Ctrl+a to carriage return the cursor seems work universally everywhere on a Mac. It even works on Microsoft products, incredible coming from the company that poorly reinvents everything and completely disrespects the default behaviors.
I always find this curious, is readline implemented at the hardware level or something? There’s just no effing way that was a priority ticket on Microsoft Teams given all the obnoxious weirdness of their chat text field.
And bizarrely, ctrl+k, ctrl+w, and ctrl+e are more seldom. Maybe 50-50 chance for those. But trusty ctrl+a is always there.
Another surprise was discovering that Ctrl-J adds a newline in Claude Code. I'm fairly certain this is a feature of the environment, not CC, but it works everywhere I've tried it. KDE Konsole on Debian.
macOS supports emacs-like bindings natively: Ctrl-A/Ctrl-E for line start/end, Ctrl-K to kill, Ctrl-Y to yank, Ctrl-F/Ctrl-B for forward/back, etc.
They are defined in /System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict. You can create ~/Library/KeyBindings/DefaultKeyBinding.dict to augment or override those.
Anything built on AppKit that uses the standard text system (NSTextView, NSTextField, and the field editors that back them) supports those bindings “for free”.
For non-native apps, Karabiner Elements⁽¹⁾ is the answer, using a config like this⁽²⁾.
⁽¹⁾ https://karabiner-elements.pqrs.org/
⁽²⁾ https://github.com/pdelfino/karabiner-config