* ediff and coding systems
@ 2007-10-20 15:21 Dan Nicolaescu
2007-10-20 18:09 ` Eli Zaretskii
2007-10-21 2:12 ` Stefan Monnier
0 siblings, 2 replies; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-20 15:21 UTC (permalink / raw)
To: emacs-devel
lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
When doing M-x ediff for the above 2 files a *Warning* buffer pops up
for each hunk:
These default coding systems were tried to encode text
in the buffer ` *ediff-tmp*':
iso-latin-1
However, each of them encountered characters it couldn't encode:
iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
Click on a character (or switch to this window by `C-x o'
and select the characters by RET) to jump to the place it appears,
where `C-u C-x =' will give information about it.
Select one of the safe coding systems listed below,
or cancel the writing with C-g and edit the buffer
to remove or modify the problematic characters,
or specify any other coding system (and risk losing
the problematic characters).
utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
with the question "Select coding system (default mule-utf-8):"
Would it be possible for ediff to avoid this?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-20 15:21 ediff and coding systems Dan Nicolaescu
@ 2007-10-20 18:09 ` Eli Zaretskii
2007-10-21 5:43 ` Michael Kifer
2007-10-21 2:12 ` Stefan Monnier
1 sibling, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2007-10-20 18:09 UTC (permalink / raw)
To: Michael Kifer, Dan Nicolaescu; +Cc: emacs-devel
Michael, could you please look into the following report? TIA
> From: Dan Nicolaescu <dann@ics.uci.edu>
> Date: Sat, 20 Oct 2007 08:21:10 -0700
>
>
> lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
>
> When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> for each hunk:
>
> These default coding systems were tried to encode text
> in the buffer ` *ediff-tmp*':
> iso-latin-1
> However, each of them encountered characters it couldn't encode:
> iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
>
> Click on a character (or switch to this window by `C-x o'
> and select the characters by RET) to jump to the place it appears,
> where `C-u C-x =' will give information about it.
>
> Select one of the safe coding systems listed below,
> or cancel the writing with C-g and edit the buffer
> to remove or modify the problematic characters,
> or specify any other coding system (and risk losing
> the problematic characters).
>
> utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
>
> with the question "Select coding system (default mule-utf-8):"
>
> Would it be possible for ediff to avoid this?
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-20 18:09 ` Eli Zaretskii
@ 2007-10-21 5:43 ` Michael Kifer
2007-10-21 6:12 ` Dan Nicolaescu
0 siblings, 1 reply; 24+ messages in thread
From: Michael Kifer @ 2007-10-21 5:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dan Nicolaescu, emacs-devel
I cannot reproduce this. I need a simple testcase.
I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
and the other with utf-8. But ediffing them did not bring any warnings.
> Michael, could you please look into the following report? TIA
>
> > From: Dan Nicolaescu <dann@ics.uci.edu>
> > Date: Sat, 20 Oct 2007 08:21:10 -0700
> >
> >
> > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> >
> > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > for each hunk:
> >
> > These default coding systems were tried to encode text
> > in the buffer ` *ediff-tmp*':
> > iso-latin-1
> > However, each of them encountered characters it couldn't encode:
> > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> >
> > Click on a character (or switch to this window by `C-x o'
> > and select the characters by RET) to jump to the place it appears,
> > where `C-u C-x =' will give information about it.
> >
> > Select one of the safe coding systems listed below,
> > or cancel the writing with C-g and edit the buffer
> > to remove or modify the problematic characters,
> > or specify any other coding system (and risk losing
> > the problematic characters).
> >
> > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> >
> > with the question "Select coding system (default mule-utf-8):"
> >
> > Would it be possible for ediff to avoid this?
> >
> >
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/emacs-devel
> >
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 5:43 ` Michael Kifer
@ 2007-10-21 6:12 ` Dan Nicolaescu
2007-10-21 6:52 ` Michael Kifer
0 siblings, 1 reply; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-21 6:12 UTC (permalink / raw)
To: Michael Kifer; +Cc: Eli Zaretskii, emacs-devel
kifer@cs.sunysb.edu (Michael Kifer) writes:
> I cannot reproduce this. I need a simple testcase.
> I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
> and the other with utf-8. But ediffing them did not bring any warnings.
Please try
env LANG=C emacs -q
and then ediff the 2 files.
> > Michael, could you please look into the following report? TIA
> >
> > > From: Dan Nicolaescu <dann@ics.uci.edu>
> > > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > >
> > >
> > > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> > >
> > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > > for each hunk:
> > >
> > > These default coding systems were tried to encode text
> > > in the buffer ` *ediff-tmp*':
> > > iso-latin-1
> > > However, each of them encountered characters it couldn't encode:
> > > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > >
> > > Click on a character (or switch to this window by `C-x o'
> > > and select the characters by RET) to jump to the place it appears,
> > > where `C-u C-x =' will give information about it.
> > >
> > > Select one of the safe coding systems listed below,
> > > or cancel the writing with C-g and edit the buffer
> > > to remove or modify the problematic characters,
> > > or specify any other coding system (and risk losing
> > > the problematic characters).
> > >
> > > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > >
> > > with the question "Select coding system (default mule-utf-8):"
> > >
> > > Would it be possible for ediff to avoid this?
> > >
> > >
> > > _______________________________________________
> > > Emacs-devel mailing list
> > > Emacs-devel@gnu.org
> > > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > >
> >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 6:12 ` Dan Nicolaescu
@ 2007-10-21 6:52 ` Michael Kifer
2007-10-21 7:17 ` Dan Nicolaescu
0 siblings, 1 reply; 24+ messages in thread
From: Michael Kifer @ 2007-10-21 6:52 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel
Same thing - no luck.
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
> > I cannot reproduce this. I need a simple testcase.
> > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
> > and the other with utf-8. But ediffing them did not bring any warnings.
>
> Please try
> env LANG=C emacs -q
> and then ediff the 2 files.
>
>
> > > Michael, could you please look into the following report? TIA
> > >
> > > > From: Dan Nicolaescu <dann@ics.uci.edu>
> > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > > >
> > > >
> > > > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> > > >
> > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > > > for each hunk:
> > > >
> > > > These default coding systems were tried to encode text
> > > > in the buffer ` *ediff-tmp*':
> > > > iso-latin-1
> > > > However, each of them encountered characters it couldn't encode:
> > > > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > > >
> > > > Click on a character (or switch to this window by `C-x o'
> > > > and select the characters by RET) to jump to the place it appears,
> > > > where `C-u C-x =' will give information about it.
> > > >
> > > > Select one of the safe coding systems listed below,
> > > > or cancel the writing with C-g and edit the buffer
> > > > to remove or modify the problematic characters,
> > > > or specify any other coding system (and risk losing
> > > > the problematic characters).
> > > >
> > > > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > > >
> > > > with the question "Select coding system (default mule-utf-8):"
> > > >
> > > > Would it be possible for ediff to avoid this?
> > > >
> > > >
> > > > _______________________________________________
> > > > Emacs-devel mailing list
> > > > Emacs-devel@gnu.org
> > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > > >
> > >
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 6:52 ` Michael Kifer
@ 2007-10-21 7:17 ` Dan Nicolaescu
2007-10-21 18:46 ` Michael Kifer
0 siblings, 1 reply; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-21 7:17 UTC (permalink / raw)
To: Michael Kifer; +Cc: Eli Zaretskii, emacs-devel
kifer@cs.sunysb.edu (Michael Kifer) writes:
> Same thing - no luck.
What version of emacs are you using?
With 22.1 it works fine for me, with CVS trunk it does not...
> > kifer@cs.sunysb.edu (Michael Kifer) writes:
> >
> > > I cannot reproduce this. I need a simple testcase.
> > > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
> > > and the other with utf-8. But ediffing them did not bring any warnings.
> >
> > Please try
> > env LANG=C emacs -q
> > and then ediff the 2 files.
> >
> >
> > > > Michael, could you please look into the following report? TIA
> > > >
> > > > > From: Dan Nicolaescu <dann@ics.uci.edu>
> > > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > > > >
> > > > >
> > > > > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> > > > >
> > > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > > > > for each hunk:
> > > > >
> > > > > These default coding systems were tried to encode text
> > > > > in the buffer ` *ediff-tmp*':
> > > > > iso-latin-1
> > > > > However, each of them encountered characters it couldn't encode:
> > > > > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > > > >
> > > > > Click on a character (or switch to this window by `C-x o'
> > > > > and select the characters by RET) to jump to the place it appears,
> > > > > where `C-u C-x =' will give information about it.
> > > > >
> > > > > Select one of the safe coding systems listed below,
> > > > > or cancel the writing with C-g and edit the buffer
> > > > > to remove or modify the problematic characters,
> > > > > or specify any other coding system (and risk losing
> > > > > the problematic characters).
> > > > >
> > > > > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > > > >
> > > > > with the question "Select coding system (default mule-utf-8):"
> > > > >
> > > > > Would it be possible for ediff to avoid this?
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Emacs-devel mailing list
> > > > > Emacs-devel@gnu.org
> > > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > > > >
> > > >
> >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 7:17 ` Dan Nicolaescu
@ 2007-10-21 18:46 ` Michael Kifer
2007-10-21 19:22 ` Dan Nicolaescu
0 siblings, 1 reply; 24+ messages in thread
From: Michael Kifer @ 2007-10-21 18:46 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel
I am using 23.0.50 - the current CVS version.
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
> > Same thing - no luck.
>
> What version of emacs are you using?
> With 22.1 it works fine for me, with CVS trunk it does not...
>
> > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > >
> > > > I cannot reproduce this. I need a simple testcase.
> > > > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
> > > > and the other with utf-8. But ediffing them did not bring any warnings.
> > >
> > > Please try
> > > env LANG=C emacs -q
> > > and then ediff the 2 files.
> > >
> > >
> > > > > Michael, could you please look into the following report? TIA
> > > > >
> > > > > > From: Dan Nicolaescu <dann@ics.uci.edu>
> > > > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > > > > >
> > > > > >
> > > > > > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > > > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> > > > > >
> > > > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > > > > > for each hunk:
> > > > > >
> > > > > > These default coding systems were tried to encode text
> > > > > > in the buffer ` *ediff-tmp*':
> > > > > > iso-latin-1
> > > > > > However, each of them encountered characters it couldn't encode:
> > > > > > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > > > > >
> > > > > > Click on a character (or switch to this window by `C-x o'
> > > > > > and select the characters by RET) to jump to the place it appears,
> > > > > > where `C-u C-x =' will give information about it.
> > > > > >
> > > > > > Select one of the safe coding systems listed below,
> > > > > > or cancel the writing with C-g and edit the buffer
> > > > > > to remove or modify the problematic characters,
> > > > > > or specify any other coding system (and risk losing
> > > > > > the problematic characters).
> > > > > >
> > > > > > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > > > > >
> > > > > > with the question "Select coding system (default mule-utf-8):"
> > > > > >
> > > > > > Would it be possible for ediff to avoid this?
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Emacs-devel mailing list
> > > > > > Emacs-devel@gnu.org
> > > > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > > > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 18:46 ` Michael Kifer
@ 2007-10-21 19:22 ` Dan Nicolaescu
2007-10-21 19:37 ` Leo
` (2 more replies)
0 siblings, 3 replies; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-21 19:22 UTC (permalink / raw)
To: Michael Kifer; +Cc: Eli Zaretskii, emacs-devel
kifer@cs.sunysb.edu (Michael Kifer) writes:
> I am using 23.0.50 - the current CVS version.
I can reproduce it with a version checked out this morning from CVS
trunk and one that is about 1 week old, I don't have anything older
than that.
Is your version up to date?
Can anybody else reproduce it? I don't know much about coding systems,
so unfortunately I can't really debug this myself.
>
> > kifer@cs.sunysb.edu (Michael Kifer) writes:
> >
> > > Same thing - no luck.
> >
> > What version of emacs are you using?
> > With 22.1 it works fine for me, with CVS trunk it does not...
> >
> > > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > >
> > > > > I cannot reproduce this. I need a simple testcase.
> > > > > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
> > > > > and the other with utf-8. But ediffing them did not bring any warnings.
> > > >
> > > > Please try
> > > > env LANG=C emacs -q
> > > > and then ediff the 2 files.
> > > >
> > > >
> > > > > > Michael, could you please look into the following report? TIA
> > > > > >
> > > > > > > From: Dan Nicolaescu <dann@ics.uci.edu>
> > > > > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > > > > > >
> > > > > > >
> > > > > > > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > > > > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> > > > > > >
> > > > > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > > > > > > for each hunk:
> > > > > > >
> > > > > > > These default coding systems were tried to encode text
> > > > > > > in the buffer ` *ediff-tmp*':
> > > > > > > iso-latin-1
> > > > > > > However, each of them encountered characters it couldn't encode:
> > > > > > > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > > > > > >
> > > > > > > Click on a character (or switch to this window by `C-x o'
> > > > > > > and select the characters by RET) to jump to the place it appears,
> > > > > > > where `C-u C-x =' will give information about it.
> > > > > > >
> > > > > > > Select one of the safe coding systems listed below,
> > > > > > > or cancel the writing with C-g and edit the buffer
> > > > > > > to remove or modify the problematic characters,
> > > > > > > or specify any other coding system (and risk losing
> > > > > > > the problematic characters).
> > > > > > >
> > > > > > > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > > > > > >
> > > > > > > with the question "Select coding system (default mule-utf-8):"
> > > > > > >
> > > > > > > Would it be possible for ediff to avoid this?
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Emacs-devel mailing list
> > > > > > > Emacs-devel@gnu.org
> > > > > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > > > > > >
> > > > > >
> > > >
> >
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-21 19:22 ` Dan Nicolaescu
@ 2007-10-21 19:37 ` Leo
2007-10-21 21:35 ` Michael Kifer
2007-10-22 3:42 ` Kenichi Handa
2 siblings, 0 replies; 24+ messages in thread
From: Leo @ 2007-10-21 19:37 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Eli Zaretskii, Michael Kifer, emacs-devel
On 2007-10-21 20:22 +0100, Dan Nicolaescu wrote:
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
> > I am using 23.0.50 - the current CVS version.
>
> I can reproduce it with a version checked out this morning from CVS
> trunk and one that is about 1 week old, I don't have anything older
> than that.
>
> Is your version up to date?
>
> Can anybody else reproduce it? I don't know much about coding systems,
> so unfortunately I can't really debug this myself.
I seemed to see a similar bug in the past.
http://news.gmane.org/group/gmane.emacs.pretest.bugs/thread=15737
--
.: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :.
Use the most powerful email client -- http://gnus.org/
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-21 19:22 ` Dan Nicolaescu
2007-10-21 19:37 ` Leo
@ 2007-10-21 21:35 ` Michael Kifer
2007-10-22 2:08 ` Dan Nicolaescu
2007-10-22 3:42 ` Kenichi Handa
2 siblings, 1 reply; 24+ messages in thread
From: Michael Kifer @ 2007-10-21 21:35 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
> > I am using 23.0.50 - the current CVS version.
>
> I can reproduce it with a version checked out this morning from CVS
> trunk and one that is about 1 week old, I don't have anything older
> than that.
>
> Is your version up to date?
Yes - just updated it this morning.
> Can anybody else reproduce it? I don't know much about coding systems,
> so unfortunately I can't really debug this myself.
>
> >
> > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > >
> > > > Same thing - no luck.
> > >
> > > What version of emacs are you using?
> > > With 22.1 it works fine for me, with CVS trunk it does not...
> > >
> > > > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > > >
> > > > > > I cannot reproduce this. I need a simple testcase.
> > > > > > I took lisp/term/mac-win.el and created two copies. One with iso-2022-7bit
> > > > > > and the other with utf-8. But ediffing them did not bring any warnings.
> > > > >
> > > > > Please try
> > > > > env LANG=C emacs -q
> > > > > and then ediff the 2 files.
> > > > >
> > > > >
> > > > > > > Michael, could you please look into the following report? TIA
> > > > > > >
> > > > > > > > From: Dan Nicolaescu <dann@ics.uci.edu>
> > > > > > > > Date: Sat, 20 Oct 2007 08:21:10 -0700
> > > > > > > >
> > > > > > > >
> > > > > > > > lisp/term/mac-win.el from CVS trunk uses: -*-coding: iso-2022-7bit;-*-
> > > > > > > > and the same file on the emacs-unicode-2 uses: -*-coding: utf-8
> > > > > > > >
> > > > > > > > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > > > > > > > for each hunk:
> > > > > > > >
> > > > > > > > These default coding systems were tried to encode text
> > > > > > > > in the buffer ` *ediff-tmp*':
> > > > > > > > iso-latin-1
> > > > > > > > However, each of them encountered characters it couldn't encode:
> > > > > > > > iso-latin-1 cannot encode these: ? ? ? ? ? ? ? ? ? ? ...
> > > > > > > >
> > > > > > > > Click on a character (or switch to this window by `C-x o'
> > > > > > > > and select the characters by RET) to jump to the place it appears,
> > > > > > > > where `C-u C-x =' will give information about it.
> > > > > > > >
> > > > > > > > Select one of the safe coding systems listed below,
> > > > > > > > or cancel the writing with C-g and edit the buffer
> > > > > > > > to remove or modify the problematic characters,
> > > > > > > > or specify any other coding system (and risk losing
> > > > > > > > the problematic characters).
> > > > > > > >
> > > > > > > > utf-8 utf-16 utf-16 utf-16 utf-16be utf-16le iso-2022-7bit
> > > > > > > >
> > > > > > > > with the question "Select coding system (default mule-utf-8):"
> > > > > > > >
> > > > > > > > Would it be possible for ediff to avoid this?
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Emacs-devel mailing list
> > > > > > > > Emacs-devel@gnu.org
> > > > > > > > http://lists.gnu.org/mailman/listinfo/emacs-devel
> > > > > > > >
> > > > > > >
> > > > >
> > >
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 21:35 ` Michael Kifer
@ 2007-10-22 2:08 ` Dan Nicolaescu
2007-10-22 3:50 ` Michael Kifer
0 siblings, 1 reply; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-22 2:08 UTC (permalink / raw)
To: Michael Kifer; +Cc: Eli Zaretskii, emacs-devel
kifer@cs.sunysb.edu (Michael Kifer) writes:
> > kifer@cs.sunysb.edu (Michael Kifer) writes:
> >
> > > I am using 23.0.50 - the current CVS version.
> >
> > I can reproduce it with a version checked out this morning from CVS
> > trunk and one that is about 1 week old, I don't have anything older
> > than that.
> >
> > Is your version up to date?
>
> Yes - just updated it this morning.
I don't have any other ideas of what to try...
Not related to this, but could you please look at these byte compile
warnings for viper-cmd.el?
In viper-next-line-carefully:
viper-cmd.el:2792:19:Warning: `next-line' used from Lisp code
That command is designed for interactive use only
In viper-next-line:
viper-cmd.el:3091:41:Warning: `next-line' used from Lisp code
That command is designed for interactive use only
In viper-previous-line:
viper-cmd.el:3134:41:Warning: `previous-line' used from Lisp code
That command is designed for interactive use only
Most similar warnings have been fixed in CVS, but for the above is not
obvious what to do.
In end of data:
viper-cmd.el:5099:1:Warning: the function `viper-heading-end' might
not be defined at runtime.
This one is strange
viper-cmd.el:5099:1:Warning: the following functions are not known to
be defined: quail-input-method, quail-start-translation,
event-to-character, character-to-event, viper-iconify, key-press-event-p, event-key,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These should be optimized out by the byte compiler.
Also viper-xemacs-p is about as long as (featurep 'emacs) and as
readable. Why not replace it? Most similar macros have been replaced
in CVS.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 2:08 ` Dan Nicolaescu
@ 2007-10-22 3:50 ` Michael Kifer
2007-10-27 21:03 ` Dan Nicolaescu
0 siblings, 1 reply; 24+ messages in thread
From: Michael Kifer @ 2007-10-22 3:50 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
> > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > >
> > > > I am using 23.0.50 - the current CVS version.
> > >
> > > I can reproduce it with a version checked out this morning from CVS
> > > trunk and one that is about 1 week old, I don't have anything older
> > > than that.
> > >
> > > Is your version up to date?
> >
> > Yes - just updated it this morning.
>
> I don't have any other ideas of what to try...
I dunno either. If somebody can come up with a reproducible test then I
could try to see what is going on.
> Not related to this, but could you please look at these byte compile
> warnings for viper-cmd.el?
>
> In viper-next-line-carefully:
> viper-cmd.el:2792:19:Warning: `next-line' used from Lisp code
> That command is designed for interactive use only
>
> In viper-next-line:
> viper-cmd.el:3091:41:Warning: `next-line' used from Lisp code
> That command is designed for interactive use only
>
> In viper-previous-line:
> viper-cmd.el:3134:41:Warning: `previous-line' used from Lisp code
> That command is designed for interactive use only
>
> Most similar warnings have been fixed in CVS, but for the above is not
> obvious what to do.
ok
> In end of data:
> viper-cmd.el:5099:1:Warning: the function `viper-heading-end' might
> not be defined at runtime.
No idea why the above shows up. Could it be a compiler bug?
>
> This one is strange
>
>
> viper-cmd.el:5099:1:Warning: the following functions are not known to
> be defined: quail-input-method, quail-start-translation,
> event-to-character, character-to-event, viper-iconify, key-press-event-p, event-key,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> These should be optimized out by the byte compiler.
No idea. The above are mostly XEmacs functions.
> Also viper-xemacs-p is about as long as (featurep 'emacs) and as
> readable. Why not replace it? Most similar macros have been replaced
> in CVS.
I do not really care, but see no reason why waste time on this one.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-22 3:50 ` Michael Kifer
@ 2007-10-27 21:03 ` Dan Nicolaescu
2007-10-28 21:01 ` Michael Kifer
0 siblings, 1 reply; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-27 21:03 UTC (permalink / raw)
To: Michael Kifer; +Cc: Eli Zaretskii, emacs-devel
kifer@cs.sunysb.edu (Michael Kifer) writes:
> > kifer@cs.sunysb.edu (Michael Kifer) writes:
> >
> > > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > >
> > This one is strange
> >
> >
> > viper-cmd.el:5099:1:Warning: the following functions are not known to
> > be defined: quail-input-method, quail-start-translation,
> > event-to-character, character-to-event, viper-iconify, key-press-event-p, event-key,
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > These should be optimized out by the byte compiler.
>
> No idea. The above are mostly XEmacs functions.
These warnings show up because the XEmacs functions are conditionally
called with the condition being the viper-xemacs-p defconst.
Defconsts cannot be optimized out at compile time.
> > Also viper-xemacs-p is about as long as (featurep 'emacs) and as
> > readable. Why not replace it? Most similar macros have been replaced
> > in CVS.
>
>
> I do not really care, but see no reason why waste time on this one.
Would you mind if I do it? For viper* and ediff* ?
Doing this will allow the byte compiler to get rid code at compile
time, this saves a few kilobytes of disk space.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-27 21:03 ` Dan Nicolaescu
@ 2007-10-28 21:01 ` Michael Kifer
0 siblings, 0 replies; 24+ messages in thread
From: Michael Kifer @ 2007-10-28 21:01 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: Eli Zaretskii, emacs-devel
> kifer@cs.sunysb.edu (Michael Kifer) writes:
>
> > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > >
> > > > > kifer@cs.sunysb.edu (Michael Kifer) writes:
> > > > >
> > > This one is strange
> > >
> > >
> > > viper-cmd.el:5099:1:Warning: the following functions are not known to
> > > be defined: quail-input-method, quail-start-translation,
> > > event-to-character, character-to-event, viper-iconify, key-press-event-p, event-key,
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > These should be optimized out by the byte compiler.
> >
> > No idea. The above are mostly XEmacs functions.
>
> These warnings show up because the XEmacs functions are conditionally
> called with the condition being the viper-xemacs-p defconst.
> Defconsts cannot be optimized out at compile time.
>
>
> > > Also viper-xemacs-p is about as long as (featurep 'emacs) and as
> > > readable. Why not replace it? Most similar macros have been replaced
> > > in CVS.
> >
> >
> > I do not really care, but see no reason why waste time on this one.
>
> Would you mind if I do it? For viper* and ediff* ?
I do not mind, but I am doing some changes now and do not want conflicts to
arise. Hold off for a couple of weeks.
> Doing this will allow the byte compiler to get rid code at compile
> time, this saves a few kilobytes of disk space.
I claim that a few Kbs are not worth of anybody's time these days.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-21 19:22 ` Dan Nicolaescu
2007-10-21 19:37 ` Leo
2007-10-21 21:35 ` Michael Kifer
@ 2007-10-22 3:42 ` Kenichi Handa
2007-10-22 4:20 ` Eli Zaretskii
2007-10-22 4:29 ` Michael Kifer
2 siblings, 2 replies; 24+ messages in thread
From: Kenichi Handa @ 2007-10-22 3:42 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: eliz, kifer, emacs-devel
In article <200710211922.l9LJMQFX013338@oogie-boogie.ics.uci.edu>, Dan Nicolaescu <dann@ics.uci.edu> writes:
> Can anybody else reproduce it? I don't know much about coding systems,
> so unfortunately I can't really debug this myself.
I can reproduce it when I run Emacs with LANG=C, and try to
see the 5th (or 6th) different point where non-ASCII
charaters exist. The calling sequence of read-coding-system
is this:
read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
select-safe-coding-system-interactively(1 5557 (utf-8 ....))
select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
ediff-make-temp-file(#<buffer *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
ediff-make-fine-diffs(5 noforce)
ediff-install-fine-diff-if-necessary(5)
ediff-next-difference(1)
call-interactively(ediff-next-difference)
I don't know why ediff-make-temp-file is called, but perhaps
it should call write-region while binding
coding-system-for-write to `no-conversion' or `emacs-mule'.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 3:42 ` Kenichi Handa
@ 2007-10-22 4:20 ` Eli Zaretskii
2007-10-22 5:05 ` Kenichi Handa
2007-10-22 15:32 ` Stefan Monnier
2007-10-22 4:29 ` Michael Kifer
1 sibling, 2 replies; 24+ messages in thread
From: Eli Zaretskii @ 2007-10-22 4:20 UTC (permalink / raw)
To: Kenichi Handa; +Cc: dann, kifer, emacs-devel
> From: Kenichi Handa <handa@m17n.org>
> CC: kifer@cs.sunysb.edu, eliz@gnu.org, emacs-devel@gnu.org
> Date: Mon, 22 Oct 2007 12:42:47 +0900
>
> read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
> select-safe-coding-system-interactively(1 5557 (utf-8 ....))
> select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
> write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
> ediff-make-temp-file(#<buffer *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
> ediff-make-fine-diffs(5 noforce)
> ediff-install-fine-diff-if-necessary(5)
> ediff-next-difference(1)
> call-interactively(ediff-next-difference)
>
> I don't know why ediff-make-temp-file is called, but perhaps
> it should call write-region while binding
> coding-system-for-write to `no-conversion' or `emacs-mule'.
Not a good idea, I'm afraid: those temporary files (or parts thereof)
will need to be read back, when `diff' finishes, so each one needs to
be in the original encoding, or else the diffs will be incorrect.
E.g., imagine two files with the same text, but different encodings: I
don't think we want ediff say that they compare identical.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 4:20 ` Eli Zaretskii
@ 2007-10-22 5:05 ` Kenichi Handa
2007-10-22 15:32 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Kenichi Handa @ 2007-10-22 5:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dann, kifer, emacs-devel
In article <uve8zu6f4.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> > From: Kenichi Handa <handa@m17n.org>
> > CC: kifer@cs.sunysb.edu, eliz@gnu.org, emacs-devel@gnu.org
> > Date: Mon, 22 Oct 2007 12:42:47 +0900
> >
> > read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
> > select-safe-coding-system-interactively(1 5557 (utf-8 ....))
> > select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
> > write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
> > ediff-make-temp-file(#<buffer *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
> > ediff-make-fine-diffs(5 noforce)
> > ediff-install-fine-diff-if-necessary(5)
> > ediff-next-difference(1)
> > call-interactively(ediff-next-difference)
> >
> > I don't know why ediff-make-temp-file is called, but perhaps
> > it should call write-region while binding
> > coding-system-for-write to `no-conversion' or `emacs-mule'.
> Not a good idea, I'm afraid: those temporary files (or parts thereof)
> will need to be read back, when `diff' finishes, so each one needs to
> be in the original encoding, or else the diffs will be incorrect.
> E.g., imagine two files with the same text, but different encodings: I
> don't think we want ediff say that they compare identical.
Perhaps you are right. I don't know what ediff is going to
write.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 4:20 ` Eli Zaretskii
2007-10-22 5:05 ` Kenichi Handa
@ 2007-10-22 15:32 ` Stefan Monnier
2007-10-22 21:11 ` Eli Zaretskii
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2007-10-22 15:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: dann, emacs-devel, kifer, Kenichi Handa
> Not a good idea, I'm afraid: those temporary files (or parts thereof)
> will need to be read back, when `diff' finishes, so each one needs to
> be in the original encoding, or else the diffs will be incorrect.
> E.g., imagine two files with the same text, but different encodings: I
> don't think we want ediff say that they compare identical.
Quite the contrary: it's the only right thing to do because we're comparing
two pieces of buffer (not file), so we want to deal with *any* char (even
those that will not be savable in the current buffer-file-coding-system) and
both files that we pass to `diff' will be temporaily created by ediff
anyway so that will also ensure they both use the same encoding.
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 15:32 ` Stefan Monnier
@ 2007-10-22 21:11 ` Eli Zaretskii
0 siblings, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2007-10-22 21:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: dann, emacs-devel, kifer, handa
> Cc: Kenichi Handa <handa@m17n.org>, dann@ics.uci.edu, kifer@cs.sunysb.edu,
> emacs-devel@gnu.org
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 22 Oct 2007 11:32:30 -0400
>
> > Not a good idea, I'm afraid: those temporary files (or parts thereof)
> > will need to be read back, when `diff' finishes, so each one needs to
> > be in the original encoding, or else the diffs will be incorrect.
> > E.g., imagine two files with the same text, but different encodings: I
> > don't think we want ediff say that they compare identical.
>
> Quite the contrary: it's the only right thing to do because we're comparing
> two pieces of buffer (not file)
I don't think ediff-make-temp-file knows that. It's a general-purpose
utility function in ediff, AFAIR, and is invoked for files as well.
Note: I was responding to Handa-san's suggestion that
ediff-make-temp-file binds coding-system-for-write.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-22 3:42 ` Kenichi Handa
2007-10-22 4:20 ` Eli Zaretskii
@ 2007-10-22 4:29 ` Michael Kifer
2007-10-22 15:34 ` Stefan Monnier
1 sibling, 1 reply; 24+ messages in thread
From: Michael Kifer @ 2007-10-22 4:29 UTC (permalink / raw)
To: Kenichi Handa; +Cc: eliz, Dan Nicolaescu, emacs-devel
> In article <200710211922.l9LJMQFX013338@oogie-boogie.ics.uci.edu>, Dan Nicolaescu <dann@ics.uci.edu> writes:
>
> > Can anybody else reproduce it? I don't know much about coding systems,
> > so unfortunately I can't really debug this myself.
>
> I can reproduce it when I run Emacs with LANG=C, and try to
> see the 5th (or 6th) different point where non-ASCII
> charaters exist. The calling sequence of read-coding-system
> is this:
>
> read-coding-system("Select coding system (default mule-utf-8): " mule-utf-8)
> select-safe-coding-system-interactively(1 5557 (utf-8 ....))
> select-safe-coding-system(1 5557 nil nil "/tmp/fineDiffA155544eB")
> write-region(1 5557 "/tmp/fineDiffA155544eB" nil no-message)
> ediff-make-temp-file(#<buffer *ediff-tmp*> "fineDiffA" "/tmp/fineDiffA155544eB")
> ediff-make-fine-diffs(5 noforce)
> ediff-install-fine-diff-if-necessary(5)
> ediff-next-difference(1)
> call-interactively(ediff-next-difference)
>
> I don't know why ediff-make-temp-file is called, but perhaps
> it should call write-region while binding
> coding-system-for-write to `no-conversion' or `emacs-mule'.
I still cannot reproduce this, but ediff-make-temp-file has been changed on
Aug 19 to use the coding system of the buffer for the temp file created out
of that buffer. This was in order to fix some other problem. Forgot which
-- it was on this list. The coding system of the buffer seems to be the
right thing. It was 'no-conversion before, but had a problem because those
temp files are then read back and no-conversion was screwing things up.
>
> ---
> Kenichi Handa
> handa@m17n.org
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 4:29 ` Michael Kifer
@ 2007-10-22 15:34 ` Stefan Monnier
2007-10-22 16:18 ` Michael Kifer
0 siblings, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2007-10-22 15:34 UTC (permalink / raw)
To: Michael Kifer; +Cc: eliz, Dan Nicolaescu, emacs-devel, Kenichi Handa
> I still cannot reproduce this, but ediff-make-temp-file has been changed on
> Aug 19 to use the coding system of the buffer for the temp file created out
> of that buffer. This was in order to fix some other problem. Forgot which
> -- it was on this list. The coding system of the buffer seems to be the
> right thing. It was 'no-conversion before, but had a problem because those
> temp files are then read back and no-conversion was screwing things up.
`no-conversion' is a bad choice (it only works for unibyte data). You want
`emacs-mule' (or rather `emacs-internal' but this one doesn't exist: I mean
by `emacs-internal' the encoding used internally, so it's `emacs-mule' in
Emacs22 but it will be different in Emacs23).
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-22 15:34 ` Stefan Monnier
@ 2007-10-22 16:18 ` Michael Kifer
0 siblings, 0 replies; 24+ messages in thread
From: Michael Kifer @ 2007-10-22 16:18 UTC (permalink / raw)
To: Stefan Monnier; +Cc: eliz, Dan Nicolaescu, emacs-devel, Kenichi Handa
> > I still cannot reproduce this, but ediff-make-temp-file has been changed on
> > Aug 19 to use the coding system of the buffer for the temp file created out
> > of that buffer. This was in order to fix some other problem. Forgot which
> > -- it was on this list. The coding system of the buffer seems to be the
> > right thing. It was 'no-conversion before, but had a problem because those
> > temp files are then read back and no-conversion was screwing things up.
>
> `no-conversion' is a bad choice (it only works for unibyte data). You want
> `emacs-mule' (or rather `emacs-internal' but this one doesn't exist: I mean
> by `emacs-internal' the encoding used internally, so it's `emacs-mule' in
> Emacs22 but it will be different in Emacs23).
Right, no-conversion had problems. So, should I use emacs-mule for now
and do something else in Emacs23?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ediff and coding systems
2007-10-20 15:21 ediff and coding systems Dan Nicolaescu
2007-10-20 18:09 ` Eli Zaretskii
@ 2007-10-21 2:12 ` Stefan Monnier
2007-10-21 2:43 ` Dan Nicolaescu
1 sibling, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2007-10-21 2:12 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: emacs-devel
> When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> for each hunk:
Can you try it with ediff-buffers? That should work (because ediff can
always save those buffers using emacs-mule coding system so both files will
have the same coding system, which is a necessary prerequisite to be able
to get meaningful diffs).
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ediff and coding systems
2007-10-21 2:12 ` Stefan Monnier
@ 2007-10-21 2:43 ` Dan Nicolaescu
0 siblings, 0 replies; 24+ messages in thread
From: Dan Nicolaescu @ 2007-10-21 2:43 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> > When doing M-x ediff for the above 2 files a *Warning* buffer pops up
> > for each hunk:
>
> Can you try it with ediff-buffers? That should work (because ediff can
> always save those buffers using emacs-mule coding system so both files will
> have the same coding system, which is a necessary prerequisite to be able
> to get meaningful diffs).
Makes no difference.
I have LANG set to C. If I set it to en_US.UTF-8 everything works fine...
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2007-10-28 21:01 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-10-20 15:21 ediff and coding systems Dan Nicolaescu
2007-10-20 18:09 ` Eli Zaretskii
2007-10-21 5:43 ` Michael Kifer
2007-10-21 6:12 ` Dan Nicolaescu
2007-10-21 6:52 ` Michael Kifer
2007-10-21 7:17 ` Dan Nicolaescu
2007-10-21 18:46 ` Michael Kifer
2007-10-21 19:22 ` Dan Nicolaescu
2007-10-21 19:37 ` Leo
2007-10-21 21:35 ` Michael Kifer
2007-10-22 2:08 ` Dan Nicolaescu
2007-10-22 3:50 ` Michael Kifer
2007-10-27 21:03 ` Dan Nicolaescu
2007-10-28 21:01 ` Michael Kifer
2007-10-22 3:42 ` Kenichi Handa
2007-10-22 4:20 ` Eli Zaretskii
2007-10-22 5:05 ` Kenichi Handa
2007-10-22 15:32 ` Stefan Monnier
2007-10-22 21:11 ` Eli Zaretskii
2007-10-22 4:29 ` Michael Kifer
2007-10-22 15:34 ` Stefan Monnier
2007-10-22 16:18 ` Michael Kifer
2007-10-21 2:12 ` Stefan Monnier
2007-10-21 2:43 ` Dan Nicolaescu
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).