Isso está "parcialmente lá", mas se depara com o problema de que não há nenhum caractere predefinido (byte único) correspondente a control + shift + C ou control + shift + V. Você precisa desse caractere de byte único para a configuração de interrupção ( intr
) com stty
. Da mesma forma, control + V é a próxima configuração literal ( lnext
) em stty
.
Você pode usar o recurso de tradução para enviar um caractere de controle + C usando o recurso string
, por exemplo, algo como essas linhas em um recurso translations
:
ctrl shift <key>C : string(0x03) \n\
ctrl shift <key>V : string(0x16) \n\
e, em seguida, atribua as chaves não deslocadas (colocando um til ~
antes da palavra-chave 'shift).
A partir do comentário subsequente, concordo que apenas especificar o padrão alterado un deve ser suficiente:
~Shift Ctrl <KeyPress> v: insert-selection(CLIPBOARD)\n\
~Shift Ctrl <KeyPress> c: copy-selection(CLIPBOARD)\n
algumas notas (que podem ser documentadas, mas o código-fonte ajuda):
-
<KeyPress>
significa o mesmo que<Key>
- os modificadores (e
<KeyPress>
) são correspondidos ignorando maiúsculas e minúsculas. - as partes do lado direito de
:
diferenciam maiúsculas de minúsculas.
Normalmente, não há tradução feita para o controle / C com ou sem o modificador de deslocamento. O xterm simplesmente obtém um XKeyEvent
que tem as informações do modificador e o caractere, e decodifica esse . O recurso translations
altera os eventos que podem ser enviados para o xterm.
Você usaria modificadores em uma tradução para limitar as correspondências, por exemplo, omitir shift significa que ele corresponde à tecla shift pressionada ou não. Adicionar um modificador ~shift
( não deslocamento) explícito não afeta a correspondência para shift
.
Leitura adicional:
- Ligações de chaves personalizadas (manual do xterm)