Allow copy/paste keybindings to pass through if they did nothing

[hatch01]

I really like to use the natural ctrl+c and ctrl+v to copy in a terminal.

For ctrl+c :
In Konsole, this can be done pretty elegantly because if I map ctrl+c to copy, it copies only if I have something selected.
If nothing is selected, it sends the classical sigint.

For ctrl+v
I did not have any solution in konsole and was unable to use the vim visual selection, but I just used my mouse with nvim.
So for this shortcut, I think that there is no big deal.

[mitchellh]

This would be pretty easy to support for Ghostty, we already have the unconsumed: modifier on keybindings and could extend that to copy/paste very easily.

I'd just like to repeat so I understand what you're asking: you want copy/paste but if they do nothing (i.e. the clipboard is empty) then you want them to encode the key and pass it on to the pty?

[mitchellh]

Approved #4328

[hatch01]

Yes, you are right, you've understood exactly what I want.
Would love to see it in ghostty.

[mitchellh]

I've converted this to a discussion because actually I think we need to think about this a bit more. I'm very supportive of making this work, but I realized there's a central issue in the way keybindings work in Ghostty:

We already know if an action was performed. We use this to pass through some keys already. But the keybindings are either always passthrough or always not on performed. What this issue is asking for is a conditional way to do that.

The easy thing to do would be to make a new keybinding action like copy_if_nonempty (and likewise for paste). If we decide that's the right way to do it that's fine.

I want to consider introducing a new keybinding syntax so that we can generalize this to the behavior of "consume only if performed." This is missing today and it'd be possible for us to generalize.

[rafikdraoui]

a new keybinding action like copy_if_nonempty

Kitty has a copy_or_interrupt action to "copy the selected text from the active window to the clipboard, if no selection, send SIGINT": https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_interrupt

For pasting, I'm not sure how useful this would be, because unless the clipboard is explicitly cleared, in my experience there is always something already in the clipboard from a previous copy action.

for ctrl+v I did not have any solution and was unable to use the vim visual selection

In Vim, you can use ctrl-q instead of ctrl-v. This works in normal mode for visual selection, and in insert and command mode to insert special characters.

Another idea is to swap ctrl-v and ctrl-shift-v in your Ghostty config: ctrl-v could be bound to "paste", and ctrl-shift-v bound to "send literal ctrl-v", and then you could use ctrl-shift-v for visual selection in Vim.

[BarbUk]

I really like to use the natural ctrl+c and ctrl+v to copy in a terminal.

+1

The main way I use this is with a smart copy feature, CTRL+C will copy the selected text if there are any and clear the current selection, or send ^C if no selection.

I use this with wezterm to handle copy when there is some selection:
https://github.com/BarbUk/dotfiles/blob/master/apps/wezterm/wezterm.lua#L29-L48

In termite, this is implemented like that:
https://github.com/aperezdc/termite/blob/3d63314a6d5e4c214ec3d2b3cd6e1307eeb0a02d/termite.cc#L1147-L1150

In kitty:
https://sw.kovidgoyal.net/kitty/actions/#action-copy_or_interrupt

[haydonryan]

I came here looking for a way to just swap ctrl-c and ctrl-shift-c.

Love the idea of a smart ctrl+c - would love to see this in ghostty

[skaphi]

I completely agree. Smart ctrl-c is one of few things that Microsoft has done a much better job with for Windows terminal, than for any of the Linux terminals. I personally think that is the default way that all terminals should behave, but would probably be too much of a norm-breaker.

I think we need a new meme for the default though! ctrl-shift-c-ctr-shift-v-ringfinger!

[Majoramari]

I like the way kitty handle it with copy_or_interrupt I guess its the way to go

[IrishBruse]

Made a mockup PR for an action similar to copy_or_interrupt from kitty I feel like its a common use case for people coming from windows terminals and kitty #3970

[glenni83]

Yes, this is a must for me as well. An easy way to set ctrl+c ctrl+v. Or else I prolly wont be using Ghostty in the future, due its a deal breaking thing for me. Why I tend to use the Konsole instead.

