GNU bug report logs - #16007
admin/charsets/mule-charsets.el requires old Emacs version

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kenichi Handa <handa <at> gnu.org>
Cc: rgm <at> gnu.org, 16007 <at> debbugs.gnu.org
Subject: bug#16007: admin/charsets/mule-charsets.el requires old Emacs version
Date: Tue, 03 Dec 2013 17:59:04 +0200

> From: Kenichi Handa <handa <at> gnu.org>
> Cc: rgm <at> gnu.org, 16007 <at> debbugs.gnu.org
> Date: Tue, 03 Dec 2013 23:50:22 +0900
> 
> In article <837gbn5hwz.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > > Emacs 23/24 is built with those maps.  Thus generating those
> > > maps by Emacs 23/24 is nonsense.
> 
> > But we are just one step away of having mule-charsets.el DTRT in Emacs
> > 24 as well.
> 
> The source of those maps is Emacs 22; more precisely
> mule-conf.el and ucs-tables.el of Emacs 22.  I used Emacs 22
> itself rather than writing a converter of those files just
> because the former was far easier.

Yes, I've seen that when I've read the code of mule-charsets.el.

> Anyway, if Emacs 24 has a bug, for instance, in
> map-charset-chars, we may generate wrong maps with that
> buggy Emacs.

Yes, but presumably whoever generates those maps will compare them
with previous ones, before committing the results.

> > Is the effort of making it work with MULE-is13194.map is
> > so significant?
> 
> ??? I'm saying that such an effort is useless.  If someone
> want to generate those maps, he/she should use Emacs 22.

I don't understand: are you saying that these maps are not used at all
in Emacs 23 and later?  In that case, we should simply delete them
from the repository.

But if these files _are_ used by latest Emacsen, then having to look
for an old Emacs 22 binary in order to produce them is a nuisance.
E.g., imagine that the maps have been lost for some reason (like some
disaster on Savannah), and need to be regenerated.

> >  Can you tell me what needs to be done to support that
> > charset?
> 
> Nothing other than fixing the current Emacs so that
> list-charset-chars works correctly with indian-is13194.

Yes, but that doesn't explain anything to me, sorry.  AFAICS,
list-charset-chars doesn't work here because decode-char returns nil,
and encode-char generates codes that are beyond 0x10FFFF, i.e. in some
private plane.  Why is that?

> >  I'll then code that myself.  Who knows, we might need this
> > some day, even if that day is far away.
> 
> Emacs 22 will not run on any avairable machine in the
> future, then we loose the original source of MULE-* maps.
> That's the same as an internet site from which we copied the
> other maps will be closed in the future.
> 
> But what is the problem?  We already have the necessary
> correct maps.  The reason of having mule-charsets.el is to
> tell how those maps are generated, not to re-generate those
> maps.

What if they do need to be re-generated, for some reason we don't
envision currently?

Previous Next

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