(\(de\|en\)code-coding-

(\(de\|en\)code-coding-

[Katsumi Yamaoka]

Hi,

I found things that might cause an error in XEmacs with no Mule
by performing

egrep '\((de|en)code-coding-' *.el

in the Gnus source directory.  So, I fixed only nneething.el so
as to use mm-decode-coding-string instead of decode-coding-string
in both the trunk and the v5-10 branch.  But I didn't modify
mml2015.el and the PGG modules since I don't know whether PGG
and EasyPG support non-Mule XEmacs.

cf. http://news.gmane.org/group/gmane.emacs.gnus.user/thread=8276

Regards,

Re: (\(de\|en\)code-coding-

[Daiki Ueno]

>>>>> In <b4mr6vlu7xp.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> I found things that might cause an error in XEmacs with no Mule
> by performing

> egrep '\((de|en)code-coding-' *.el

Is there any particular reason to compile non-Mule XEmacs without
file-coding?  IIRC, at least Debian's xemacs21-nomule is compiled with
--without-mule --with-file-coding and there is encode-coding-region.

> in the Gnus source directory.  So, I fixed only nneething.el so
> as to use mm-decode-coding-string instead of decode-coding-string
> in both the trunk and the v5-10 branch.  But I didn't modify
> mml2015.el and the PGG modules since I don't know whether PGG
> and EasyPG support non-Mule XEmacs.

I think that it's ok to apply the same fix to mml2015.el but please
don't propagate such a change to pgg-*.el.
-- 
Daiki Ueno

Re: (\(de\|en\)code-coding-

[Katsumi Yamaoka]

>>>>> In <94896bca-29ad-425b-83c5-3e767f0a928b@well-done.deisui.org>
>>>>>	Daiki Ueno wrote:

> Is there any particular reason to compile non-Mule XEmacs without
> file-coding?  IIRC, at least Debian's xemacs21-nomule is compiled with
> --without-mule --with-file-coding and there is encode-coding-region.

I don't know, but Uwe Brauer seems to use the one that has
neither mule nor file-coding.  (I have three XEmacs 21.4.19 for
testing.)

>> in the Gnus source directory.  So, I fixed only nneething.el so
>> as to use mm-decode-coding-string instead of decode-coding-string

> I think that it's ok to apply the same fix to mml2015.el but please
> don't propagate such a change to pgg-*.el.

I'll do it.  Thanks.

Re: (\(de\|en\)code-coding-

[Daiki Ueno]

>>>>> In <b4m64cxiuev.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> > Is there any particular reason to compile non-Mule XEmacs without
> > file-coding?  IIRC, at least Debian's xemacs21-nomule is compiled with
> > --without-mule --with-file-coding and there is encode-coding-region.

> I don't know, but Uwe Brauer seems to use the one that has
> neither mule nor file-coding.  (I have three XEmacs 21.4.19 for
> testing.)

I mean, is there any distros which distribute non-Mule XEmacs without
file-coding?  If so, I agree with that it's worth supporting it.
Otherwise I would recommend such a user to recompile with
--with-file-coding.
-- 
Daiki Ueno

Re: (\(de\|en\)code-coding-

[Katsumi Yamaoka]

>>>>> In <9a4033ba-9fa5-487f-9608-fd730bd95c49@well-done.deisui.org>
>>>>>	Daiki Ueno wrote:

> I mean, is there any distros which distribute non-Mule XEmacs without
> file-coding?  If so, I agree with that it's worth supporting it.
> Otherwise I would recommend such a user to recompile with
> --with-file-coding.

Gnus provides `mm-encode-coding-region' and so forth.  Doesn't
it mean there are those who need them?  I can agree personally
not to make Gnus support XEmacs without the file-coding feature,
though.

Re: (\(de\|en\)code-coding-

[Uwe Brauer]

>>>>> " " == Daiki Ueno <ueno@unixuser.org> writes:

>>>>> In <b4m64cxiuev.fsf@jpl.org> 

    > I mean, is there any distros which distribute non-Mule XEmacs without
    > file-coding?  If so, I agree with that it's worth supporting it.
    > Otherwise I would recommend such a user to recompile with
    > --with-file-coding.
Well debian in the non mule version does *not* support file-coding. If
I remember correctly it was me who asked the Debian manager not to
include it anymore. The reasons for this was discussed in XEmacs beta
and unfortunately I don't remember them.

There is another issue, if I use XEmacs mule, then
pgg-encrypt(sign)-region deletes the region in question, so I presume
there might be a different problem

Uwe Brauer 

Re: (\(de\|en\)code-coding-

[Uwe Brauer]

>>>>> " " == Daiki Ueno <ueno@unixuser.org> writes:

>>>>> In <b4mr6vlu7xp.fsf@jpl.org> 
   >>>>>> Katsumi Yamaoka <yamaoka@jpl.org> wrote:
   >> I found things that might cause an error in XEmacs with no Mule
   >> by performing

   >> egrep '\((de|en)code-coding-' *.el

    > Is there any particular reason to compile non-Mule XEmacs without
    > file-coding?  IIRC, at least Debian's xemacs21-nomule is compiled with
    > --without-mule --with-file-coding and there is encode-coding-region.
It is not, see my other mail 

   >> in the Gnus source directory.  So, I fixed only nneething.el so
   >> as to use mm-decode-coding-string instead of decode-coding-string
   >> in both the trunk and the v5-10 branch.  But I didn't modify
   >> mml2015.el and the PGG modules since I don't know whether PGG
   >> and EasyPG support non-Mule XEmacs.

    > I think that it's ok to apply the same fix to mml2015.el but please
    > don't propagate such a change to pgg-*.el.


How shall we proceed?

Uwe Brauer

Re: (\(de\|en\)code-coding-

[Daiki Ueno]

>>>>> In <873b81p7ko.fsf@mat.ucm.es> 
>>>>>	Uwe Brauer <uwe_brauer@mat.ucm.es> wrote:
>     > Is there any particular reason to compile non-Mule XEmacs without
>     > file-coding?  IIRC, at least Debian's xemacs21-nomule is compiled with
>     > --without-mule --with-file-coding and there is encode-coding-region.
> It is not, see my other mail 

>>>>> In <877ixdp7n7.fsf@mat.ucm.es> 
>>>>>	Uwe Brauer <uwe_brauer@mat.ucm.es> wrote:
> >>>>> " " == Daiki Ueno <ueno@unixuser.org> writes:

> Well debian in the non mule version does *not* support file-coding. If
> I remember correctly it was me who asked the Debian manager not to
> include it anymore. The reasons for this was discussed in XEmacs beta
> and unfortunately I don't remember them.

Ok, I'll do search on Gmane.

>     > I think that it's ok to apply the same fix to mml2015.el but please
>     > don't propagate such a change to pgg-*.el.

> How shall we proceed?

I'll add a workaround to PGG, not using mm-* functions.
-- 
Daiki Ueno

Re: (\(de\|en\)code-coding-

[Daiki Ueno]

>>>>> In <79e43a18-83dd-4d65-a595-94a29351052e@well-done.deisui.org> 
>>>>>	Daiki Ueno <ueno@unixuser.org> wrote:
> >     > I think that it's ok to apply the same fix to mml2015.el but please
> >     > don't propagate such a change to pgg-*.el.

> > How shall we proceed?

> I'll add a workaround to PGG, not using mm-* functions.

Sorry, I was half asleep when I wrote it.  I won't do it because I think
PGG in the Gnus trunk should be reverted to v5-10 branch.

See http://article.gmane.org/gmane.emacs.gnus.general/63738

Regards,
-- 
Daiki Ueno