Seems like there is a fix to? Or am I misstaken? Im not sure how you do this?

If someone can make me a small guide to do it. I would be verry happy.

[Majoramari]

There's no fix yet, but a pull request (#3970) has been opened to introduce the copy_or_interrupt action in Ghostty.

If it gets merged, you'll probably be able to add this line to your Ghostty config:

keybind = ctrl+c=copy_or_interrupt  

EDIT: It seems the maintainer decided to take a different approach and opened PR #4328. This introduces performable:, which adds functionality to check if an action is "performable." If not, it will fallback to an alternative action.

keybind = performable:ctrl+c=copy_to_clipboard

Also, note that Ctrl+V for pasting is already working, so there's no need to wait for that. Just add:

keybind = ctrl+v=paste_from_clipboard  

[Amir-Ahmad]

I'm trying out the new performable prefix to use Ctrl+C for both copy and SIGINT, but am having trouble getting SIGINT working.

I've added this to my config:

keybind = performable:ctrl+c=copy_to_clipboard

While ctrl+C correctly only copies when text is highlighted, SIGINT never seems to get sent. I'm testing with sleep 100 and then pressing Ctrl+C. Nothing happens.

This is on fedora 40 with gnome and wayland. version:

Version
  - version: 1.0.1-1+20250107.003840.a3837a1e4ee06a183f32d4a622c2cdcd51f73fb8.fc40
  - channel: tip
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - desktop env: gnome
  - GTK version:
    build      : 4.14.5
    runtime    : 4.14.5
  - libadwaita : enabled
    build      : 1.5.5
    runtime    : 1.5.3
  - libX11     : enabled
  - libwayland : enabled

Is this working for anyone else?

[rinormaloku]

It isn't working for me either. Added a comment to the issue linked as an answer

[Majoramari]

Did you build it from source? as far as I know this PR merged but not released yet and planned to be out in 1.1.0.

[codeknight03]

I have build it from source but this does not work for me either. This is on PopOs 22.04.

info: ghostty version=1.0.2-main+72d08552
info: ghostty build optimize=ReleaseFast
info: runtime=apprt.Runtime.gtk
info: font_backend=font.main.Backend.fontconfig_freetype
info: dependency harfbuzz=8.4.0
info: dependency fontconfig=21402
info: renderer=renderer.OpenGL
info: libxev backend=main.Backend.io_uring
info(os): setlocale from env result=en_US.UTF-8
info(gtk): GTK version build=4.6.9 runtime=4.6.9
info: reading configuration file path=/home/codeknight03/.config/ghostty/config
info(config): default shell source=env value=/bin/bash
warning(gtk): configuration error: cli:1:version: invalid field
warning(gtk): CLI errors detected, exiting

[rinormaloku]

This was already pointed out by mitchellh that this is an issue.

[tarikkirgin]

Coming from kitty, I had copy_or_interrupt bound to Command + c. I'm not sure how to replicate this using performable: as understandably Command + c does not trigger the interrupt functionality even if sent through.

[tarikkirgin]

unfortunately not, doesn't look like this functionality is possible within the current way of doing things

[z0al]

@mitchellh would you accept a PR to implement a copy_or_interrupt-style command?

The current performable-based system limits the "smart copy" binding to ctrl+c by design as stated above :/

[00-kat]

I tried the following to no avail.

This wouldn't work, since the second one overwrites the first one; it would need something like #3175.

[eddy-geek]

It's quite specific to my workflow , but what I did for macOS was:

• keep the normal (Linux) ghostty binding : keybind = performable:ctrl+c=copy_to_clipboard
• using hammerspoon, swap cmd and ctrl for some keys only , and only in ghostty
  the rough idea is here :

local eventtap = hs.eventtap
local eventTypes = eventtap.event.types
local keycodes = hs.keycodes.map

-- Per-app: treat ⌘ as ⌃ in Terminal/iTerm for letters (so Cmd works as Ctrl)
local TERMINAL_BUNDLES = {
  ["com.apple.Terminal"] = true,
  ["com.googlecode.iterm2"] = true,
  ["com.iterm2"] = true,
  ["com.mitchellh.ghostty"] = true,
}

