10:11 p.m.
>>>> "Reiner" == Reiner Steib
<reinersteib+gmane(a)imap.cc> writes:
Reiner> I don't see any reason not to improve compatibility in `mm*.el'
Reiner> for XEmacs (MULE or non-MULE). But since most of the currently
Reiner> active Gnus developers don't use XEmacs, I'm afraid this won't
Reiner> happen unless you (i.e. XEmacs developers and users) contribute
Reiner> patches or concrete proposals.
I'm willing to help as best I can, but I could use some clues, either
from the gnus or XEmacs folks.
mm-coding-system-p appears to be trying to figure out what coding system
interface to use, with the choices being find-coding-system,
coding-system-p, and mm-get-coding-system-list. Are any of these
standard Emacs or XEmacs interfaces?
The docstring for mm-coding-system-p says it returns "a coding system
object in XEmacs". The XEmacs Lisp reference talks about coding
systems, under MULE. Does that mean that coding system objects only
exist in MULE XEmacs? What should (mm-coding-system-p 'iso-8859-1)
return in non-MULE XEmacs?
mike
11:22 p.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
On Sun, Feb 19 2006, Mike Kupfer wrote:
mm-coding-system-p appears to be trying to figure out what coding
system
interface to use,
[ This is the relevant code: ]
,----[ `mm-util.el' ]
| (defun mm-coding-system-p (cs)
| "Return non-nil if CS is a symbol naming a coding system.
| In XEmacs, also return non-nil if CS is a coding system object.
| If CS is available, return CS itself in Emacs, and return a coding
| system object in XEmacs."
| (if (fboundp 'find-coding-system)
| (and cs (find-coding-system cs))
| (if (fboundp 'coding-system-p)
| (when (coding-system-p cs)
| cs)
| ;; Is this branch ever actually useful?
| (car (memq cs (mm-get-coding-system-list))))))
`----
So "Is this branch ever actually useful?" is used in non-MULE XEmacs.
with the choices being find-coding-system, coding-system-p, and
mm-get-coding-system-list. Are any of these standard Emacs or
XEmacs interfaces?
`coding-system-p' is a standard Emacs interface:
,----[ (info "(elisp)Lisp and Coding Systems") ]
| -- Function: coding-system-p object
| This function returns `t' if OBJECT is a coding system name or
| `nil'.
`----
The function `find-coding-system' doesn't exist in Emacs 21/22.
In case it wasn't obvious: mm-coding-system-list (the function) is
aliased to "ignore" if (fbound 'coding-system-list) is nil.
Leaving this for the XEmacs folks...
The docstring for mm-coding-system-p says it returns "a coding
system
object in XEmacs". The XEmacs Lisp reference talks about coding
systems, under MULE. Does that mean that coding system objects only
exist in MULE XEmacs? What should (mm-coding-system-p 'iso-8859-1)
return in non-MULE XEmacs?
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
7:41 a.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
>>>> In <v9irrb9bna.fsf(a)marauder.physik.uni-ulm.de>
Reiner Steib wrote:
Leaving this for the XEmacs folks...
> The docstring for mm-coding-system-p says it returns "a coding system
> object in XEmacs". The XEmacs Lisp reference talks about coding
> systems, under MULE. Does that mean that coding system objects only
> exist in MULE XEmacs? What should (mm-coding-system-p 'iso-8859-1)
> return in non-MULE XEmacs?
I have five XEmacsen installed. Those are:
1. 21.4.19 with mule with file-coding
2. 21.4.19 with mule without file-coding
3. 21.4.19 without mule without file-coding
4. 21.5-b24 with mule with file-coding
5. 21.5-b24 without mule with file-coding
Only 3 doesn't have coding system functions including
`decode-coding-string', `encode-coding-region', etc., and mm-util
makes them all aliases to `identity', `ignore' or equivalents.
Even so, if I understand it correctly, that version of XEmacs
displays 8-bit data as Latin-1 characters. For example:
(insert "\310")
È
(mm-decode-coding-string "\310" 'iso-8859-1)
"È"
(mm-decode-coding-string "\310" 'any-coding-system)
"È"
The last example suggests we can make `mm-coding-system-p' return
any value, that is, it doesn't have to be a coding system object.
Actually, the following form works:
(let ((mm-coding-system-list '(iso-8859-1)))
(rfc2047-decode-string
"=?ISO-8859-1?Q?Ignacio_Marambio_Cat=E1n?="))
"Ignacio Marambio Catán"
So, changing
(defvar mm-coding-system-list nil)
to
(defvar mm-coding-system-list '(iso-8859-1))
in mm-util.el will solve at least the problem that Mike Kupfer
first brought up. Is there any coding systems which should be
added to the default value other than iso-8859-1 that XEmacs
without mule without file-coding supports?
I'm not sure it solves all problems with Gnus and that version
of XEmacs, though.
9:40 a.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
>>>> In <b4mirrao4t0.fsf(a)jpl.org> Katsumi Yamaoka
wrote:
So, changing
(defvar mm-coding-system-list nil)
to
(defvar mm-coding-system-list '(iso-8859-1))
in mm-util.el will solve at least the problem that Mike Kupfer
first brought up.
That's a wrong approach. It should be something like:
(defvar mm-coding-system-list nil)
(defun mm-get-coding-system-list ()
"Get the coding system list."
(or mm-coding-system-list
(setq mm-coding-system-list
(or (mm-coding-system-list) '(iso-8859-1)))))
Is there any coding systems which should be added to the
default value other than iso-8859-1 that XEmacs without mule
without file-coding supports?
11:30 a.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
At last I realized the problem is due to my change:
2005-10-19 Katsumi Yamaoka <yamaoka(a)jpl.org>
* rfc2047.el (rfc2047-allow-incomplete-encoded-text): New variable.
(rfc2047-charset-to-coding-system): New function.
(rfc2047-decode-encoded-words): New function.
(rfc2047-decode-region): Use them.
(rfc2047-decode-cte): Remove.
(rfc2047-parse-and-decode): Remove.
(rfc2047-decode): Remove.
Formerly `rfc2047-decode' didn't verify whether a given charset
is valid, while `rfc2047-charset-to-coding-system' (which merged
the feature of `rfc2047-decode' partially) does it now using
`mm-coding-system-p'. However, it should be left to
`mm-charset-to-coding-system' even if it is incomplete[1] now.
Therefore, I've made a change in both the trunk and the v5-10
branch.
[1] The form (mm-charset-to-coding-system 'foo-bar-baz) returns
foo-bar-baz in non-Mule XEmacs 21.4.
The following diff is for the latest Gnus XEmacs package:
2006-02-20 Katsumi Yamaoka <yamaoka(a)jpl.org>
* rfc2047.el (rfc2047-charset-to-coding-system): Don't check the
coding system which mm-charset-to-coding-system returns for a
given charset is valid.
--- rfc2047.el~ 2005-12-19 22:31:44 +0000
+++ rfc2047.el 2006-02-20 11:29:44 +0000
＠＠ -835,7 +835,7 ＠＠
(cond ((eq cs 'ascii)
(setq cs (or (mm-charset-to-coding-system mail-parse-charset)
'raw-text)))
- ((setq cs (mm-coding-system-p cs)))
+ ((mm-coding-system-p cs))
((and charset
(listp mail-parse-ignored-charsets)
(memq 'gnus-unknown mail-parse-ignored-charsets))
8:46 a.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
>>>> "Reiner" == Reiner Steib
<reinersteib+gmane(a)imap.cc> writes:
Reiner> In case it wasn't obvious: mm-coding-system-list (the
Reiner> function) is aliased to "ignore" if (fbound
Reiner> 'coding-system-list) is nil.
So mm-coding-system-p passes nil back to Gnus.
Reiner> Leaving this for the XEmacs folks...
> What should (mm-coding-system-p 'iso-8859-1) return in
non-MULE
> XEmacs?
nil, according to Reiner's description of the design. So Gnus is
receiving nil as a result from an internal Gnus function, and refusing
to handle that value, which eventually results in an error and buggy
display.
This is definitely not an XEmacs problem---it's all internal to Gnus.
So I guess Reiner is saying that no-MULE XEmacs is not supported by
Gnus any more.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
9:41 a.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
On Mon, Feb 20 2006, Stephen J. Turnbull wrote:
>>>>> "Reiner" == Reiner Steib
<reinersteib+gmane(a)imap.cc> writes:
Reiner> In case it wasn't obvious: mm-coding-system-list (the
Reiner> function) is aliased to "ignore" if (fbound
Reiner> 'coding-system-list) is nil.
So mm-coding-system-p passes nil back to Gnus.
Yes, this is what the current mm-util.el code does in Mike's XEmacs.
Reiner> Leaving this for the XEmacs folks...
>> What should (mm-coding-system-p 'iso-8859-1) return in non-MULE
>> XEmacs?
nil, according to Reiner's description of the design. So Gnus is
receiving nil as a result from an internal Gnus function, and refusing
to handle that value, which eventually results in an error and buggy
display.
Huh, I didn't describe the design, I only described the current code.
I don't know if the current code is correct for XEmacs or gives the
desired result there.
This is definitely not an XEmacs problem---it's all internal to
Gnus.
So I guess Reiner is saying that no-MULE XEmacs is not supported by
Gnus any more.
Stephen, I don't understand this finger pointing. It doesn't bring us
any further. If you look at Gnus' ChangeLog you won't find any
changes aiming to stop supporting no-MULE XEmacs. There are only very
few XEmacs specific changes in that area, AFAICS. Most of these were
patches from Aidan WRT latin-unity (I don't know if those are
responsible for Mike's problems or not). If support of no-MULE XEmacs
has been broken, it wasn't done on purpose and as I wrote in my
previous mail, I'm all for fixing it if someone gives us an idea how
to fix it.
BTW, we are talking about the Gnus 5.10.x series which (compared to
5.10.1) should not contain any new features (only bugfixes). We
didn't even officially drop support for Emacs 20.7 and XEmacs 21.1, see
<http://thread.gmane.org/v9y80ega32.fsf_-_＠marauder.physik.uni-ulm.de>;.
But I doubt that anyone verified that the current v5-10 branch works
on these Emacsen.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
3:52 p.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
>>>> "Reiner" == Reiner Steib
<reinersteib+gmane(a)imap.cc> writes:
Reiner> Huh, I didn't describe the design,
OK. Can you point me to a design document?
> This is definitely not an XEmacs problem---it's all internal
to
> Gnus.
> So I guess Reiner is saying that no-MULE XEmacs is not
> supported by Gnus any more.
Reiner> Stephen, I don't understand this finger pointing.
You described a situation that clearly is entirely a Gnus problem,
then said "it's up to the XEmacs guys." You can't say you support
XEmacs and at the same time pass the buck that way.
BTW, there's nothing wrong with abandoning support for legacy code, or
telling the users that they have to support it themselves. You've got
a finite amount of time, and maybe you've got something better to do
with that time than to deal with the legacy no-Mule configuration that
_your_ Emacs hasn't supported for about 4 years now. I understand
that, and I'm sure Mike does too, even if we don't like it.
I'd just like to be able to tell Mike where he stands.
Reiner> I'm all for fixing it if someone gives us an idea how to
Reiner> fix it.
Fortunately, Katsumi Yamaoka, has something to say about the issue.
So it's a Gnus developer who's going to fix it after all.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
9:26 p.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
Christ Stephen, stop being so damn pissy...
-miles
--
Come now, if we were really planning to harm you, would we be waiting here,
beside the path, in the very darkest part of the forest?
9:14 a.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
Ar an fichiú lá de mí Feabhra, scríobh Reiner Steib>:
Stephen, I don't understand this finger pointing. It doesn't
bring us
any further. If you look at Gnus' ChangeLog you won't find any
changes aiming to stop supporting no-MULE XEmacs. There are only very
few XEmacs specific changes in that area, AFAICS. Most of these were
patches from Aidan WRT latin-unity (I don't know if those are
responsible for Mike's problems or not).
All my Gnus code that touches on latin-unity is wrapped in this (it’s in the
mm-xemacs-find-mime-charset-1 function):
(defmacro mm-xemacs-find-mime-charset (begin end)
(when (featurep 'xemacs)
`(and (featurep 'mule) (mm-xemacs-find-mime-charset-1 ,begin ,end))))
So on non-Mule systems, it won’t be touched, and there shouldn’t be
behavioural changes from the old code, which is as it should be.
On fr.lettres.langue.francaise, there are subject lines like this from a
participant using Gnus v5.10.7 on XEmacs 21.4.17 (from
http://groups.google.com/groups?selm=m2wte3cbiw.fsf＠baba.ba ):
=?us-ascii?Q?=3D=3Fiso-8859-1=3Fq=3FRe=3A=5FEtymon=5F=5B=3DE9?=
=?us-ascii?Q?tait=5F=3A=5FRe=3A=5Fquestion=5Fd'un=5Fd=3DE9butant=5Fen=5Fd?=
=?us-ascii?Q?actylographie=5D=3F=3D?=
Which is broken, clearly (it’s a double encoding which shouldn’t be
happening).
However, I can’t reproduce that double encoding with 21.4.17, the latest
XEmacs package Gnus (and xemacs -vanilla) , and nor can I reproduce the
described problem with RFC 2047-encoded user names not being decoded, they
work fine for me (even ISO-8859-15 encoded names are decoded, which is
probably broken.) If someone can come up with a more detailed recipe, I’ll
be happy to look into it.
If support of no-MULE XEmacs has been broken, it wasn't done on
purpose
and as I wrote in my previous mail, I'm all for fixing it if someone
gives us an idea how to fix it.
--
In the beginning God created the heavens and the earth. And God was a
bug-eyed, hexagonal smurf with a head of electrified hair; and God said:
“Si, mi chiamano Mimi...”
7:35 p.m.
New subject: [Bug: 21.4.18] gnus 5.10.7 not rendering Latin-1 headers
On Sun, Apr 09 2006, Aidan Kehoe wrote:
Ar an fichiú lá de mí Feabhra, scríobh Reiner Steib>:
> Stephen, I don't understand this finger pointing. It doesn't bring us
> any further. If you look at Gnus' ChangeLog you won't find any
> changes aiming to stop supporting no-MULE XEmacs. There are only very
> few XEmacs specific changes in that area, AFAICS. Most of these were
> patches from Aidan WRT latin-unity (I don't know if those are
> responsible for Mike's problems or not).
All my Gnus code that touches on latin-unity is wrapped in this (it’s in the
mm-xemacs-find-mime-charset-1 function):
(defmacro mm-xemacs-find-mime-charset (begin end)
(when (featurep 'xemacs)
`(and (featurep 'mule) (mm-xemacs-find-mime-charset-1 ,begin ,end))))
So on non-Mule systems, it won’t be touched, and there shouldn’t be
behavioural changes from the old code, which is as it should be.
Yes, it turned out that a change in `rfc2047.el' caused it, see
http://article.gmane.org/gmane.emacs.gnus.general/62033.
On fr.lettres.langue.francaise, there are subject lines like this
from a
participant using Gnus v5.10.7 on XEmacs 21.4.17 (from
http://groups.google.com/groups?selm=m2wte3cbiw.fsf＠baba.ba ):
=?us-ascii?Q?=3D=3Fiso-8859-1=3Fq=3FRe=3A=5FEtymon=5F=5B=3DE9?=
=?us-ascii?Q?tait=5F=3A=5FRe=3A=5Fquestion=5Fd'un=5Fd=3DE9butant=5Fen=5Fd?=
=?us-ascii?Q?actylographie=5D=3F=3D?=
Which is broken, clearly
Yes.
| User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (darwin)
Does this XEmacs have MULE? Maybe we should add something to the
User-Agent in `gnus-extended-version' if (featurep 'mule) is nil.
Here's another example:
,----[ <news:mzez3i0p.fsf＠nemo.im.schnuerpel.net> ]
| From: Sabine 'Sani' Schulz <heitschi.bumbeitschi.bumbum(a)albasani.net>
| Newsgroups: de.comm.software.newsreader
| Subject: Re: =?us-ascii?Q?=3D=3FISO-8859-15=3FQ=3FMesNews=5Ff=3DFCr=5FAnf?=
| =?us-ascii?Q?=3DE4nger=5Fgeeignet=3D3F=3F=3D?=
| Date: Wed, 05 Apr 2006 22:05:26 +0200
| User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.13 (windows-nt)
`----
(it’s a double encoding which shouldn’t be happening).
Double encoding is necessary, e.g. if the user types the following
Subject:
| Subject: Ich hab' da mal 'ne Fräge: Was bedeuten denn diese Zeichen
=?ISO-8859-15?Q?=F6?= ?
However, I can’t reproduce that double encoding with 21.4.17, the
latest
XEmacs package Gnus (and xemacs -vanilla) ,
Did you try with a no-MULE XEmacs? Could there be a difference
between an XEmacs without MULE on Windows and GNU/Linux?
and nor can I reproduce the described problem with RFC 2047-encoded
user names not being decoded, they work fine for me (even
ISO-8859-15 encoded names are decoded, which is probably broken.)
This has been fixed in Gnus CVS. It should also be fixed in
xemacs-pkg-1_90.
BTW, will anyone sync the XEmacs Gnus package to Gnus 5.10.8 (released
today)? Is the Position still Vacant? See
<http://article.gmane.org/gmane.emacs.xemacs.beta/22341>;.
If someone can come up with a more detailed recipe, I’ll be happy to
look into it.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
6800
days inactive
6851
days old
10 comments
6 participants
participants (6)
-
Aidan Kehoe -
Katsumi Yamaoka -
Mike Kupfer -
Miles Bader -
Reiner Steib -
Stephen J. Turnbull