Additional keysyms for AltGr keys #13

Display near-equivalent characters on keys which have dead_* characters which don't display.
The correct dead_* character is printed.

There are some keysyms I don't know how to enter into the keysymtab list.

For example, keysym 0x1000301 for the Ukrainian AltGr+<TLDE> key, the xev output being:

KeyPress event, serial 66, synthetic NO, window 0x3800001,
    root 0xa4, subw 0x0, time 6669891, (-360,546), root:(394,575),
    state 0x180, keycode 49 (keysym 0x1000301, U0301), same_screen YES,
    XLookupString gives 2 bytes: (cc 81) ""
    XmbLookupString gives 2 bytes: (cc 81) ""
    XFilterEvent returns: True

KeyRelease event, serial 66, synthetic NO, window 0x3800001,
    root 0xa4, subw 0x0, time 6669893, (-360,546), root:(394,575),
    state 0x180, keycode 49 (keysym 0x1000301, U0301), same_screen YES,
    XLookupString gives 2 bytes: (cc 81) ""
    XFilterEvent returns: False

It currently shows blank, with the assigned character being combining acute [U0301].
Keying e+AltGr+<TLDE> prints е́ ok

And a similar issue with 'keysym 0xffffff, VoidSymbol' for the Turkish keyboard.

Is there any way to enter these keysyms into the keysymtab list?

Thanks @Ray-V, PR is good and merged already.

Regarding your questions:

you can see in the code that 0x01xxxxxx codes are not searched in the keysymtab array. I have no idea if that code is correct/required. If it is and we need to handle special cases, we have two ways.

a. we add an if() for the special case, which I don't really recommend
b. we move the search through the keysymtab array before line 849 and add the special cases in the array. In this case we can easily handle special cases without adding a multitude of if() cases.
We will need to change "unsigned short" to unsigned int" or "long" in the keysymtab array to handle 32bits values. I suggest something like:

struct codepair {
  Keysym keysym;
  unsigned long ucs;
} keysymtab[] { ... }

unsigned long keysym2ucs(KeySym keysym) { ... }

The solution b. above should be able to handle also the case for the Turkinsh void symbol.

What do you think?

What do you think?

I've set up PR#14 to cover this.