GNU bug report logs - #34862
27.0.50; Trying to update pinyin.map

Previous Next

Package: emacs;

Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>

Date: Thu, 14 Mar 2019 21:52:01 UTC

Severity: wishlist

Found in version 27.0.50

To reply to this bug, email your comments to 34862 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Thu, 14 Mar 2019 21:52:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eric Abrahamsen <eric <at> ericabrahamsen.net>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 14 Mar 2019 21:52:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Trying to update pinyin.map
Date: Thu, 14 Mar 2019 14:49:51 -0700
As discussed in bug#34215, I'm trying to update the
romanization-to-Chinese-character mapping in the
file ./leim/MISC-DIC/pinyin.map to use the more complete mapping
provided by the Google pinyin input method, licensed under Apache 2.0.
This expands the number of characters recognized by Emacs from around
7,000 to around 17,000. (And increases the size of the mapping file from
18K to 53K.)

I'm running into encoding problems when adding the new characters --
Emacs says some of the characters can't be written using the existing
coding system. The original file has an encoding cookie reading coding:
cn-gb-2312, and describing the coding system gives me:

chinese-iso-8bit-dos (alias: cn-gb-2312-dos euc-china-dos euc-cn-dos
  cn-gb-dos gb2312-dos)

The characters *can* be encoded using gb18030, and of course utf8. The
wikipedia page for gb18030 describes gb2312 as "legacy"[1], and says
gb18030 is a superset of 2312.

Is there any reason not to go straight to utf8 for this file? If that's
not okay, would gb18030 be acceptable?

Codepoint 23744 is an example of a character that can be encoded with
18030 but not 2312. It also exercises my font engine.

I have two other questions, about reducing vc churn, and how to insert
the license at the top of the file, but I figured I'd ask this first.

Thanks,
Eric

[1]  https://en.wikipedia.org/wiki/GB_18030





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Fri, 15 Mar 2019 05:04:02 GMT) Full text and rfc822 format available.

Message #8 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 34862 <at> debbugs.gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Fri, 15 Mar 2019 07:03:30 +0200
> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Date: Thu, 14 Mar 2019 14:49:51 -0700
> 
> 
> As discussed in bug#34215, I'm trying to update the
> romanization-to-Chinese-character mapping in the
> file ./leim/MISC-DIC/pinyin.map to use the more complete mapping
> provided by the Google pinyin input method, licensed under Apache 2.0.
> This expands the number of characters recognized by Emacs from around
> 7,000 to around 17,000. (And increases the size of the mapping file from
> 18K to 53K.)
> 
> I'm running into encoding problems when adding the new characters --
> Emacs says some of the characters can't be written using the existing
> coding system. The original file has an encoding cookie reading coding:
> cn-gb-2312, and describing the coding system gives me:
> 
> chinese-iso-8bit-dos (alias: cn-gb-2312-dos euc-china-dos euc-cn-dos
>   cn-gb-dos gb2312-dos)
> 
> The characters *can* be encoded using gb18030, and of course utf8. The
> wikipedia page for gb18030 describes gb2312 as "legacy"[1], and says
> gb18030 is a superset of 2312.
> 
> Is there any reason not to go straight to utf8 for this file? If that's
> not okay, would gb18030 be acceptable?

I'm not sure I understand the encoding of which file would you like to
change?  Could you please clarify?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Fri, 15 Mar 2019 05:59:02 GMT) Full text and rfc822 format available.

Message #11 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34862 <at> debbugs.gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Thu, 14 Mar 2019 22:58:14 -0700
On 03/15/19 07:03 AM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Date: Thu, 14 Mar 2019 14:49:51 -0700
>> 
>> 
>> As discussed in bug#34215, I'm trying to update the
>> romanization-to-Chinese-character mapping in the
>> file ./leim/MISC-DIC/pinyin.map to use the more complete mapping
>> provided by the Google pinyin input method, licensed under Apache 2.0.
>> This expands the number of characters recognized by Emacs from around
>> 7,000 to around 17,000. (And increases the size of the mapping file from
>> 18K to 53K.)
>> 
>> I'm running into encoding problems when adding the new characters --
>> Emacs says some of the characters can't be written using the existing
>> coding system. The original file has an encoding cookie reading coding:
>> cn-gb-2312, and describing the coding system gives me:
>> 
>> chinese-iso-8bit-dos (alias: cn-gb-2312-dos euc-china-dos euc-cn-dos
>>   cn-gb-dos gb2312-dos)
>> 
>> The characters *can* be encoded using gb18030, and of course utf8. The
>> wikipedia page for gb18030 describes gb2312 as "legacy"[1], and says
>> gb18030 is a superset of 2312.
>> 
>> Is there any reason not to go straight to utf8 for this file? If that's
>> not okay, would gb18030 be acceptable?
>
> I'm not sure I understand the encoding of which file would you like to
> change?  Could you please clarify?