-- In Terminal, keep native ⌘ behavior for these letters (lowercase)
-- User's keep list: F H J M O Q T V W
local TERMINAL_CMD_KEEP = { f = true, h = true, j = true, m = true, o = true, q = true, t = true, v = true, w = true }

local function keyRemapper(event)
  local keyCode = event:getKeyCode()
  local flags = event:getFlags()

  -- This is a guard clause: if no modifiers are held, do nothing.
  -- This prevents the script from analyzing every single key press.
  if not flags.cmd and not flags.alt and not flags.ctrl and not flags.fn then
    return false
  end

  -- Terminal/iTerm: map Cmd+[a-z] to Ctrl+[a-z] (except keep list) so Cmd acts as Ctrl in Terminal.
  -- Preserve Shift/Alt; emit synthetic keystroke and temporarily disable hs.hotkey
  -- to prevent your Ctrl-based global focus bindings from firing.
  do
    local front = hs.application.frontmostApplication()
    local bid = front and front:bundleID() or nil
    if bid and TERMINAL_BUNDLES[bid] and flags.cmd and not flags.shift and not flags.alt then
      local ch = event:getCharacters(true) -- lowercase letter without modifiers
      if ch and ch:match("^[a-z]$") and not TERMINAL_CMD_KEEP[ch] then
        print ("Force Send ctrl + " .. ch .. " in Terminal")
        local mods = { "ctrl" }
        -- Consume original and send synthetic Ctrl+[letter]
        hs.eventtap.keyStroke(mods, ch, 0, front)
        return true  -- Consume the event
      end
    end
  end
  -- For any other key combination, do not interfere.
  return false
end

[ArcticLampyrid]

This wouldn't work, since the second one overwrites the first one; it would need something like #3175.

It seems that #3175 is being used to discuss chained requests. Have we made any progress on A or B logic?

[w-jablonski]

I think it would be useful to also clear selection on copy. Otherwise, the selection consumes ctrl+c forever, while being useless. 👍

[jakubklos77]

I agree completely

[rhodes-b]

good thing it already exists
https://ghostty.org/docs/config/reference#selection-clear-on-copy

also for the future please dont comment on a post that is already closed and very old

[gitmpr]

Hit this specific case: stacking performable: over the implicit default so one key handles both URL-copy and regular selection-copy:

keybind = performable:ctrl+shift+c=copy_url_to_clipboard

On GTK/Linux (Ghostty 1.3.2-dev tip, GNOME/Wayland), when no URL is hovered the action correctly reports as not-performable, but the fallthrough to the compiled-in default copy_to_clipboard binding does not fire - the keypress just clears the selection instead of copying it. Confirmed via isolation: removing the performable: line entirely restores plain ctrl+shift+c copy immediately, so it is specifically the fallthrough-to-implicit-default path that is broken, not clipboard access generally.

Matches what is noted above about needing OR/AND keybind logic (#3175) to reliably stack performable actions on one key. Working around it for now by dropping performable: here and picking a separate key for URL copying.

Edit: followed up on this further. The copy_url_to_clipboard action itself is not broken - it works fine when bound on its own dedicated key. The real issue is specific to sharing one trigger between a performable and a non-performable binding: copy_to_clipboard is also a GTK context-menu item, so a non-performable binding for it gets registered as a GTK menu accelerator and fires via the performBinding fast path, bypassing the normal Surface.keyCallback pipeline that would otherwise let a performable sibling on the same key take priority when applicable. In practice this means whenever a plain copy_to_clipboard binding exists on a key, it always wins over a performable: sibling on that same key, regardless of which is declared first (verified live in both orders).

Also worth correcting: declaring a single performable: binding alone for a trigger does not fall back to Ghosttys own compiled-in default action either - a user config declaration fully replaces the default for that trigger rather than layering under it, so there is nothing left to fall through to.

Ended up giving up on one-key dual use and just splitting it across two keys instead, which works reliably:

keybind = ctrl+shift+c=copy_to_clipboard
keybind = performable:ctrl+shift+y=copy_url_to_clipboard