bug#34215: 27.0.50; Provide elisp access to Chinese pinyin-to-character mapping

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Sat, 26 Jan 2019 21:34:39 -0800
>> 
>> So this proposed patch simply parses the same file in the same way, but
>> in a different location. I've put it in china-util.el, but chinese.el
>> would also be a reasonable spot. Both those files are concerned with
>> encoding, but at least "china-util" gives the impression that it could
>> be a grab-bag.
>
> How much does this add to Emacs memory footprint when loaded?  

I actually don't know how to measure the memory taken up by the contents
of a variable, but I imagine it's fairly significant. Or maybe I could
do a "before and after" measurement of all of Emacs.

> Since this will be required only rarely, I doubt that it would be a
> good idea to force every user of Chinese language to pay the price, if
> it is significant. It would be better to have this as a separate file
> with autoloaded variable or function, IMO.

That sounds fine to me. I agree the data shouldn't be loaded unless it's
been explicitly requested.

>> I'm not sure this use of `source-directory' is particularly robust, but
>> I don't know how else to handle it.
>
> source-directory might not exist in a given installation.
>
> Maybe we should have the data copied into that separate file I
> mentioned above.

I can imagine a few ways of doing that:

1. Just manually copy the data into a new file and add it to the repo
   (pinyin.map hasn't been updated in years).
2. Do the copy at build time. I'm not quite sure where that function
   would live, or how it would get called.
3. Use an `eval-and-compile' form as in the patch I provided. Is working
   back from `load-file-name' more reliable than using
   `source-directory'?

Autoloading a variable seems to copy the value of the variable into the
loaddefs file, so there's no point to that. I figure we can just ask
people who want this value to require the library.

Thanks,
Eric

PS: pinyin.map is ancient and is missing a lot of good correspondences.
Google's pinyin input method uses a much larger map, licensed with
Apache v2.0. This[1] seems to indicate that Apache 2.0 is okay for Gnu
projects, maybe we could consider switching to that map?

Footnotes:
[1]  https://www.gnu.org/licenses/license-list.en.html#apache2