charprop.el and uni-*.el

charprop.el and uni-*.el

[Kenichi Handa]

I intended to put files charprop.el and uni-*.el under
lisp/internatinal in CVS, and someone who re-generats them
from admin/unidata/UnicodeData.txt (perhaps by getting the
recent version of that file from unicode.org) commits them.

And, this part in src/Makefile.in:

#ifdef HAVE_UNIDATA
UNIDATA=${admindir}unidata/UnicodeData.txt

${lispsource}international/charprop.el: temacs${EXEEXT} ${UNIDATA}
	RUNEMACS="$(RUN_TEMACS)"; \
	cd ${admindir}unidata; \
	$(MAKE) $(MFLAGS) \
	  RUNEMACS="$${RUNEMACS}" DSTDIR=${lispsource}international
#endif

was just for my conveninence, and I forgot to delete it.

So, I'm going to commit charprop.in and uni-*.el in CVS and
delete the above target in src/Makefile.in.  Any objection?

In the future, I'll write a code to gradually generate data
in uni-*.el from UnicodeData.txt (storing it under etc) on
demand, but for the moment, I don't have a time to do that.
If someone can work on it, I appreciate it very much.

---
Kenichi Handa
handa@ni.aist.go.jp

PS. As I didn't reach the Internet in the weekend, I read
mails this morning, and I have not yet understood well which
problems are already solved, and which are not.  :-(

Re: charprop.el and uni-*.el

[Kim F. Storm]

Kenichi Handa <handa@ni.aist.go.jp> writes:

> So, I'm going to commit charprop.in and uni-*.el in CVS and
> delete the above target in src/Makefile.in.  

charprop.in ?

>                                              Any objection?

Not at all - so far I have been unable to build from CVS
since the unicode merge because make doesn't know how to
build charprop.el.

This is on a fairly up-to-date debian GNU/Linux system, running
/configure without any args.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <87tzkpc9gj.fsf@kfs-lx.rd.rdm>, storm@cua.dk (Kim F. Storm) writes:

> Kenichi Handa <handa@ni.aist.go.jp> writes:
> > So, I'm going to commit charprop.in and uni-*.el in CVS and
> > delete the above target in src/Makefile.in.  

> charprop.in ?

Oops, my typo, I mean charprop.el.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: charprop.el and uni-*.el

[Dan Nicolaescu]

Kenichi Handa <handa@ni.aist.go.jp> writes:

  > PS. As I didn't reach the Internet in the weekend, I read
  > mails this morning, and I have not yet understood well which
  > problems are already solved, and which are not.  :-(

One issue that is still present: the data segment size in emacs went
from 4MB to 11MB.

Re: charprop.el and uni-*.el

[Eli Zaretskii]

> From: Kenichi Handa <handa@ni.aist.go.jp>
> Date: Mon, 04 Feb 2008 17:24:55 +0900
> 
> I intended to put files charprop.el and uni-*.el under
> lisp/internatinal in CVS, and someone who re-generats them
> from admin/unidata/UnicodeData.txt (perhaps by getting the
> recent version of that file from unicode.org) commits them.
> 
> And, this part in src/Makefile.in:
> 
> #ifdef HAVE_UNIDATA
> UNIDATA=${admindir}unidata/UnicodeData.txt
> 
> ${lispsource}international/charprop.el: temacs${EXEEXT} ${UNIDATA}
> 	RUNEMACS="$(RUN_TEMACS)"; \
> 	cd ${admindir}unidata; \
> 	$(MAKE) $(MFLAGS) \
> 	  RUNEMACS="$${RUNEMACS}" DSTDIR=${lispsource}international
> #endif
> 
> was just for my conveninence, and I forgot to delete it.
> 
> So, I'm going to commit charprop.in and uni-*.el in CVS and
> delete the above target in src/Makefile.in.  Any objection?

And what happens when the next Unicode release publishes a new version
of UnicodeData.txt?

> In the future, I'll write a code to gradually generate data
> in uni-*.el from UnicodeData.txt (storing it under etc) on
> demand

How is this different from what we have now?

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <usl08tpiz.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > From: Kenichi Handa <handa@ni.aist.go.jp>
> > Date: Mon, 04 Feb 2008 17:24:55 +0900
> > 
> > I intended to put files charprop.el and uni-*.el under
> > lisp/internatinal in CVS, and someone who re-generats them
> > from admin/unidata/UnicodeData.txt (perhaps by getting the
> > recent version of that file from unicode.org) commits them.
[...]

> And what happens when the next Unicode release publishes a new version
> of UnicodeData.txt?

Someone get it, run make in admin/unidata, commit the newly
generated uni-*.el.

> > In the future, I'll write a code to gradually generate data
> > in uni-*.el from UnicodeData.txt (storing it under etc) on
> > demand

> How is this different from what we have now?

We don't need a little bit cryptic uni-*.el files.  We can
also delete admin/unidata.  Perhaps the first call of
get-char-code-property is will be faster (especially when
PROPNAME is 'name).

---
Kenichi Handa
handa@ni.aist.go.jp

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <E1JLwdL-0003mt-OP@etlken.m17n.org>, Kenichi Handa <handa@ni.aist.go.jp> writes:

> So, I'm going to commit charprop.in and uni-*.el in CVS and
> delete the above target in src/Makefile.in.  Any objection?

Just done.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: charprop.el and uni-*.el

[Jason Rumney]

Kenichi Handa wrote:
> In article <E1JLwdL-0003mt-OP@etlken.m17n.org>, Kenichi Handa <handa@ni.aist.go.jp> writes:
>
>   
>> So, I'm going to commit charprop.in and uni-*.el in CVS and
>> delete the above target in src/Makefile.in.  Any objection?
>>     
>
> Just done.
>   
Should the uni-*.el files be checked in as binary? They don't appear to 
be utf-8 as the coding tag at the bottom claims.

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <47B01DFB.5050905@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > In article <E1JLwdL-0003mt-OP@etlken.m17n.org>, Kenichi Handa <handa@ni.aist.go.jp> writes:
> >
> >   
>>> So, I'm going to commit charprop.in and uni-*.el in CVS and
>>> delete the above target in src/Makefile.in.  Any objection?
>>> 
> >
> > Just done.
> >   
> Should the uni-*.el files be checked in as binary? They don't appear to 
> be utf-8 as the coding tag at the bottom claims.

No, they encode (a kind of) binary data using Unicode
character codes.  I used that format to minimize the file
sizes.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: charprop.el and uni-*.el

[Jason Rumney]

Kenichi Handa wrote:
> In article <47B01DFB.5050905@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
>
>   
>> Should the uni-*.el files be checked in as binary? They don't appear to 
>> be utf-8 as the coding tag at the bottom claims.
>>     
>
> No, they encode (a kind of) binary data using Unicode
> character codes.  I used that format to minimize the file
> sizes.
>   

Binary data is still binary data after it has been utf-8 encoded. And 
wouldn't encoding it make the file size bigger, as now all bytes with 
values in the 128-255 range take up two bytes instead of one?

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Kenichi Handa wrote:
>> In article <47B01DFB.5050905@gnu.org>, Jason Rumney <jasonr@gnu.org> 
>> writes:
>>
>>  
>>> Should the uni-*.el files be checked in as binary? They don't appear 
>>> to be utf-8 as the coding tag at the bottom claims.
>>>     
>>
>> No, they encode (a kind of) binary data using Unicode
>> character codes.  I used that format to minimize the file
>> sizes.
>>   
> 
> Binary data is still binary data after it has been utf-8 encoded. And 
> wouldn't encoding it make the file size bigger, as now all bytes with 
> values in the 128-255 range take up two bytes instead of one?


Here are some errors I got right now during bootstrap after a fresh 
checkout:

Wrote c:/eclean/bld/emacs/lisp/international/quail.elc
Wrote c:/eclean/bld/emacs/lisp/international/robin.elc
Wrote c:/eclean/bld/emacs/lisp/international/titdic-cnv.elc
File local-variables error: (error "Local variables entry is missing the 
suffix")

In toplevel form:
international/uni-bidi.el:492:34:Error: End of file during parsing
File local-variables error: (error "Local variables entry is missing the 
suffix")

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <47B165F5.2050801@gmail.com>, "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Here are some errors I got right now during bootstrap after a fresh 
> checkout:

> Wrote c:/eclean/bld/emacs/lisp/international/quail.elc
> Wrote c:/eclean/bld/emacs/lisp/international/robin.elc
> Wrote c:/eclean/bld/emacs/lisp/international/titdic-cnv.elc
> File local-variables error: (error "Local variables entry is missing the 
> suffix")

> In toplevel form:
> international/uni-bidi.el:492:34:Error: End of file during parsing
> File local-variables error: (error "Local variables entry is missing the 
> suffix")

I don't see that error.

"Juanma Barranquero" <lekktu@gmail.com> writes:

> I think the problem was not related to the uni-* files (it happened
> before they were committed), but it has stopped happening now (perhaps
> because of the regeneration of ldefs-boot.el).

So, perhaps, you have to regenerate loaddefs.el from
ldefs-boot.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: charprop.el and uni-*.el

[Juanma Barranquero]

On Feb 13, 2008 6:32 AM, Kenichi Handa <handa@ni.aist.go.jp> wrote:

> I don't see that error.

I don't see it now, either.

> So, perhaps, you have to regenerate loaddefs.el from
> ldefs-boot.

Bootstrapping already does that.

             Juanma

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Feb 13, 2008 6:32 AM, Kenichi Handa <handa@ni.aist.go.jp> wrote:
> 
>> I don't see that error.
> 
> I don't see it now, either.
> 
>> So, perhaps, you have to regenerate loaddefs.el from
>> ldefs-boot.
> 
> Bootstrapping already does that.


But it stills fails for me (or it failed for me 8 hours ago). I get this

  Wrote c:/eclean/bld/emacs/lisp/international/robin.elc
  Wrote c:/eclean/bld/emacs/lisp/international/titdic-cnv.elc
  File local-variables error: (error "Local variables entry is missing 
the suffix")

  In toplevel form:
  international/uni-bidi.el:492:34:Error: End of file during parsing
  File local-variables error: (error "Local variables entry is missing 
the suffix")

  In toplevel form:
  international/uni-category.el:538:51:Error: End of file during parsing

Bootstrapping continues, but it ends with

  Wrote c:/eclean/bld/emacs/leim/quail/vntelex.elc
    Successfully remade target file `quail/vntelex.elc'.
     File `quail/lao.elc' does not exist.
    Must remake target `quail/lao.elc'.
  "./../src/oo-spd/i386/emacs.exe" -batch --no-init-file --no-site-file 
--multibyte -f batch-byte-compile quail/lao.el
  Loading c:/eclean/bld/emacs/lisp/international/uni-name.el (source)...

  In toplevel form:
  quail/lao.el:32:1:Error: Symbol's value as variable is void: 
char-table-extra-slot
  make[2]: *** [quail/lao.elc] Error 1
  make[2]: Leaving directory `C:/eclean/bld/emacs/leim'
  make[1]: *** [all-other-dirs-gmake] Error 2
  make[1]: Leaving directory `C:/eclean/bld/emacs/nt'
  make: *** [bootstrap] Error 2

Is there something new I should do after the merge? I just use the same 
script to check out and bootstrap etc as I used before.

Re: charprop.el and uni-*.el

[Juanma Barranquero]

On Feb 13, 2008 5:32 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> Is there something new I should do after the merge? I just use the same
> script to check out and bootstrap etc as I used before.

Hmmm. Have you tried with a fresh checkout, i.e., not an update of
your existing one? Bootstrapping does not delete every generated file.

             Juanma

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Feb 13, 2008 5:32 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>> Is there something new I should do after the merge? I just use the same
>> script to check out and bootstrap etc as I used before.
> 
> Hmmm. Have you tried with a fresh checkout, i.e., not an update of
> your existing one? Bootstrapping does not delete every generated file.

Yes, I delete everything first. This is essentially what I do after that:

     cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs co
emacs

     cd emacs\nt
     cvs update -kb

Hm, I forgotten added this, maybe that is the trouble now?:

     cd emacs\leim\CXTERM-DIC
     cvs update -kb *.tit


And then I bootstrap the normal way on w32:

     cd emacs\nt
     make --debug=b bootstrap

Re: charprop.el and uni-*.el

[Juanma Barranquero]

On Feb 13, 2008 6:06 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> Hm, I forgotten added this, maybe that is the trouble now?:
>
>      cd emacs\leim\CXTERM-DIC
>      cvs update -kb *.tit

I have the following files:

  leim/CXTERM-DIC/*.tit
  international/uni-*.el

checked out with -kb and my bootstrap is successful.

> And then I bootstrap the normal way on w32:
>
>      cd emacs\nt
>      make --debug=b bootstrap

Uh?

I always do

  cd emacs\nt
  configure.bat --with-gcc --cflags -IC:/my/emacs/include/path
--cflags -fno-crossjumping
  make bootstrap install

             Juanma

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Feb 13, 2008 6:06 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>> Hm, I forgotten added this, maybe that is the trouble now?:
>>
>>      cd emacs\leim\CXTERM-DIC
>>      cvs update -kb *.tit
> 
> I have the following files:
> 
>   leim/CXTERM-DIC/*.tit
>   international/uni-*.el

Thanks, added the second one.

> checked out with -kb and my bootstrap is successful.
> 
>> And then I bootstrap the normal way on w32:
>>
>>      cd emacs\nt
>>      make --debug=b bootstrap
> 
> Uh?
> 
> I always do
> 
>   cd emacs\nt
>   configure.bat --with-gcc --cflags -IC:/my/emacs/include/path
> --cflags -fno-crossjumping

Me too, but I do not always write what I intend to.

>   make bootstrap install
> 
>              Juanma
> 

A new error this time (unrelated to the prev errors I believe):

   gcc -I. -DWIN32_LEAN_AND_MEAN -D_WIN32_WINNT=0x0400 -D_X86_=1 -c 
-gstabs+ -g3  -mtune=pentium4 -O2  -Di386 -D_CRTAPI1=_cdecl 
-Ic:/g/include -fno-crossjumping -Demacs=1 -DWINDOWSNT -DDOS_NT 
-DHAVE_CONFIG_H -I../nt/inc -D_UCHAR_T -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 
-DPURESIZE=5000000 -o oo-spd/i386/data.o data.c
   data.c:116: error: conflicting types for 'wrong_type_argument'
   lisp.h:2259: error: previous declaration of 'wrong_type_argument' was 
here
   data.c:116: error: conflicting types for 'wrong_type_argument'
   lisp.h:2259: error: previous declaration of 'wrong_type_argument' was 
here
   make[2]: *** [oo-spd/i386/data.o] Error 1
   make[2]: Leaving directory `C:/eclean/bld/emacs/src'
   make[1]: *** [bootstrap-temacs] Error 2
   make[1]: Leaving directory `C:/eclean/bld/emacs/src'
   make: *** [bootstrap-gmake] Error 2

Re: charprop.el and uni-*.el

[Juanma Barranquero]

On Feb 13, 2008 7:17 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> Me too, but I do not always write what I intend to.

:)

> A new error this time (unrelated to the prev errors I believe):

Yes, that's caused by a recent change by Stefan.

             Juanma

Re: charprop.el and uni-*.el

[Stefan Monnier]

> Yes, that's caused by a recent change by Stefan.

I believe I've fixed this mess up,


        Stefan

Re: charprop.el and uni-*.el

[Juanma Barranquero]

On Feb 14, 2008 2:33 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I believe I've fixed this mess up,

I've removed a few ASLOTs in coding.h. It now bootstraps OK.

             Juanma

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> 
> 
> Juanma Barranquero wrote:
>> On Feb 13, 2008 6:06 PM, Lennart Borgman (gmail)
>> <lennart.borgman@gmail.com> wrote:
>>
>>> Hm, I forgotten added this, maybe that is the trouble now?:
>>>
>>>      cd emacs\leim\CXTERM-DIC
>>>      cvs update -kb *.tit
>>
>> I have the following files:
>>
>>   leim/CXTERM-DIC/*.tit
>>   international/uni-*.el
> 
> Thanks, added the second one.
> 
>> checked out with -kb and my bootstrap is successful.
>>
>>> And then I bootstrap the normal way on w32:
>>>
>>>      cd emacs\nt
>>>      make --debug=b bootstrap
>>
>> Uh?
>>
>> I always do
>>
>>   cd emacs\nt
>>   configure.bat --with-gcc --cflags -IC:/my/emacs/include/path
>> --cflags -fno-crossjumping
> 
> Me too, but I do not always write what I intend to.
> 
>>   make bootstrap install
>>
>>              Juanma

Now, with a fresh checkout I get

     File `quail/lao.elc' does not exist.
    Must remake target `quail/lao.elc'.
  "./../src/oo-spd/i386/emacs.exe" -batch --no-init-file --no-site-file 
--multibyte -f batch-byte-compile quail/lao.el
  Loading c:/eclean/bld/emacs/lisp/international/uni-name.el (source)...

  In toplevel form:
  quail/lao.el:32:1:Error: Symbol's value as variable is void: 
char-table-extra-slot
  make[2]: *** [quail/lao.elc] Error 1
  make[2]: Leaving directory `C:/eclean/bld/emacs/leim'
  make[1]: *** [all-other-dirs-gmake] Error 2
  make[1]: Leaving directory `C:/eclean/bld/emacs/nt'
  make: *** [bootstrap] Error 2

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> 
> 
> Juanma Barranquero wrote:
>> On Feb 13, 2008 6:06 PM, Lennart Borgman (gmail)
>> <lennart.borgman@gmail.com> wrote:
>>
>>> Hm, I forgotten added this, maybe that is the trouble now?:
>>>
>>>      cd emacs\leim\CXTERM-DIC
>>>      cvs update -kb *.tit
>>
>> I have the following files:
>>
>>   leim/CXTERM-DIC/*.tit
>>   international/uni-*.el
> 
> Thanks, added the second one.
> 
>> checked out with -kb and my bootstrap is successful.
>>
>>> And then I bootstrap the normal way on w32:
>>>
>>>      cd emacs\nt
>>>      make --debug=b bootstrap
>>
>> Uh?
>>
>> I always do
>>
>>   cd emacs\nt
>>   configure.bat --with-gcc --cflags -IC:/my/emacs/include/path
>> --cflags -fno-crossjumping
> 
> Me too, but I do not always write what I intend to.
> 
>>   make bootstrap install
>>
>>              Juanma

I still cannot build from a fresh checkout. I get this now:

    File `quail/lao.elc' does not exist.
   Must remake target `quail/lao.elc'.
"./../src/oo-spd/i386/emacs.exe" -batch --no-init-file --no-site-file 
--multibyte -f batch-byte-compile quail/lao.el
Loading c:/eclean/bld/emacs/lisp/international/uni-name.el (source)...

In toplevel form:
quail/lao.el:32:1:Error: Symbol's value as variable is void: 
char-table-extra-slot
make[2]: *** [quail/lao.elc] Error 1
make[2]: Leaving directory `C:/eclean/bld/emacs/leim'
make[1]: *** [all-other-dirs-gmake] Error 2
make[1]: Leaving directory `C:/eclean/bld/emacs/nt'
make: *** [bootstrap] Error 2

Re: charprop.el and uni-*.el

[Juanma Barranquero]

On Feb 16, 2008 1:12 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

> I still cannot build from a fresh checkout. I get this now:
>
>
>     File `quail/lao.elc' does not exist.
>    Must remake target `quail/lao.elc'.
> "./../src/oo-spd/i386/emacs.exe" -batch --no-init-file --no-site-file
> --multibyte -f batch-byte-compile quail/lao.el
> Loading c:/eclean/bld/emacs/lisp/international/uni-name.el (source)...
>
> In toplevel form:
> quail/lao.el:32:1:Error: Symbol's value as variable is void:
> char-table-extra-slot
> make[2]: *** [quail/lao.elc] Error 1
> make[2]: Leaving directory `C:/eclean/bld/emacs/leim'
> make[1]: *** [all-other-dirs-gmake] Error 2
> make[1]: Leaving directory `C:/eclean/bld/emacs/nt'
> make: *** [bootstrap] Error 2

I don't know what's causing this. Do you have uni-name.el checked out
as -kb? (quail/lao.el and the lisp/language/lao* files don't need to
be -kb).

             Juanma

Re: charprop.el and uni-*.el

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Feb 16, 2008 1:12 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>> I still cannot build from a fresh checkout. I get this now:
>>
>>
>>     File `quail/lao.elc' does not exist.
>>    Must remake target `quail/lao.elc'.
>> "./../src/oo-spd/i386/emacs.exe" -batch --no-init-file --no-site-file
>> --multibyte -f batch-byte-compile quail/lao.el
>> Loading c:/eclean/bld/emacs/lisp/international/uni-name.el (source)...
>>
>> In toplevel form:
>> quail/lao.el:32:1:Error: Symbol's value as variable is void:
>> char-table-extra-slot
>> make[2]: *** [quail/lao.elc] Error 1
>> make[2]: Leaving directory `C:/eclean/bld/emacs/leim'
>> make[1]: *** [all-other-dirs-gmake] Error 2
>> make[1]: Leaving directory `C:/eclean/bld/emacs/nt'
>> make: *** [bootstrap] Error 2
> 
> I don't know what's causing this. Do you have uni-name.el checked out
> as -kb? (quail/lao.el and the lisp/language/lao* files don't need to
> be -kb).


Ah, thanks Juanma. It is just so much easier when you are sure it should 
work. I should have better error checking in my scripts (yes, I added 
it). I thought I had those checked out as -kb but I did not. Now (for 
the first time since the merge) the bootstrap went fine. Thanks to all 
who have been working with the merge!

Of course there was something that did not work, but I will take that as 
a bug report (perhaps, it might be because everything is not ready yet 
with the merge so I will wait a while).

Re: charprop.el and uni-*.el

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Hm, I forgotten added this, maybe that is the trouble now?:
>
>     cd emacs\leim\CXTERM-DIC
>     cvs update -kb *.tit

No, that bug has been fixed. Now the problem is the files

  lisp/international/uni-*.el

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <47B163B7.6030601@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > In article <47B01DFB.5050905@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:
> >
> >   
>>> Should the uni-*.el files be checked in as binary? They don't appear to 
>>> be utf-8 as the coding tag at the bottom claims.
>>> 
> >
> > No, they encode (a kind of) binary data using Unicode
> > character codes.  I used that format to minimize the file
> > sizes.
> >   

> Binary data is still binary data after it has been utf-8 encoded.

I should have said that they encode a sequence of numbers
and some are greater than 255.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: charprop.el and uni-*.el

[Glenn Morris]

Kenichi Handa wrote:

>> So, I'm going to commit charprop.in and uni-*.el in CVS and delete
>> the above target in src/Makefile.in. Any objection?
>
> Just done.

It breaks bootstrapping.

lisp/Makefile.in has international/charprop.el etc in AUTOGENEL.

So `make maintainer-clean' deletes them. Now there's no rule to
re-make them, so bootstrapping fails.

Maybe they should just be removed from AUTOGENEL?

Re: charprop.el and uni-*.el

[Kenichi Handa]

In article <tchcgf9v3p.fsf@fencepost.gnu.org>, Glenn Morris <rgm@gnu.org> writes:

> Kenichi Handa wrote:
>>> So, I'm going to commit charprop.in and uni-*.el in CVS and delete
>>> the above target in src/Makefile.in. Any objection?
> >
> > Just done.

> It breaks bootstrapping.

> lisp/Makefile.in has international/charprop.el etc in AUTOGENEL.

> So `make maintainer-clean' deletes them. Now there's no rule to
> re-make them, so bootstrapping fails.

> Maybe they should just be removed from AUTOGENEL?

I agree.  I've just installed that change.

---
Kenichi Handa
handa@ni.aist.go.jp