bug#37530: 26.1; Tack characters translated incorrectly

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Axel Svensson <mail@axelsvensson.com>,  37530@debbugs.gnu.org
> Date: Fri, 27 Sep 2019 15:32:30 +0200
> 
> The following patch updates out map with the data from the .h file:
> 
> (setq map
>       (let ((map nil))
> 	(with-temp-buffer
> 	  (insert-file-contents "/usr/include/xkbcommon/xkbcommon-keysyms.h")
> 	  (while (re-search-forward "#define +XKB_KEY.*0x\\([a-fA-Z0-9]+\\).*U\\+\\([a-fA-Z0-9]+\\)" nil t)
> 	    (push (cons (string-to-number (match-string 1) 16)
> 			(string-to-number (match-string 2) 16))
> 		  map)))
> 	(nreverse map)))
> 
> Does this look OK to everybody?

Sorry, this is not enough.  We cannot blindly use some alternative
source, especially as the other source was determined to be
inaccurate.  How do we know that header file is accurate?  (And what
is the license of that file, btw?)

I'd like someone to do the research and find out why Markus Kuhn's
suggestions were changed.  I'd like also to state the source of the
data and the information about the change reason(s) in x-win.el, where
we have the mapping.

> In addition, there's a huge number of keysyms in that file that we do
> not do mappings to characters for.  Hm...  but those are all over
> #x1000174, so I guess they're mapped to Unicode code points directly?
> 
> 	  /* Keysyms directly mapped to Unicode characters.  */
> 	  if (keysym >= 0x01000000 && keysym <= 0x0110FFFF)

To answer the question, one needs to compare the keysyms with the
corresponding codepoints.  If they are identical, then the mapping is
trivial.

Thanks.