From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#16007: admin/charsets/mule-charsets.el requires old Emacs version Date: Tue, 03 Dec 2013 17:59:04 +0200 Message-ID: <83li023ozb.fsf@gnu.org> References: <87wqjm0z0x.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1386086834 17611 80.91.229.3 (3 Dec 2013 16:07:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 16:07:14 +0000 (UTC) Cc: 16007@debbugs.gnu.org To: Kenichi Handa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 03 17:07:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnsVK-0003nX-RD for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 17:07:19 +0100 Original-Received: from localhost ([::1]:43218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnsVJ-0004Xm-Tt for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2013 11:07:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnsOQ-0005QN-SP for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 11:00:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnsOK-0006pq-Mj for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 11:00:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnsOK-0006pe-Ib for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 11:00:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VnsOJ-0001sv-Ju for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2013 11:00:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2013 16:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16007 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16007-submit@debbugs.gnu.org id=B16007.13860863527126 (code B ref 16007); Tue, 03 Dec 2013 16:00:03 +0000 Original-Received: (at 16007) by debbugs.gnu.org; 3 Dec 2013 15:59:12 +0000 Original-Received: from localhost ([127.0.0.1]:56576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnsNT-0001qs-Rh for submit@debbugs.gnu.org; Tue, 03 Dec 2013 10:59:12 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:62520) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VnsNR-0001qC-3q for 16007@debbugs.gnu.org; Tue, 03 Dec 2013 10:59:10 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MX800700MO3FO00@a-mtaout20.012.net.il> for 16007@debbugs.gnu.org; Tue, 03 Dec 2013 17:59:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MX8007YJN2D4680@a-mtaout20.012.net.il>; Tue, 03 Dec 2013 17:59:02 +0200 (IST) In-reply-to: <87wqjm0z0x.fsf@gnu.org> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:81318 Archived-At: > From: Kenichi Handa > Cc: rgm@gnu.org, 16007@debbugs.gnu.org > Date: Tue, 03 Dec 2013 23:50:22 +0900 > > In article <837gbn5hwz.fsf@gnu.org>, Eli Zaretskii 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?