* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version @ 2013-11-30 1:54 Glenn Morris 2013-11-30 10:48 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Glenn Morris @ 2013-11-30 1:54 UTC (permalink / raw) To: 16007 Package: emacs Version: 24.3.50 The charsets etc/charsets/MULE*.map are generated files, produced by admin/charsets/mule-charsets.el. But this requires Emacs 21.3 or 22, it does not work with modern Emacs. Therefore Emacs cannot self-bootstrap without an old Emacs around. I think this is a problem. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-11-30 1:54 bug#16007: admin/charsets/mule-charsets.el requires old Emacs version Glenn Morris @ 2013-11-30 10:48 ` Eli Zaretskii 2013-11-30 18:16 ` Glenn Morris 2013-12-02 14:29 ` Kenichi Handa 0 siblings, 2 replies; 22+ messages in thread From: Eli Zaretskii @ 2013-11-30 10:48 UTC (permalink / raw) To: Glenn Morris, Kenichi Handa; +Cc: 16007 > From: Glenn Morris <rgm@gnu.org> > Date: Fri, 29 Nov 2013 20:54:22 -0500 > > The charsets etc/charsets/MULE*.map are generated files, produced by > admin/charsets/mule-charsets.el. But this requires Emacs 21.3 or 22, > it does not work with modern Emacs. Therefore Emacs cannot > self-bootstrap without an old Emacs around. I think this is a problem. Mostly fixed in trunk revision 115303. The only remaining problem is with MULE-is13194.map, in which the modified code generates an empty equivalence list. But a similar problem happens with list-charset-chars, so I guess this charset needs some special handling (it seems to be mapped to a private plane, see ind-util.el). Perhaps Handa-san (CC'ed) could help us out here. Btw, while removing these and similar files from the repository, please keep in mind the possibility that Emacs is bootstrapped in a non-ASCII directory, which could use characters from these charsets. Let's not remove any files that will defeat such a possibility. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-11-30 10:48 ` Eli Zaretskii @ 2013-11-30 18:16 ` Glenn Morris 2013-11-30 18:38 ` Eli Zaretskii 2013-12-02 14:29 ` Kenichi Handa 1 sibling, 1 reply; 22+ messages in thread From: Glenn Morris @ 2013-11-30 18:16 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 Eli Zaretskii wrote: > Btw, while removing these and similar files from the repository, > please keep in mind the possibility that Emacs is bootstrapped in a > non-ASCII directory, which could use characters from these charsets. > Let's not remove any files that will defeat such a possibility. They are not likely to go any time soon, because they require non-standard tools to make. Obviously it's something I have my eye on, though. I am a bit annoyed that we have _two_ identical copies (in etc/charsets and admin/charsets/mapfiles) of some of these generated files in the repo! ;) BTW, this .bzrignore pattern: *.map is far too broad. Eg bzr status etc/charsets/MULE-ipa.map -> ignored: etc/charsets/MULE-ipa.map It seems to be some Windows thing; can it be restricted? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-11-30 18:16 ` Glenn Morris @ 2013-11-30 18:38 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2013-11-30 18:38 UTC (permalink / raw) To: Glenn Morris; +Cc: 16007 > From: Glenn Morris <rgm@gnu.org> > Cc: 16007@debbugs.gnu.org > Date: Sat, 30 Nov 2013 13:16:40 -0500 > > BTW, this .bzrignore pattern: > > *.map > > is far too broad. Eg > > bzr status etc/charsets/MULE-ipa.map > -> ignored: > etc/charsets/MULE-ipa.map > > It seems to be some Windows thing; can it be restricted? If it's only for Windows (I really don't remember, but it looks like you are right), then src/temacs.map is the only file I have that needs to be ignored. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-11-30 10:48 ` Eli Zaretskii 2013-11-30 18:16 ` Glenn Morris @ 2013-12-02 14:29 ` Kenichi Handa 2013-12-02 16:36 ` Eli Zaretskii 1 sibling, 1 reply; 22+ messages in thread From: Kenichi Handa @ 2013-12-02 14:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <83wqjq5fnn.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > The charsets etc/charsets/MULE*.map are generated files, produced by > > admin/charsets/mule-charsets.el. But this requires Emacs 21.3 or 22, > > it does not work with modern Emacs. Therefore Emacs cannot > > self-bootstrap without an old Emacs around. I think this is a problem. They were surely generated using an emacs of older version. But, I don't think we must re-generate them on self-boostrapping Emacs. The map files are already there as well as the other map files copied from some internet sites. > Mostly fixed in trunk revision 115303. Emacs 23/24 is built with those maps. Thus generating those maps by Emacs 23/24 is nonsense. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-02 14:29 ` Kenichi Handa @ 2013-12-02 16:36 ` Eli Zaretskii 2013-12-03 14:50 ` Kenichi Handa 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2013-12-02 16:36 UTC (permalink / raw) To: Kenichi Handa; +Cc: 16007 > From: Kenichi Handa <handa@gnu.org> > Cc: rgm@gnu.org, 16007@debbugs.gnu.org > Date: Mon, 02 Dec 2013 23:29:49 +0900 > > In article <83wqjq5fnn.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > > > The charsets etc/charsets/MULE*.map are generated files, produced by > > > admin/charsets/mule-charsets.el. But this requires Emacs 21.3 or 22, > > > it does not work with modern Emacs. Therefore Emacs cannot > > > self-bootstrap without an old Emacs around. I think this is a problem. > > They were surely generated using an emacs of older version. > But, I don't think we must re-generate them on > self-boostrapping Emacs. The map files are already there as > well as the other map files copied from some internet > sites. > > > Mostly fixed in trunk revision 115303. > > 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. Is the effort of making it work with MULE-is13194.map is so significant? Can you tell me what needs to be done to support that charset? I'll then code that myself. Who knows, we might need this some day, even if that day is far away. TIA ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-02 16:36 ` Eli Zaretskii @ 2013-12-03 14:50 ` Kenichi Handa 2013-12-03 15:59 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Kenichi Handa @ 2013-12-03 14:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <837gbn5hwz.fsf@gnu.org>, Eli Zaretskii <eliz@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. Anyway, if Emacs 24 has a bug, for instance, in map-charset-chars, we may generate wrong maps with that buggy Emacs. > 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. > 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. > 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. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-03 14:50 ` Kenichi Handa @ 2013-12-03 15:59 ` Eli Zaretskii 2013-12-10 11:48 ` K. Handa 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2013-12-03 15:59 UTC (permalink / raw) To: Kenichi Handa; +Cc: 16007 > From: Kenichi Handa <handa@gnu.org> > 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 <eliz@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? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-03 15:59 ` Eli Zaretskii @ 2013-12-10 11:48 ` K. Handa 2013-12-10 17:40 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: K. Handa @ 2013-12-10 11:48 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <83li023ozb.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > 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. If he/she has the "previous ones" to compare, why does he/she have to generate them? > > > 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. They are surely used as well as the other maps (e.g. Uni2JIS) which can never be re-generated if the source internet sites are gone. > 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. I think it is a nuisance to prepare for such a disaster. But, if we are going to do that, as such a disaster will happen on any other internet sites, we should have a program to re-generate all charsets (and perhaps all uni-*.el). --- Kenichi Handa handa@gnu.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-10 11:48 ` K. Handa @ 2013-12-10 17:40 ` Eli Zaretskii 2013-12-11 9:30 ` K. Handa 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2013-12-10 17:40 UTC (permalink / raw) To: K. Handa; +Cc: 16007 > From: handa@gnu.org (K. Handa) > Cc: rgm@gnu.org, 16007@debbugs.gnu.org > Date: Tue, 10 Dec 2013 20:48:11 +0900 > > > > > 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. > > They are surely used as well as the other maps > (e.g. Uni2JIS) which can never be re-generated if the source > internet sites are gone. > > > 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. > > I think it is a nuisance to prepare for such a disaster. > But, if we are going to do that, as such a disaster will > happen on any other internet sites, we should have a program > to re-generate all charsets (and perhaps all uni-*.el). I see. What about the problem with indian-is13194 in list-charset-chars -- what is needed to fix that one? Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-10 17:40 ` Eli Zaretskii @ 2013-12-11 9:30 ` K. Handa 2013-12-11 16:16 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: K. Handa @ 2013-12-11 9:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <83d2l4y57t.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > I think it is a nuisance to prepare for such a disaster. > > But, if we are going to do that, as such a disaster will > > happen on any other internet sites, we should have a program > > to re-generate all charsets (and perhaps all uni-*.el). > I see. Does your change break mule-charsets.el working with Emacs 22? If not, it's ok to keep it as is now, but if it breaks, please revert your change. > What about the problem with indian-is13194 in list-charset-chars -- > what is needed to fix that one? I'm sorry that I don't have a time to fix it yet. I'll work on it after I the problem of bug#15984 is settled. --- Kenichi Handa handa@gnu.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-11 9:30 ` K. Handa @ 2013-12-11 16:16 ` Eli Zaretskii 2013-12-23 18:52 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2013-12-11 16:16 UTC (permalink / raw) To: K. Handa; +Cc: 16007 > From: handa@gnu.org (K. Handa) > Cc: rgm@gnu.org, 16007@debbugs.gnu.org > Date: Wed, 11 Dec 2013 18:30:35 +0900 > > Does your change break mule-charsets.el working with Emacs > 22? If not, it's ok to keep it as is now, but if it breaks, > please revert your change. It is unusual to keep code in Emacs that specifically targets older versions. So no, I didn't keep the v22 code. But I could easily reinstate it, if that's a requirement, conditioned by the Emacs version. > > What about the problem with indian-is13194 in list-charset-chars -- > > what is needed to fix that one? > > I'm sorry that I don't have a time to fix it yet. I think I know the reason: we didn't specify the mapping file for that charset, and didn't make that charset unified. Do you agree with the following patch? It makes list-charset-chars work again for this charset. --- lisp/international/mule-conf.el~ 2013-06-30 07:20:59.000000000 +0300 +++ lisp/international/mule-conf.el 2013-12-11 16:13:53.778785000 +0200 @@ -895,7 +895,8 @@ :emacs-mule-id 225 :supplementary-p t :code-space [33 126] - :code-offset #x180000) + :code-offset #x180000 + :unify-map "MULE-is13194") (let ((code-offset #x180100)) (dolist (script '(devanagari sanskrit bengali tamil telugu assamese @@ -1197,6 +1198,7 @@ (unify-charset 'japanese-jisx0212) (unify-charset 'japanese-jisx0213-1) (unify-charset 'japanese-jisx0213-2) +(unify-charset 'indian-is13194) \f ;; These are tables for translating characters on decoding and ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-11 16:16 ` Eli Zaretskii @ 2013-12-23 18:52 ` Eli Zaretskii 2013-12-24 15:00 ` K. Handa 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2013-12-23 18:52 UTC (permalink / raw) To: handa; +Cc: 16007 Ping! Is the patch suggested below correct, please? > Date: Wed, 11 Dec 2013 18:16:36 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 16007@debbugs.gnu.org > > > From: handa@gnu.org (K. Handa) > > Cc: rgm@gnu.org, 16007@debbugs.gnu.org > > Date: Wed, 11 Dec 2013 18:30:35 +0900 > > > > Does your change break mule-charsets.el working with Emacs > > 22? If not, it's ok to keep it as is now, but if it breaks, > > please revert your change. > > It is unusual to keep code in Emacs that specifically targets older > versions. So no, I didn't keep the v22 code. But I could easily > reinstate it, if that's a requirement, conditioned by the Emacs > version. > > > > What about the problem with indian-is13194 in list-charset-chars -- > > > what is needed to fix that one? > > > > I'm sorry that I don't have a time to fix it yet. > > I think I know the reason: we didn't specify the mapping file for that > charset, and didn't make that charset unified. Do you agree with the > following patch? It makes list-charset-chars work again for this > charset. > > --- lisp/international/mule-conf.el~ 2013-06-30 07:20:59.000000000 +0300 > +++ lisp/international/mule-conf.el 2013-12-11 16:13:53.778785000 +0200 > @@ -895,7 +895,8 @@ > :emacs-mule-id 225 > :supplementary-p t > :code-space [33 126] > - :code-offset #x180000) > + :code-offset #x180000 > + :unify-map "MULE-is13194") > > (let ((code-offset #x180100)) > (dolist (script '(devanagari sanskrit bengali tamil telugu assamese > @@ -1197,6 +1198,7 @@ > (unify-charset 'japanese-jisx0212) > (unify-charset 'japanese-jisx0213-1) > (unify-charset 'japanese-jisx0213-2) > +(unify-charset 'indian-is13194) > > \f > ;; These are tables for translating characters on decoding and > > > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-23 18:52 ` Eli Zaretskii @ 2013-12-24 15:00 ` K. Handa 2013-12-24 17:35 ` Eli Zaretskii 2013-12-31 15:13 ` Kenichi Handa 0 siblings, 2 replies; 22+ messages in thread From: K. Handa @ 2013-12-24 15:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <83r493763q.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > Ping! > Is the patch suggested below correct, please? I'm sorry for being late. It took time to recall why I didn't specify the unify map for indian-is13194. The story is a little bit complicated, but, in short, Emacs 22 was wrong in providing is13194->Unicode map in ucs-tables.el. That map maps indian-is13194 to Unicode Devanagari area, but such a mapping is correct only for Devanagari users. For Telugu users, for instance, the characters in indian-is13194 should be mapped to Unicode Telugu area. IS13194 is actually not a charset but an encoding mechanism of all (ah, almost all) Indian scripts, and it uses the sequence 0xE0 0x4? to switch scripts. So, at the time of designing Unicode-base Emacs, I had intended to solve this incorrect behavior of Emacs 22. But, while attacking many other problems, I forgot this issue. :-( For instance, iscii-to-ucs-region (IS13194 is called as ISCII) of ind-util.el still has this comment: ;; only Devanagari is supported now. I am still wondering how to solve this problem. At least, the docstring of indian-is13194 should state that the current implementation of that charset is for Devanagari users only if we suply the unify-map as your patch. The better will be to provide a different unify map for different lang. env. But, as IS13194 is used very rarely now, I'm not sure it's worth making such an effort. Please give me some more time to decide what to do for the next release. --- Kenichi Handa handa@gnu.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-24 15:00 ` K. Handa @ 2013-12-24 17:35 ` Eli Zaretskii 2013-12-31 15:13 ` Kenichi Handa 1 sibling, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2013-12-24 17:35 UTC (permalink / raw) To: K. Handa; +Cc: 16007 > From: handa@gnu.org (K. Handa) > Cc: 16007@debbugs.gnu.org, handa@gnu.org > Date: Wed, 25 Dec 2013 00:00:39 +0900 > > Please give me some more time to decide what to do for the > next release. OK, please take your time. Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-24 15:00 ` K. Handa 2013-12-24 17:35 ` Eli Zaretskii @ 2013-12-31 15:13 ` Kenichi Handa 2013-12-31 15:18 ` Eli Zaretskii 1 sibling, 1 reply; 22+ messages in thread From: Kenichi Handa @ 2013-12-31 15:13 UTC (permalink / raw) To: K. Handa; +Cc: 16007 In article <87k3eupa3s.fsf@gnu.org>, handa@gnu.org (K. Handa) writes: > I am still wondering how to solve this problem. At least, > the docstring of indian-is13194 should state that the > current implementation of that charset is for Devanagari > users only if we suply the unify-map as your patch. > The better will be to provide a different unify map for > different lang. env. But, as IS13194 is used very rarely > now, I'm not sure it's worth making such an effort. > Please give me some more time to decide what to do for the > next release. I've just committed your changes plus the modification of the docstring of the charset indian-is13194. Happy new year (JST)! --- Kenichi Handa handa@gnu.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-31 15:13 ` Kenichi Handa @ 2013-12-31 15:18 ` Eli Zaretskii 2014-01-01 14:28 ` Kenichi Handa 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2013-12-31 15:18 UTC (permalink / raw) To: Kenichi Handa; +Cc: 16007 > From: Kenichi Handa <handa@gnu.org> > Cc: eliz@gnu.org, 16007@debbugs.gnu.org > Date: Wed, 01 Jan 2014 00:13:01 +0900 > > I've just committed your changes plus the modification of > the docstring of the charset indian-is13194. Thanks. So now, returning to the original issue: since these changes make the new code in admin/charsets/mule-charsets.el produce correct mapping files for all the character sets, do you want me to keep the old Emacs 22 code in mule-charsets.el, in addition to the new (distinguished by the Emacs version), so that mule-charsets.el could be used with both old and new Emacs versions? Or is it OK to leave just the new code there? > Happy new year (JST)! Happy New Year! ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2013-12-31 15:18 ` Eli Zaretskii @ 2014-01-01 14:28 ` Kenichi Handa 2014-01-01 16:04 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Kenichi Handa @ 2014-01-01 14:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <83ppodyrom.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > So now, returning to the original issue: since these changes make the > new code in admin/charsets/mule-charsets.el produce correct mapping > files for all the character sets, ?? The current mule-charsets.el produces only MULE-* charsets. The necessity of the file arises only in the following case: * There occurs a disaster and only admin/charsets/mapfiles/*.map are lost from all the world. Isn't it ridiculous to prepare for such a case? Another necessity of the file, which is my original intention, is to provide the information about from where those maps comes, how those maps are created. > do you want me to keep the old Emacs 22 code in > mule-charsets.el, in addition to the new (distinguished by > the Emacs version), so that mule-charsets.el could be used > with both old and new Emacs versions? I'll repeat that running that file with Emacs 23 is meaningless as well as generating 8859-1.map by Emacs 23. If you think that keeping *.el that doesn't run in the latest Emacs is a bad thing, perhaps the better way to keep the information I wrote above is not by the Lisp file but by a document which may contain the code in mule-charset.el (the original one) as just a reference. If you agree, I'll delete mule-charset.el and add proper information to admin/charsets/mapfiles/README. --- Kenichi Handa handa@gnu.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2014-01-01 14:28 ` Kenichi Handa @ 2014-01-01 16:04 ` Eli Zaretskii 2014-01-02 1:49 ` Kenichi Handa 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2014-01-01 16:04 UTC (permalink / raw) To: Kenichi Handa; +Cc: 16007 > From: Kenichi Handa <handa@gnu.org> > Cc: 16007@debbugs.gnu.org, handa@gnu.org > Date: Wed, 01 Jan 2014 23:28:46 +0900 > > If you think that keeping *.el that doesn't run in the > latest Emacs is a bad thing, perhaps the better way to keep > the information I wrote above is not by the Lisp file but by > a document which may contain the code in mule-charset.el > (the original one) as just a reference. > > If you agree, I'll delete mule-charset.el and add proper > information to admin/charsets/mapfiles/README. I'm not sure we can distribute generated files without the programs that generated them. And even if we could, deleting a file because we don't want to maintain it sounds too drastic to me. Why is it a problem to make changes in mule-charsets.el so that it could work both with Emacs 22 and with the latest versions of Emacs? What do we lose if we make such a change in mule-charsets.el? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2014-01-01 16:04 ` Eli Zaretskii @ 2014-01-02 1:49 ` Kenichi Handa 2014-01-02 3:40 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Kenichi Handa @ 2014-01-02 1:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 16007 In article <83iou3zo1o.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > If you agree, I'll delete mule-charset.el and add proper > > information to admin/charsets/mapfiles/README. > I'm not sure we can distribute generated files without the programs > that generated them. They are not "generated files" in the same sence as, for instance, PTCP154 is not a "generated file". The files etc/charsets/MULE-*.map can not be generated without an external source, and, in this case, that external source is the ucs-tables.el in Emacs 22. That situation is the same as that etc/charsets/PTCP154.map can not be generated without the external source http://www.iana.org/assignments/charset-reg/PTCP154. I don't know how http://www.iana.org/assignments/charset-reg/PTCP154 is generated and don't have a program to generate it. Of course they both (and all othere charset maps) can be generated if we have a running Emacs, but we don't have a program to generate all of them. > And even if we could, deleting a file because we > don't want to maintain it sounds too drastic to me. mule-charset.el is not what to be maintained. It was once used to generate MULE-*.map from Emacs 22. It has already finished the main role. The only remaining role is to tell peaple the origin of those map files as written in admin/charsets/mapfiles/README: ------------------------------------------------------------ * MULE-*.map.gz Created by using ../mule-charsets.el in Emacs 22 as this: % emacs-22 -batch -l ../mule-charsets.el ------------------------------------------------------------ > Why is it a problem to make changes in mule-charsets.el so that it > could work both with Emacs 22 and with the latest versions of Emacs? Because we don't have a reasonable explanation why we have that file and keep it runnable with the latest Emacs. > What do we lose if we make such a change in mule-charsets.el? We will waste a time of future maintainers who must keep that file runnable with the latest Emacs. It's a waste because such an effort yields nothing. --- Kenichi Handa handa@gnu.org ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2014-01-02 1:49 ` Kenichi Handa @ 2014-01-02 3:40 ` Eli Zaretskii 2014-06-07 8:15 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2014-01-02 3:40 UTC (permalink / raw) To: Kenichi Handa, Stefan Monnier; +Cc: 16007 > From: Kenichi Handa <handa@gnu.org> > Cc: 16007@debbugs.gnu.org, handa@gnu.org > Date: Thu, 02 Jan 2014 10:49:09 +0900 > > > Why is it a problem to make changes in mule-charsets.el so that it > > could work both with Emacs 22 and with the latest versions of Emacs? > > Because we don't have a reasonable explanation why we have > that file and keep it runnable with the latest Emacs. > > > What do we lose if we make such a change in mule-charsets.el? > > We will waste a time of future maintainers who must keep > that file runnable with the latest Emacs. It's a waste > because such an effort yields nothing. Stefan, I guess this becomes your call, then. Thanks. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#16007: admin/charsets/mule-charsets.el requires old Emacs version 2014-01-02 3:40 ` Eli Zaretskii @ 2014-06-07 8:15 ` Eli Zaretskii 0 siblings, 0 replies; 22+ messages in thread From: Eli Zaretskii @ 2014-06-07 8:15 UTC (permalink / raw) To: handa; +Cc: 16007-done > Date: Thu, 02 Jan 2014 05:40:00 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 16007@debbugs.gnu.org > > > From: Kenichi Handa <handa@gnu.org> > > Cc: 16007@debbugs.gnu.org, handa@gnu.org > > Date: Thu, 02 Jan 2014 10:49:09 +0900 > > > > > Why is it a problem to make changes in mule-charsets.el so that it > > > could work both with Emacs 22 and with the latest versions of Emacs? > > > > Because we don't have a reasonable explanation why we have > > that file and keep it runnable with the latest Emacs. > > > > > What do we lose if we make such a change in mule-charsets.el? > > > > We will waste a time of future maintainers who must keep > > that file runnable with the latest Emacs. It's a waste > > because such an effort yields nothing. > > Stefan, I guess this becomes your call, then. I see that Handa-san fixed this in revision 115426.1.2, so I'm closing this bug. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-06-07 8:15 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-30 1:54 bug#16007: admin/charsets/mule-charsets.el requires old Emacs version Glenn Morris 2013-11-30 10:48 ` Eli Zaretskii 2013-11-30 18:16 ` Glenn Morris 2013-11-30 18:38 ` Eli Zaretskii 2013-12-02 14:29 ` Kenichi Handa 2013-12-02 16:36 ` Eli Zaretskii 2013-12-03 14:50 ` Kenichi Handa 2013-12-03 15:59 ` Eli Zaretskii 2013-12-10 11:48 ` K. Handa 2013-12-10 17:40 ` Eli Zaretskii 2013-12-11 9:30 ` K. Handa 2013-12-11 16:16 ` Eli Zaretskii 2013-12-23 18:52 ` Eli Zaretskii 2013-12-24 15:00 ` K. Handa 2013-12-24 17:35 ` Eli Zaretskii 2013-12-31 15:13 ` Kenichi Handa 2013-12-31 15:18 ` Eli Zaretskii 2014-01-01 14:28 ` Kenichi Handa 2014-01-01 16:04 ` Eli Zaretskii 2014-01-02 1:49 ` Kenichi Handa 2014-01-02 3:40 ` Eli Zaretskii 2014-06-07 8:15 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).