How to change Paste hotkey?

[sosokun]

I want to use shift+Insert for Paste. In Oryxiss shortcuts I see this hotkey is handled by the terminal widget. Where should I change it?

[wilsonglasser]

@sosokun Today is not possible to modify the paste key directly, I can add the paste to hotkeys, the problem with Paste is the multiple modifiers related to it, what I can do is add the variantion too.

[wilsonglasser]

Following up on my earlier answer with a concrete plan: I opened #75 to track this.

Short version: you are right that this should be configurable, and it turned out to be cheaper than I first thought. The hotkey system in Settings > Shortcuts is already fully rebindable with conflict resolution and persistence, and it already accepts Insert as a key. The clipboard chords are simply the last interactive keys in the app that were never wired into it, so Shift+Insert has nothing to bind to. Adding TerminalCopy / TerminalPaste / TerminalSelectAll as proper actions closes that gap, and your request becomes a normal rebind in the Settings panel.

While tracing it I found a related bug worth fixing in the same change. Right now any Ctrl+V is turned into a paste before the byte reaches the PTY, so the literal ^V never gets through. That silently breaks vim's visual block mode, readline's quoted-insert at a shell prompt, and nano's ^V page-down, with no way to opt out. The convention in gnome-terminal, konsole and xterm is Ctrl+Shift+V for paste and plain Ctrl+V passed through as ^V, Oryxis is the odd one out here, and restoring that default fixes all three for free.

On the "multiple modifiers" concern I raised earlier: the answer is that paste keeps several chords rather than exactly one. The open question in #75 is whether to give every action an optional secondary binding slot, or to model paste as a pair of actions. Either way, binding Shift+Insert to paste will not cost you Ctrl+Shift+V.

I also considered detecting the foreground app so Ctrl+V could paste at a shell prompt but send ^V inside vim, and rejected it, the reasoning is recorded in #75 so it does not get re-proposed. The short of it: every available signal fails (alternate-screen detection breaks tmux users who are at a shell prompt, and vim enables bracketed paste just like the shell does), and a paste is irreversible, so guessing wrong pastes into a running program. A chord that always does the same thing beats a clever one.

No ETA yet, but it is tracked and scoped. Thanks for the report.