* 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).