
Preciso solucionar por que digitar alguns caracteres Unicode em meu terminal não funciona.
Eu uso um layout de teclado não-qwerty (ou seja,neo), o que me permite digitar diretamente caracteres Unicode, como α β γ δ … ∀ ∃ … ∘ ⇒ ⇔
, o que funciona perfeitamente para a maioria dos aplicativos.
No entanto, com terminais como rxvt-unicode
ou xterm
, digitar os caracteres ∘
e ⇔
não faz nada –embora os personagens sejam exibidos perfeitamente bemquando eu os copio e colo.
Informações sobre os caracteres e teclas específicos que não funcionam:
⇔
: código hexadecimal0x21D4
; neo-sequência:Capslock + AltGr + m
∘
: código hexadecimal:0x2218
; neo-sequência:Capslock + AltGr + [
Outros caracteres digitados via Capslock + AltGr + ⟨some key⟩
, por exemplo ⇒
, também funcionam sem problemas no meu terminal. Isso me deixa perplexo.
Alguém sabe onde pode estar o problema aqui? Alguém tem alguma ideia de onde procurar?
Eu uso o Parabola GNU/Linux (que é basicamente Arch Linux).
Responder1
Ok, pelo menos encontrei uma solução alternativa agora.
Acontece que o problema é que ifonlyif
e jot
não parecem ser reconhecidos xmodmap
como nomes de teclas. Eles são usados na minha configuração.
$ xmodmap -pke | egrep "jot|ifonlyif"
keycode 34 = ssharp U1E9E ssharp U1E9E U017F Greek_finalsmallsigma U2212 NoSymbol jot NoSymbol U017F Greek_finalsmallsigma U2212 NoSymbol jot
keycode 58 = m M m M percent Greek_mu KP_1 KP_1 ifonlyif
Se alguém os substituir por seus códigos hexadecimais Unicode, tudo funcionará bem. Então eu acabei de fazer:
$ xmodmap -pke | sed -e 's:ifonlyif:U21D4:' -e 's:jot:U2218:' > .Xmodmap
$ xmodmap .Xmodmap
$ xmodmap -pke | egrep "keycode (34|58)"
keycode 34 = ssharp U1E9E ssharp U1E9E U017F Greek_finalsmallsigma U2212 NoSymbol U2218 NoSymbol U017F Greek_finalsmallsigma U2212
keycode 58 = m M m M percent Greek_mu KP_1 KP_1 U21D4
Caso isso possa ser útil para outras pessoas, cheguei a isso da seguinte maneira: observei a xev
saída ao tentar digitar ⇔
(ifonlyif) e ∘
(jot), respectivamente.
KeyPress event, serial 34, synthetic NO, window 0x2400001,
root 0x9b, subw 0x0, time 170075495, (1,1), root:(552,302),
state 0xa0, keycode 58 (keysym 0x8cd, ifonlyif), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x2400001,
root 0x9b, subw 0x0, time 170075574, (1,1), root:(552,302),
state 0xa0, keycode 58 (keysym 0x8cd, ifonlyif), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x2400001,
root 0x9b, subw 0x0, time 170076304, (1,1), root:(552,302),
state 0xa0, keycode 34 (keysym 0xbca, jot), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x2400001,
root 0x9b, subw 0x0, time 170076336, (1,1), root:(552,302),
state 0xa0, keycode 34 (keysym 0xbca, jot), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Por outro lado, digitar outros caracteres funcionais ( Θ
, ⇒
) fornece linhas como:
…
state 0xa0, keycode 61 (keysym 0x7c8, Greek_THETA), same_screen YES,
XLookupString gives 2 bytes: (ce 98) "Θ"
…
state 0xa0, keycode 59 (keysym 0x10021d2, U21D2), same_screen YES,
XLookupString gives 3 bytes: (e2 87 92) "⇒"
Então eu sabia que o problema possivelmente era XLookupString
não devolver nada. Então eu fiz man xlookupstring
e man xmodmap
. Em seguida, investiguei a tabela xmodmap xmodmap -pke
e comparei a pesquisa com falha de ifonlyif
as ⇔
com a pesquisa bem-sucedida de U21D2
as ⇒
.