Progress towards universal Copy/Paste shortcuts on Linux

Original Article ↗ Hacker News Discussion ↗

Apple Cmd vs Ctrl and OS-level roles

  • Several comments praise Apple’s separation: Cmd for GUI shortcuts, Ctrl preserved for terminal control codes, reducing clashes like Ctrl‑C (copy) vs SIGINT.
  • Others find switching between macOS (Cmd) and Linux/Windows (Ctrl) infuriating for muscle memory.
  • Some argue the “OS key” (Win/Super/Cmd) should consistently handle OS‑ or system‑wide actions (copy/paste, window switching), leaving Ctrl/Alt to applications; others reply Ctrl is the only “non‑modal” safe modifier and shouldn’t be demoted.
  • Multiple posters emphasize that macOS shortcut behavior is actually messy: apps override bindings inconsistently, and rebinding can require app‑specific GUIs rather than centralized configuration.

Existing “universal” shortcuts and dedicated keycodes

  • Many point out long‑standing CUA shortcuts: Ctrl‑Insert (copy), Shift‑Insert (paste), Shift‑Del (cut), which often work across Windows and Linux, including terminals.
  • Objections: Insert is missing or hard to reach on many laptops, and usage is low, so they don’t feel universal.
  • Linux/X11 already defines dedicated keysyms (XF86Copy, XF86Paste, XF86Cut, XF86Undo); people bind these to keyboard or mouse buttons, or via tools like Toshy or wtype.
  • Skepticism that GTK/Qt adding support in 2025 will quickly yield universality, given legacy GTK2/Qt5 apps.

Terminals vs GUI and the learning curve

  • One camp says the difference is “just add Shift in terminals” and not a big deal; others insist this is one of the biggest everyday pain points and a major hurdle for beginners.
  • Educators report students perceive the terminal as a “different world” because copy/paste and text selection behave differently.
  • Historical arguments: terminals predate copy/paste and interpret Ctrl combos as ASCII control characters; changing that would fundamentally alter what a terminal is.
  • Some terminals and Emacs modes already implement context‑sensitive Ctrl‑C (copy if selection, SIGINT otherwise) as a compromise.

Multiple clipboards and X11 behavior

  • X11’s PRIMARY (select + middle‑click) vs CLIPBOARD (Ctrl‑C/V) model is defended as powerful: two buffers, delayed rendering, content negotiation, and workflows like “paste the same thing repeatedly while copying other text.”
  • Others see it as confusing “weird buffers” that increase cognitive load and inconsistency, especially with Vim registers and differing toolkit behavior.
  • Clipboard managers can unify buffers and provide history, but add configuration complexity.

Programmable hardware and remapping

  • Some embrace programmable keyboards/mice and layered layouts to implement universal copy/paste via XF86* keys and ergonomic layers, arguing it’s a big productivity and comfort win.
  • Others see hardware programming as unnecessary; keymaps should be handled in the OS, and proliferation of custom layouts risks fragmenting shortcuts and muscle memory further.

Broader UX and “year of the Linux desktop”

  • Thread repeatedly widens into a UX debate: Linux as a tinkerers’ ecosystem with powerful but inconsistent defaults vs Apple’s constrained but consistent approach.
  • Many agree: whatever the theoretical elegance of terminals or X11, inconsistent copy/paste across apps, terminals, and browsers remains a daily annoyance, and a “solved” universal behavior would be a strong quality‑of‑life improvement.