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: Sun, 27 Jan 2019 10:02:48 -0800
>> 
>> >> 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'?
>
> 2 is what I had in mind.  I don't think it matters where the code
> lives, it's small enough to not matter.  It would be called like the
> various *-convert functions we invoke at build time to build the
> dictionaries needed for CJK input methods, see the files in the leim/
> directory.

Okay, I'll put that together and add it to one of the Makefiles. I
suppose it could go in leim/Makefile.in, though it technically isn't
part of leim, and I was expecting the resulting file to go to
lisp/language/. But it would be convenient to put the generation
function in titdic-cnv.el.

>> 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.
>
> Right.
>
>> 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?
>
> Maybe.  Unfortunately, I don't know enough about these input methods
> to tell whether replacing the file is a good idea.  I wonder who can
> we ask about this.

It's more or less a drop-in replacement -- the format of the data would
be the same, only a bit more of it. I'm not sure who is "in charge" of
these files, though.

Eric