Improve split pane close UX

[cmwetherell]

What do you want to change?

I'd like to make two small improvements to the split pane experience:

1. Add a "Close Pane" option to the right-click context menu (both macOS and GTK). Right now you can split from the menu but can't close from it.
2. Draw a subtle border around the focused pane when splits are active, so it's more obvious which one is selected.

I have a working implementation on a local branch already.

Why do you want to make this change?

I use splits a lot and I've accidentally closed the wrong pane with Cmd+W more than once. The unfocused dimming is easy to miss, especially with similar content in both panes. A visible border on the focused pane would make it obvious at a glance, and having "Close Pane" in the right-click menu gives you a way to close a specific pane without worrying about which one has focus.

AI disclosure: I used Claude Code to help with planning and writing the implementation. I've reviewed and understand all the changes.

I acknowledge that:

• I have read the Contributing Guide and understand the contribution process.
• I have read and agree to follow the AI Usage Policy.
• I wrote this vouch request myself, in my own voice, without AI generating it.

[cmwetherell]

👋

[pluiedev]

I'm on board with the first change (on GTK you can just add the close split action within the "Split" submenu) but the second change needs more elaboration. Show your code if you have it.

[cmwetherell]

Thanks for the feedback! I'll drop the focused-split border for now and make that a separate PR if there's interest.

Here's a breakdown of the "Close Split" context menu changes:

GTK

surface.blp — Adds "Close Split" at the bottom of the existing "Split" submenu, right after the directional split options:

item {
  label: _("Close Split");
  action: "split-tree.close-split";
}

split_tree.zig — Registers the close-split action alongside the existing split actions and wires it to surface.close():

pub fn actionCloseSplit(
    _: *gio.SimpleAction,
    _: ?*glib.Variant,
    self: *Self,
) callconv(.c) void {
    const surface = self.getActiveSurface() orelse return;
    surface.close();
}

macOS

SurfaceView_AppKit.swift — Adds "Close Split" to the right-click menu after the split direction options, with a separator:

menu.addItem(.separator())
item = menu.addItem(withTitle: "Close Split",
                    action: #selector(closeSurface(_:)),
                    keyEquivalent: "")
item.setImageIfDesired(systemSymbolName: "xmark.rectangle")

The action reuses the existing close_surface binding action:

@IBAction func closeSurface(_ sender: Any?) {
    guard let surface = self.surface else { return }
    let action = "close_surface"
    if !ghostty_surface_binding_action(surface, action,
            UInt(action.lengthOfBytes(using: .utf8))) {
        AppDelegate.logger.warning("action failed action=\(action)")
    }
}

• Both platforms follow existing patterns — GTK reuses the split-tree action group and surface.close(), macOS reuses ghostty_surface_binding_action with close_surface (same path as the keybinding)
• No new dependencies or config options needed
• The menu item sits naturally inside the existing "Split" submenu (GTK) / after the split options (macOS)

[jcollie]

"Close Pane" → "Close Split". "Pane" is not a term we've ever used and we don't want to confuse people.

[cmwetherell]

That makes sense. I edited the post, and will make that change in my code before submitting a PR.

[cmwetherell]

@jcollie @pluiedev can one of you !vouch so I can submit the PR?

[jcollie]

!vouch

[jcollie]

FYI, it might be better to split the PR into two, one for the GTK changes and one for the macOS changes. Also, this won't be in 1.3 since it's adding strings.

[cmwetherell]

Thats good to know. I'm working on the PRs now - will 'split' and submit both today.

[roja]

Strong +1 on the macOS "Close Split" menu item, from a discoverability angle rather than just convenience.

Hit this today: one of my splits (running a full-screen TUI) blanked out entirely — empty pane, just a hollow cursor rectangle in the top-left corner, completely unresponsive. Looks like the surface stops repainting (#11435 looks like the same thing). Right-click → "Reset terminal" did nothing (wrong lever — it resets terminal state, not the renderer). The repaint tricks didn't recover it either: toggle split zoom, toggle fullscreen, and resizing the split all left it blank.

What actually fixed it was Cmd+W to close just that one surface, then re-splitting — window and other splits untouched. Exactly the outcome this request is about.

The reason a menu item matters here: when a split looks dead, the instinct is to right-click on it, because keyboard focus feels unreliable when the pane appears frozen. But the context menu offers "Split" and no way to close, so the natural read is "I have to close the whole window." A "Close Split" entry in that menu would surface the recovery at exactly the moment people are stuck and reaching for the mouse. It's arguably most valuable precisely when a split is misbehaving.