Sorry, I'm trying to add more characters to ./leim/MISC-DIC/pinyin.map,
which is encoded as chinese-iso-8bit-dos, and it can't accept the new
characters with that current encoding. That's the file I'd like to
change.

Thanks,
Eric




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Fri, 15 Mar 2019 07:06:01 GMT) Full text and rfc822 format available.

Message #14 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 34862 <at> debbugs.gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Fri, 15 Mar 2019 09:04:54 +0200
> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: 34862 <at> debbugs.gnu.org
> Date: Thu, 14 Mar 2019 22:58:14 -0700
> 
> > I'm not sure I understand the encoding of which file would you like to
> > change?  Could you please clarify?
> 
> Sorry, I'm trying to add more characters to ./leim/MISC-DIC/pinyin.map,
> which is encoded as chinese-iso-8bit-dos, and it can't accept the new
> characters with that current encoding. That's the file I'd like to
> change.

That file is imported from an external source, isn't it?  Are you
saying we should stop synchronizing it with that source, and instead
fork it, maintain our own separate copy, and never resync with that
source again?  If so, then I see no reason not to recode it in UTF-8.

Btw, I understand that the Google pinyin method is Apache licensed,
but does this mean we can freely use its data for updating pinyin.map?
IANAL.  Could you perhaps describe how you intend to extract the data
from the Google input method for the purpose of updating our file?  I
think someone will have to audit that process for being legal and
compatible with both the Apache license and the GPL.

(Also, I'm somewhat surprised that gbk isn't capable of covering the
characters you want to add.  Or did you not try using it?)

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Fri, 15 Mar 2019 18:33:02 GMT) Full text and rfc822 format available.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Fri, 15 Mar 2019 11:31:40 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: 34862 <at> debbugs.gnu.org
>> Date: Thu, 14 Mar 2019 22:58:14 -0700
>> 
>> > I'm not sure I understand the encoding of which file would you like to
>> > change?  Could you please clarify?
>> 
>> Sorry, I'm trying to add more characters to ./leim/MISC-DIC/pinyin.map,
>> which is encoded as chinese-iso-8bit-dos, and it can't accept the new
>> characters with that current encoding. That's the file I'd like to
>> change.
>
> That file is imported from an external source, isn't it?  Are you
> saying we should stop synchronizing it with that source, and instead
> fork it, maintain our own separate copy, and never resync with that
> source again?  If so, then I see no reason not to recode it in UTF-8.

Near as I can tell that file was imported into Emacs in 2001 and not
touched since (apart from copyright and encoding stuff). The Debian
package from which it comes seems to have been orphaned in 2003[1]. So
there's not much to either synchronize or fork!

> Btw, I understand that the Google pinyin method is Apache licensed,
> but does this mean we can freely use its data for updating pinyin.map?
> IANAL.  Could you perhaps describe how you intend to extract the data
> from the Google input method for the purpose of updating our file?  I
> think someone will have to audit that process for being legal and
> compatible with both the Apache license and the GPL.

This[2] is the source file I used. I chopped off all the
multiple-character dictionary entries, and munged the remaining data
into the format we need. Ie, lines like this:

八 6677.54934466 0 ba
把 165484.231697 0 ba
吧 385205.434615 0 ba

Became this:

ba 吧把八

A straight rearrangement, with frequency of use translated into simple
ordering of the characters. While this is obviously pretty manual, and a
bit of work, a file like this really only needs to be updated every five
years or so -- if that. Whenever someone thinks of it.

Regarding the license, I'm even less of a lawyer than you, but these[3]
are the terms that cover this data.

> (Also, I'm somewhat surprised that gbk isn't capable of covering the
> characters you want to add.  Or did you not try using it?)

I did not try using it! Mostly because the error message suggested
gb18030 first. gbk also works. I don't have any opinion about encoding,
apart from assuming utf8 unless there's a good reason not to.

Thanks,
Eric

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189523;msg=18

[2]  https://android.googlesource.com/platform/packages/inputmethods/PinyinIME/+/refs/heads/master/jni/data/rawdict_utf16_65105_freq.txt

[3]  https://android.googlesource.com/platform/packages/inputmethods/PinyinIME/+/refs/heads/master/NOTICE






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Wed, 20 Mar 2019 09:46:01 GMT) Full text and rfc822 format available.

