mirror of
https://github.com/ghostty-org/ghostty.git
synced 2026-04-14 19:45:49 +00:00
608d312651
This adds support for the `OSC 133 A click_events=1` extension introduced by Kitty and supported by Fish.[^1] **What this means:** If the shell advertises `click_events=1` support, Ghostty will _unconditionally_ (no modifier required) send mouse events to the shell for clicks on a prompt line, delegating to the supporting shell to move the cursor as needed. For Fish 4.1+ this means that clicking on the prompt line moves the cursor (see demo video below). This PR also contains: * A minor fix in `cl` parsing but we don't yet implement the logic there * Updated inspector to show the semantic prompt click mode ## Demo https://github.com/user-attachments/assets/03ef8975-7ad9-441f-aaa2-9d0eb5c5e36d ## Implementation Details `click_events` is wildly underspecified, so here are the details the best I understand them. This itself is not a specification (I omit details) but adds some more context to it. The `click_events=1` option can be specified with `OSC 133 A` (Ghostty also allows it on OSC 133 N). When that is specified, it flags for all future prompts that the screen supports click events for semantic prompts. If both `click_events` and `cl` are specified, `click_events` takes priority if true. If `click_events=0` (disable), then any set `cl` will take priority. When a mouse click comes in, we check for the following conditions: 1. The screen supports click events 2. The screen cursor is currently at a prompt 3. The mouse click was at or below the starting prompt line of the current prompt If those are met, we encode an SGR mouse event with: left button, press, coordinates of click. It is up to the shell after that to handle it. Out of prompt bounds SGR events are possible (specifically below). The shell should robustly handle this. [^1]: I don't know any other terminal or shell that supports it at the moment.