mjhjmtu

I need to troubleshoot why typing in some unicode characters in my terminal won’t work.

I use a non-qwerty keyboard layout (namely neo) which allows me to directly type in unicode characters such as α β γ δ … ∀ ∃ … ∘ ⇒ ⇔, which works just fine for most applications.

However with terminals such as rxvt-unicode or xterm, typing in the characters ∘ and ⇔ does nothing – although the characters are displayed perfectly well when I copy-paste them.

Information on the specific characters and keys which don’t work:

• 
  ⇔: hex code 0x21D4; neo-sequence: Capslock + AltGr + m
  


• 
  ∘: hex code: 0x2218; neo-sequence: Capslock + AltGr + [
  

Other characters typed in via Capslock + AltGr + ⟨some key⟩, for instance ⇒, also work without problem on my terminal. This baffles me.

So does anyone know where the problem might lie here? Does anyone have a clue where to look?

I use Parabola GNU/Linux (which is basically Arch Linux).

Okay, I at least found a work-around now.

It turns out the problem is that ifonlyif and jot do not seem to be recognised by xmodmap as keysymnames. They are used in my configuration.

$ 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

If one replaces them by their unicode hex codes, all works well. So I just did:

$ 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

In case this might be helpful for others, I came to this by the following: I observed the xev output for trying to type in ⇔ (ifonlyif) and ∘ (jot) respectively.

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

In contrast, typing in other, working characters (Θ, ⇒) give lines such as:

…
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) "⇒"

So I knew the problem possibly was XLookupString failing to return anything. So I did man xlookupstring and man xmodmap. Then I investigated the xmodmap table xmodmap -pke and compared the failing lookup of ifonlyif as ⇔ with the successfull lookup of U21D2 as ⇒.