Message #20 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Richard Stallman <rms <at> gnu.org>
Cc: 34862 <at> debbugs.gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Wed, 20 Mar 2019 11:45:30 +0200
> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Date: Fri, 15 Mar 2019 11:31:40 -0700
> 
> > That file is imported from an external source, isn't it?  Are you
> > saying we should stop synchronizing it with that source, and instead
> > fork it, maintain our own separate copy, and never resync with that
> > source again?  If so, then I see no reason not to recode it in UTF-8.
> 
> Near as I can tell that file was imported into Emacs in 2001 and not
> touched since (apart from copyright and encoding stuff). The Debian
> package from which it comes seems to have been orphaned in 2003[1]. So
> there's not much to either synchronize or fork!

OK, sounds reasonable.

> > Btw, I understand that the Google pinyin method is Apache licensed,
> > but does this mean we can freely use its data for updating pinyin.map?
> > IANAL.  Could you perhaps describe how you intend to extract the data
> > from the Google input method for the purpose of updating our file?  I
> > think someone will have to audit that process for being legal and
> > compatible with both the Apache license and the GPL.
> 
> This[2] is the source file I used. I chopped off all the
> multiple-character dictionary entries, and munged the remaining data
> into the format we need. Ie, lines like this:
> 
> 八 6677.54934466 0 ba
> 把 165484.231697 0 ba
> 吧 385205.434615 0 ba
> 
> Became this:
> 
> ba 吧把八
> 
> A straight rearrangement, with frequency of use translated into simple
> ordering of the characters. While this is obviously pretty manual, and a
> bit of work, a file like this really only needs to be updated every five
> years or so -- if that. Whenever someone thinks of it.

I think this should be done with a script, and that script should be
in our repository.  The easiest kind of a script is a Lisp program, of
course, but we can also use other kinds, such as Awk scripts.

> Regarding the license, I'm even less of a lawyer than you, but these[3]
> are the terms that cover this data.

Richard, could you please look at that license and tell if we can use
this data file?

> > (Also, I'm somewhat surprised that gbk isn't capable of covering the
> > characters you want to add.  Or did you not try using it?)
> 
> I did not try using it! Mostly because the error message suggested
> gb18030 first. gbk also works. I don't have any opinion about encoding,
> apart from assuming utf8 unless there's a good reason not to.

I see no good reason to use anything other than UTF-8.

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189523;msg=18
> 
> [2]  https://android.googlesource.com/platform/packages/inputmethods/PinyinIME/+/refs/heads/master/jni/data/rawdict_utf16_65105_freq.txt
> 
> [3]  https://android.googlesource.com/platform/packages/inputmethods/PinyinIME/+/refs/heads/master/NOTICE

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Wed, 20 Mar 2019 19:31:02 GMT) Full text and rfc822 format available.

Message #23 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34862 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Wed, 20 Mar 2019 12:30:22 -0700
On 03/20/19 11:45 AM, Eli Zaretskii wrote:

[...]

>> > Btw, I understand that the Google pinyin method is Apache licensed,
>> > but does this mean we can freely use its data for updating pinyin.map?
>> > IANAL. Could you perhaps describe how you intend to extract the data
>> > from the Google input method for the purpose of updating our file? I
>> > think someone will have to audit that process for being legal and
>> > compatible with both the Apache license and the GPL.
>> 
>> This[2] is the source file I used. I chopped off all the
>> multiple-character dictionary entries, and munged the remaining data
>> into the format we need. Ie, lines like this:
>> 
>> 八 6677.54934466 0 ba
>> 把 165484.231697 0 ba
>> 吧 385205.434615 0 ba
>> 
>> Became this:
>> 
>> ba 吧把八
>> 
>> A straight rearrangement, with frequency of use translated into simple
>> ordering of the characters. While this is obviously pretty manual, and a
>> bit of work, a file like this really only needs to be updated every five
>> years or so -- if that. Whenever someone thinks of it.
>
> I think this should be done with a script, and that script should be
> in our repository.  The easiest kind of a script is a Lisp program, of
> course, but we can also use other kinds, such as Awk scripts.

Awk seems just right for the problem, but I haven't written much in it;
I did the original munging in elisp. Would this be a script written for
use with -batch and a custom make target? Or something to be loaded into
a running Emacs and called interactively? In either case, should it also
be responsible for downloading a recent copy of the source file, or
should that be done first, and the function pointed at the file?

>> Regarding the license, I'm even less of a lawyer than you, but these[3]
>> are the terms that cover this data.
>
> Richard, could you please look at that license and tell if we can use
> this data file?
>
>> > (Also, I'm somewhat surprised that gbk isn't capable of covering the
>> > characters you want to add.  Or did you not try using it?)
>> 
>> I did not try using it! Mostly because the error message suggested
>> gb18030 first. gbk also works. I don't have any opinion about encoding,
>> apart from assuming utf8 unless there's a good reason not to.
>
> I see no good reason to use anything other than UTF-8.

Excellent. I will think about the script, and look forward to word from
Richard.

