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.
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
GNOME:
or GTK: 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.
https://gaphor.org/2022/12/10/gtk4-macos-keybindings/
> In what I would consider to be a fatal regression, GTK 4 just aliases <Control> and <Primary>, leaving the apps to do the work.
Gtk4 makes some many dumb decisions, that I always code new programs against Gtk3. They also deleted so many useful widgets and essentially said "We don't care implement it yourself". I can't afford my programs to become unusable just because they completely lost the plot, so I intend to keep using Gtk3 forever.
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.
I have been using Linux / GNOME as my primary environment for the last 20 years, but at my current job, that was not an option, so I'm on macOS.
I tried for a week to get used to the unfamiliar key bindings for text input, but then I gave up—I'm a vim user after all!—and found a system setting to use the bindings I am more familiar with. This was picked up by many applications, but notably _not_ by the Microsoft suite, which appears to have the default macOS bindings hard coded...
To me Ctrl+A was always "Select All", and it worked reliably on every system I had (except once when at my office I had a computer with unix bindings and the administrator told me he can't change them so I only used my laptop).
It’s an OS level thing (well, OS + standard widget library). As long as the app is using a native macOS text field, the OS has (and has since I think the first versions of osx) support for basic emacs movement keys, no extra effort on the app developers part.
> because linux never picks the correct method
Because linux is not an operating system. A specific operating system will have some specific behaviour.
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.
It's the Carret Notation: https://en.wikipedia.org/wiki/Caret_notation
That's because C-J IS ANSI Carriage Return. It's basically the absence of any special treatment.
In fact, without some fairly new (and poorly supported) extensions, it's impossible for an application running in a terminal to distinguish between ^J and a "real" press of the return key. The same goes for tab vs. ^I, Esc vs. ^[, and so on.
You meant ASCII Line Feed, ne?
Yes, shame on me. Should have conducted ascii(7) before making bold statements.