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.

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.

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).

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...

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.

It’s always bugged me that Ctrl+M should be what’s carriage-returning the cursor (and Ctrl+J to submit).

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.

You meant ASCII Line Feed, ne?

Yes, shame on me. Should have conducted ascii(7) before making bold statements.

       Oct   Dec   Hex   Char                        Oct   Dec   Hex   Char
       ────────────────────────────────────────────────────────────────────────
       000   0     00    NUL '\0' (null character)   100   64    40    @
       001   1     01    SOH (start of heading)      101   65    41    A
       002   2     02    STX (start of text)         102   66    42    B
       003   3     03    ETX (end of text)           103   67    43    C
       004   4     04    EOT (end of transmission)   104   68    44    D
       005   5     05    ENQ (enquiry)               105   69    45    E
       006   6     06    ACK (acknowledge)           106   70    46    F
       007   7     07    BEL '\a' (bell)             107   71    47    G
       010   8     08    BS  '\b' (backspace)        110   72    48    H
       011   9     09    HT  '\t' (horizontal tab)   111   73    49    I
       012   10    0A    LF  '\n' (new line)         112   74    4A    J
       013   11    0B    VT  '\v' (vertical tab)     113   75    4B    K
       014   12    0C    FF  '\f' (form feed)        114   76    4C    L
       015   13    0D    CR  '\r' (carriage ret)     115   77    4D    M

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.

Claude Code does distinguish between the two. Pressing the Enter key submits the query, pressing ^J inserts a newline.

That's maybe, because (I was wrong and) it's LF, but pressing return produces CR, which is differentiable by an application.

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

> because linux never picks the correct method

Because linux is not an operating system. A specific operating system will have some specific behaviour.