bug#37530: 26.1; Tack characters translated incorrectly

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Isn't the output of "C-h l" evidence that Emacs actually received the
> codepoints it displayed?  IOW, how do we know this is a problem in
> Emacs and not in the keyboard configuration and/or driver software?

I've always wondered how Emacs actually does this thing, but have never
had a peek, so I rummaged around in keyboard.c for a bit.  If I'm
reading the code right, we get an event, and then pick out the
symbol_num from that (and that's probably they keycode in X parlance),
and then we end up here (under X):

/* Convert a keysym to its name.  */

char *
get_keysym_name (int keysym)
{
  char *value;

  block_input ();
  value = XKeysymToString (keysym);
  unblock_input ();

  return value;
}

But I'm a bit lost in how that name is translated into a character.
Uhm...  OK, there's a hash table called x-keysym-table.

(format "%x" (gethash #x0bc2 x-keysym-table))
=> "22a5"

> > #define XKB_KEY_downtack                      0x0bc2  /* U+22A4 DOWN TACK */
> > #define XKB_KEY_uptack                        0x0bce  /* U+22A5 UP TACK */
> > #define XKB_KEY_lefttack                      0x0bdc  /* U+22A3 LEFT TACK */
> > #define XKB_KEY_righttack 0x0bfc /* U+22A2 RIGHT TACK */

And that's wrong, according to the bug reporter.  Now where does that
come from?  Some grepping shows w-win.el:

;; Table from Kuhn's proposed additions to the `KEYSYM Encoding'
;; appendix to the X protocol definition.
(dolist
...
        (#xbc2 . ?⊥)

Oh, there it is.

Character code properties: customize what to show
  name: UP TACK
  general-category: Sm (Symbol, Math)
  decomposition: (8869) ('⊥')

So we've got some wrong data in x-win.el?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no