Eric




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Wed, 20 Mar 2019 19:40:02 GMT) Full text and rfc822 format available.

Message #26 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 34862 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Wed, 20 Mar 2019 21:39:11 +0200
> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
> Cc: Richard Stallman <rms <at> gnu.org>,  34862 <at> debbugs.gnu.org
> Date: Wed, 20 Mar 2019 12:30:22 -0700
> 
> > I think this should be done with a script, and that script should be
> > in our repository.  The easiest kind of a script is a Lisp program, of
> > course, but we can also use other kinds, such as Awk scripts.
> 
> Awk seems just right for the problem, but I haven't written much in it;
> I did the original munging in elisp. Would this be a script written for
> use with -batch and a custom make target?

Yes.

> should it also be responsible for downloading a recent copy of the
> source file, or should that be done first, and the function pointed
> at the file?

The latter, I think.  That's what we do with the other data files we
use from external sources, e.g. see admin/unidata/.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Wed, 20 Mar 2019 19:42:02 GMT) Full text and rfc822 format available.

Message #29 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34862 <at> debbugs.gnu.org, rms <at> gnu.org
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Wed, 20 Mar 2019 12:41:45 -0700
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
>> Cc: Richard Stallman <rms <at> gnu.org>,  34862 <at> debbugs.gnu.org
>> Date: Wed, 20 Mar 2019 12:30:22 -0700
>> 
>> > I think this should be done with a script, and that script should be
>> > in our repository.  The easiest kind of a script is a Lisp program, of
>> > course, but we can also use other kinds, such as Awk scripts.
>> 
>> Awk seems just right for the problem, but I haven't written much in it;
>> I did the original munging in elisp. Would this be a script written for
>> use with -batch and a custom make target?
>
> Yes.
>
>> should it also be responsible for downloading a recent copy of the
>> source file, or should that be done first, and the function pointed
>> at the file?
>
> The latter, I think.  That's what we do with the other data files we
> use from external sources, e.g. see admin/unidata/.

Understood -- thanks for this.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Wed, 02 Feb 2022 19:00:02 GMT) Full text and rfc822 format available.

Message #32 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34862 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Wed, 02 Feb 2022 19:59:25 +0100
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

>> I think this should be done with a script, and that script should be
>> in our repository.  The easiest kind of a script is a Lisp program, of
>> course, but we can also use other kinds, such as Awk scripts.
>
> Awk seems just right for the problem, but I haven't written much in it;
> I did the original munging in elisp. Would this be a script written for
> use with -batch and a custom make target?

It's fine to parse the files with Lisp instead of awk (unless they're
needed to boot Emacs, which I don't think is the case here).

Did you get any further with this?

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Tue, 08 Feb 2022 00:27:01 GMT) Full text and rfc822 format available.

Message #35 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34862 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Mon, 07 Feb 2022 16:26:25 -0800
On 02/02/22 19:59 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>>> I think this should be done with a script, and that script should be
>>> in our repository.  The easiest kind of a script is a Lisp program, of
>>> course, but we can also use other kinds, such as Awk scripts.
>>
>> Awk seems just right for the problem, but I haven't written much in it;
>> I did the original munging in elisp. Would this be a script written for
>> use with -batch and a custom make target?
>
> It's fine to parse the files with Lisp instead of awk (unless they're
> needed to boot Emacs, which I don't think is the case here).
>
> Did you get any further with this?

I guess I still didn't know if I should be writing the script as a part
of the make process or not...




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Tue, 08 Feb 2022 06:13:01 GMT) Full text and rfc822 format available.

Message #38 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 34862 <at> debbugs.gnu.org,
 Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Tue, 08 Feb 2022 07:12:28 +0100
Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:

> I guess I still didn't know if I should be writing the script as a part
> of the make process or not...

Yes, I think it would be natural to have it be part of the make process.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34862; Package emacs. (Sat, 15 Feb 2025 02:23:01 GMT) Full text and rfc822 format available.

Message #41 received at 34862 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eric Abrahamsen <eric <at> ericabrahamsen.net>, Eli Zaretskii <eliz <at> gnu.org>,
 34862 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#34862: 27.0.50; Trying to update pinyin.map
Date: Sat, 15 Feb 2025 02:22:50 +0000
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
>> I guess I still didn't know if I should be writing the script as a part
>> of the make process or not...
>
> Yes, I think it would be natural to have it be part of the make process.

(That was three years ago.)

Eric, did you get anywhere with this?




Severity set to 'wishlist' from 'normal' Request was from Stefan Kangas <stefankangas <at> gmail.com> to control <at> debbugs.gnu.org. (Sat, 15 Feb 2025 02:24:01 GMT) Full text and rfc822 format available.

This bug report was last modified 123 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.