Skip to content

Option is not Meta on macOS, so Option+b and Option+f type ∫ and ƒ #63

Description

@karngyan

What happens

On a Mac, Option+letter in the browser terminal produces the character macOS puts on that key — , ƒ, ¬ — rather than a Meta-prefixed byte. So the readline word motions everyone uses (Option+B, Option+F, Option+Backspace) do nothing but insert glyphs, and every Meta binding in an agent CLI, tmux or emacs is out of reach.

Option+Enter is unaffected and already sends ESC CR — xterm's third-level-shift rule excludes keycodes at or below 47, and Enter is 13.

Why

macOptionIsMeta defaults to false, and with it off xterm treats Option+key as a third-level shift: the key event is handed back to the browser, whose composed character arrives through the input event.

This is the same setting claude /terminal-setup turns on elsewhere — it sets useOptionAsMetaKey on the Terminal.app profile, and iTerm2's equivalent is "Left Option key: Esc+".

Shape of a fix

macOptionIsMeta: true in web/src/emulator/xterm.ts, next to the other Terminal options.

The cost is real and is why this is not a one-liner to be merged without a decision: it takes away typing é, ü and on a Mac keyboard, for everyone, permanently. A terminal is a place where Meta is worth more than an em dash, which is why every native terminal offers the switch — but flue would be choosing for the user rather than offering it.

So the question to settle first is whether this is a setting on the Settings screen (per browser, alongside the theme preference, which already has the storage and the cross-tab sync to copy) or a default with no way back.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions