That's "partially there", but runs into the problem that there is no predefined (single byte) character corresponding to Ctrl+Shift+C or Ctrl+Shift+V. You need that single byte character for the interrupt (
intr) setting with
stty. Likewise, control+V is the literal next (
lnext) setting in
You could use the translation resource to send a Ctrl+C character using the
string feature, e.g., something like these lines in a
ctrl shift <key>C : string(0x03) \n\
ctrl shift <key>V : string(0x16) \n\
and then assign the unshifted keys (putting a tilde
~ before the `shift keyword).
From the followup comment, I agree that just specifying the unshifted pattern should be enough:
~Shift Ctrl <KeyPress> v: insert-selection(CLIPBOARD)\n\
~Shift Ctrl <KeyPress> c: copy-selection(CLIPBOARD)\n
a few notes (which might be documented, but the source code helps):
<KeyPress> means the same as
- the modifiers (and
<KeyPress>) are matched ignoring case.
- the parts on the right-side of
: are case-sensitive.
Normally there is no translation done for Ctrl+C with or without the shift-modifier. xterm simply gets an
XKeyEvent which has the modifier information and the character, and decodes that. The
translations resource alters the events which might be sent to xterm.
You would use modifiers in a translation to limit the matches, e.g., omitting Shift means it matches whether or not the shift-key is pressed. Adding an explicit
~shift (noshift) modifier has no effect on the match for