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/