Gnus 5.9.0 - Arithmetic error

Gnus 5.9.0 - Arithmetic error

[François Pinard]

Hello!

Let me report an arithmetic error in Gnus 5.9.0, as within Emacs 21.2.92
(not official, this is a pretest version).  Given this summary:

---------------------------------------------------------------------->
021003 R# [  33: Tim Peters          ] RE: Re: PEP239 (Rational Numbers) Reference Implementation and new issues
021003  #     [  62: Oren Tirosh         ] 
020725  # [  24: Fernando Perez      ] Re: Float class with infinity and stuff, interval computations
000708    [  35: Adam DePrince       ] Re: 123.4+2=125.40000000000001
000607    [  45: Tim Peters          ] RE: math.exp underflow (was: exp behaviour: is it a bug ?)
000513    [  66: Tim Peters          ] RE: NaN again - and IEEE arithmatics
000515        [  58: Huaiyu Zhu          ] 
000516            [  72: Randall Hopper      ] 
000513        [  35: Mark C Favas        ] 
921207    [ 829: Hugo Graumann       ] Re: assign NaN to a variable ?
----------------------------------------------------------------------<

command `M P a' yields:

---------------------------------------------------------------------->
Debugger entered--Lisp error: (range-error "truncate" 40000000000001.0)
  format("%06d" 40000000000001.0)
  gnus-uu-expand-numbers((("Re: 123.4+2=125.40000000000001" . 7)) t)
  gnus-uu-find-articles-matching()
  gnus-uu-mark-series()
  gnus-uu-mark-all()
  call-interactively(gnus-uu-mark-all)
----------------------------------------------------------------------<

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Gnus 5.9.0 - Arithmetic error

[Kai Großjohann]

pinard@iro.umontreal.ca (François Pinard) writes:

> command `M P a' yields:
>
> ---------------------------------------------------------------------->
> Debugger entered--Lisp error: (range-error "truncate" 40000000000001.0)

Whee.

I think it will be very difficult to change Gnus to use strings as
article numbers instead of numbers.

Maybe it's easier to implement bignums in Emacs Lisp.

A workaround for your problem, of course, is to say something like `9
9 9 9 #'.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Gnus 5.9.0 - Arithmetic error

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1387 bytes --]

[Kai Großjohann]

> pinard@iro.umontreal.ca (François Pinard) writes:

> > command `M P a' yields:
> >
> > ---------------------------------------------------------------------->
> > Debugger entered--Lisp error: (range-error "truncate" 40000000000001.0)

> Whee.

> I think it will be very difficult to change Gnus to use strings as
> article numbers instead of numbers.

Did I ever ask for this?  I just wanted to mark all articles, quickly.
I often use it.

---------------------------------------------------------------------->
M P a runs the command gnus-uu-mark-all
   which is an interactive compiled Lisp function in `gnus-uu'.
(gnus-uu-mark-all)

Mark all articles in "series" order.
----------------------------------------------------------------------<

> Maybe it's easier to implement bignums in Emacs Lisp.  A workaround
> for your problem, of course, is to say something like `9 9 9 9 #'.

I am vaguely reading that you say that it is not a Gnus problem.  I would
not think Gnus should ever raise an Emacs error because the Subject line is
unexpected.  There is a lot of noise in the flurry of messages we receive,
and Gnus should be solid as rock against random subjects.  At first glance,
I would believe that `M P a' should mark all articles, as its name implies.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Gnus 5.9.0 - Arithmetic error

[Kai Großjohann]

pinard@iro.umontreal.ca (François Pinard) writes:

> I am vaguely reading that you say that it is not a Gnus problem.  I would
> not think Gnus should ever raise an Emacs error because the Subject line is
> unexpected.  There is a lot of noise in the flurry of messages we receive,
> and Gnus should be solid as rock against random subjects.  At first glance,
> I would believe that `M P a' should mark all articles, as its name implies.

Note that `M P a' comes from gnus-uu, which is intended for reading
binary groups.  The idea is that you get lots of messages with
subject lines like `Horny Gnusae.mpg (42/4711)'.  These might arrive out
of order, so there might be a `Lazy Lars.jpg (1/2)' in between them.
But `M P a' marks them in the `right' order.  That's the `series
order' part of the documentation.

So you can see that `M P a' has to parse the subject lines.

It might be useful to have a more generic mark-all-articles command.
It could mark in the order of the summary buffer, or by article
numbers, or something.

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Gnus 5.9.0 - Arithmetic error

[François Pinard]

[Kai Großjohann]

> Note that `M P a' comes from gnus-uu, which is intended for reading
> binary groups.  The idea is that you get lots of messages with subject
> lines like `Horny Gnusae.mpg (42/4711)'.  These might arrive out
> of order, so there might be a `Lazy Lars.jpg (1/2)' in between them.
> But `M P a' marks them in the `right' order.  That's the `series order'
> part of the documentation.

> So you can see that `M P a' has to parse the subject lines.

Granted, and thanks for the explanations.

Yet, Gnus `M P a' should nevertheless protect itself against arithmetic
errors while evaluating subjects, (with `condition-case'?) and maybe
merely ignore offending subjects just as it there were no numbers in it.
Ideally, there should not often be Emacs errors in "normal" Gnus usage. :-)

P.S. - I would have guessed that `M P a' and `M P b' abbreviate `-all' and
`-binary', but in fact, they are both `all', while `b' is for `-buffer'.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Gnus 5.9.0 - Arithmetic error

[Kai Großjohann]

pinard@iro.umontreal.ca (François Pinard) writes:

> Yet, Gnus `M P a' should nevertheless protect itself against arithmetic
> errors while evaluating subjects, (with `condition-case'?) and maybe
> merely ignore offending subjects just as it there were no numbers in it.
> Ideally, there should not often be Emacs errors in "normal" Gnus usage. :-)

You're right.

So I took a look and it seems that the function that's called is
gnus-uu-expand-numbers, and that function _does_ slap ignore-errors
around the calls to string-to-int and format.

Hm.

But I looked in Oort Gnus from CVS, not in Gnus 5.9.  Ah.  Yes, the
ignore-errors is missing from Gnus 5.9.

I'm not sure how to proceed now.  What do others say?  Do we put this
single fix in Gnus 5.9 or is Emacs 21.4 going to contain Gnus 5.11
anyway?

kai
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: Gnus 5.9.0 - Arithmetic error

[François Pinard]

[Kai Großjohann]

> I'm not sure how to proceed now.  What do others say?  Do we put
> this single fix in Gnus 5.9 or is Emacs 21.4 going to contain Gnus
> 5.11 anyway?

Note that the arithmetic error I reported is rather unusual.  I got it
_once_ over many years of Gnus usage and many, many hundreds of thousands
of articles.  Despite the correction is necessary, it is far from urgent.
Gnus 5.9 should of course receive "urgent" fixes, but Gnus is pretty
stable, there are not so many of those serious problems, all considered.

From having observed it more than once, I know that deadlines may scratch
quality.  The same way GNU packages may have to be rushed out in time
for some CD mastering, Gnus versions may have to meet Emacs releases...
Best is probably to let Oort Gnus mature, as comfortably as possible.

Nice theories, yet real life is usually not that simple.  Sigh! :-)

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Gnus 5.9.0 - Arithmetic error

[Jesper Harder]

pinard@iro.umontreal.ca (François Pinard) writes:

> I am vaguely reading that you say that it is not a Gnus problem.  I
> would not think Gnus should ever raise an Emacs error because the
> Subject line is unexpected.  There is a lot of noise in the flurry of
> messages we receive, and Gnus should be solid as rock against random
> subjects.  At first glance, I would believe that `M P a' should mark
> all articles, as its name implies.

`M P b' does (nearly) the same thing. 

It is faster and generally better unless you want to decode some
multipart binary.  Does `M P b' also trigger the error?

Re: Gnus 5.9.0 - Arithmetic error

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 545 bytes --]

[Jesper Harder]

> pinard@iro.umontreal.ca (François Pinard) writes:

> > At first glance, I would believe that `M P a' should mark all articles,
> > as its name implies.

> `M P b' does (nearly) the same thing.  It is faster and generally
> better unless you want to decode some multipart binary.  Does `M P b'
> also trigger the error?

`M P b' does not trigger the error on the offending article, and does
indeed mark all articles.  Thanks for the suggestion.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Gnus 5.9.0 - Arithmetic error

[Jesper Harder]

pinard@iro.umontreal.ca (François Pinard) writes:

> [Jesper Harder]
>
>> pinard@iro.umontreal.ca (Fran.ois Pinard) writes:
>
>> > At first glance, I would believe that `M P a' should mark all
>> > articles, as its name implies.
>
>> `M P b' does (nearly) the same thing.  It is faster and generally
>> better unless you want to decode some multipart binary.  Does `M P b'
>> also trigger the error?
>
> `M P b' does not trigger the error on the offending article, and does
> indeed mark all articles.  Thanks for the suggestion.

Maybe the documentation (especially the menu) should be improved.

It wasn't obvious to me that `M P b' was the command I really wanted to
use until I wondered why `M P a' was so slooow and looked at the code.

Re: Gnus 5.9.0 - Arithmetic error

[Matthias Andree]

pinard@iro.umontreal.ca (François Pinard) writes:

>> pinard@iro.umontreal.ca (Fran篩s Pinard) writes:
                                ^
I can smell utf-8 breakage here.... looks like some Chinese symbol.

-- 
Matthias Andree

UTF-8 breakage (was: Re: Gnus 5.9.0 - Arithmetic error)

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2724 bytes --]

[Matthias Andree]

> pinard@iro.umontreal.ca (François Pinard) writes:

> >> pinard@iro.umontreal.ca (Fran篩s Pinard) writes:
>                                 ^
> I can smell utf-8 breakage here.... looks like some Chinese symbol.

There was some breakage indeed.

I'm quoting below the edited copy I go for my own outgoing message,
after having replaced non-ASCII characters by `[0x...]' to make very
clear what they were.  From the headers, it seem that the message left
the place in quoted-printable.  Was it quoted-printable over UTF-8?
I cannot say.  Conversion back to 8 bits occurred automatically, and this
might have produced some Latin-1 characters.  I guess one needs a lot of
administrative power along the way to really trace down all this mess. :-)

The abnormality I see is that the message encoding is said to be UTF-8,
but the c-cedilla in the second line of attribution was Latin-1.  Surely,
it should have been UTF-8 there.  However, in the same message, the
c-cedilla in the signature seems correctly written in UTF-8.

Besides the various MTAs, it might be an Emacs or a Gnus problem.  Emacs is
surely a complex program for the poor little me, but Mule is an area within
Emacs where I feel particularily lost 1/2 :-).  I feel overwhelmed! :-)

---------------------------------------------------------------------->
X-From-Line: pinard@IRO.UMontreal.CA  Sun Nov 25 17:12:21 2002
[...]
Sender: pinard@sram.qc.ca
To: Jesper Harder <harder@ifa.au.dk>
Cc: ding@gnus.org
Subject: Re: Gnus 5.9.0 - Arithmetic error
[...]
From: pinard@IRO.UMontreal.CA (=?iso-8859-1?q?Fran=E7ois?= Pinard)
Date: 25 Nov 2002 17:12:21 -0500
In-Reply-To: <m37kf1qta8.fsf@defun.localdomain>
[...]
Message-ID: <oqel99ti2i.fsf@carouge.sram.qc.ca>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mercure.iro.umontreal.ca id gAPMCLO8020161
[...]

[Jesper Harder]

> pinard@iro.umontreal.ca (Fran[0xE7]ois Pinard) writes:

> > At first glance, I would believe that `M P a' should mark all articles,
> > as its name implies.

> `M P b' does (nearly) the same thing.  It is faster and generally
> better unless you want to decode some multipart binary.  Does `M P b'
> also trigger the error?

`M P b' does not trigger the error on the offending article, and does
indeed mark all articles.  Thanks for the suggestion.

-- 
Fran[0xC3A7]ois Pinard   http://www.iro.umontreal.ca/~pinard
----------------------------------------------------------------------<

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: UTF-8 breakage

[Matthias Andree]

pinard@iro.umontreal.ca (François Pinard) writes:

> I'm quoting below the edited copy I go for my own outgoing message,
> after having replaced non-ASCII characters by `[0x...]' to make very
> clear what they were.  From the headers, it seem that the message left
> the place in quoted-printable.  Was it quoted-printable over UTF-8?

Exactement ça.

I remember I was having a hard time at Oort Gnus 0.04 or 0.05 or 0.06
time of telling Gnus how to behave. I ended up with lots of packages,
but I did not document every failed try :-(, I now have

(require 'gnus-load)
(require 'custom)
(require 'un-define)
(require 'ucs-tables)
(ucs-unify-8859)
(unify-8859-on-encoding-mode t)
(unify-8859-on-decoding-mode t)

in my .emacs. I don't quite recall where all those files came from
(except Gnus, evidently) or whether these are still current. I believe I
grabbed Dave Love's ucs-tables.el from some *.sources or
de.comm.software*gnus newsgroup, and there may be duplication of
functionality.

The last two lines may even be utterly bogus...

-- 
Matthias Andree

Re: UTF-8 breakage

[Matthias Andree]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> I remember I was having a hard time at Oort Gnus 0.04 or 0.05 or 0.06
> time of telling Gnus how to behave. I ended up with lots of packages,
> but I did not document every failed try :-(, I now have
>
> (require 'gnus-load)
> (require 'custom)
> (require 'un-define)
> (require 'ucs-tables)
> (ucs-unify-8859)
> (unify-8859-on-encoding-mode t)
> (unify-8859-on-decoding-mode t)

It turned out that I also had to add and require utf-8 recently for
reasons I'm not going to investigate.

Thanks to Reiner Steib for his document about Gnus UTF-8 and ISO-8859-15
unification for just mentioning utf-8 .-)

-- 
Matthias Andree

Re: UTF-8 breakage

[Reiner Steib]

On Fri, Nov 29 2002, Matthias Andree wrote:

> Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:
[...]
>> (require 'ucs-tables)

I think (CMIIW) that you need either...

>> (ucs-unify-8859)

... or those two:

>> (unify-8859-on-encoding-mode t)
>> (unify-8859-on-decoding-mode t)

> It turned out that I also had to add and require utf-8 recently for
> reasons I'm not going to investigate.
>
> Thanks to Reiner Steib for his document about Gnus UTF-8 and ISO-8859-15
> unification for just mentioning utf-8 .-)

With Emacs 21.[1-3], you also need a newer version of utf-8.el and
load it with (load-library "utf-8"), see [1]:

| The version of `utf-8.el' shipped with 21.1 or 21.2 is _not_ sufficient.
| Moreover (because the code of `utf-8.el' is dumped into the emacs binary
| at build time), it's _not_ enough to replace `utf-8.el*' in the directory
| share/emacs/21.?/lisp/international by the new ones.

Bye, Reiner.

[1] <URL: http://my.gnus.org/Members/rsteib/howto_unify/>
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: UTF-8 breakage

[Simon Josefsson]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> [1] <URL: http://my.gnus.org/Members/rsteib/howto_unify/>

That seems useful.  Maybe it should say it is for Gnus 5.8 and Gnus
5.9?  I think Oort is supposed to unify at least across ISO-8859-*
automatically when possible (which included the example on the page).
But I don't use this often, so maybe it doesn't work any
longer...  let's see:

räksmörgås
r€ksm€rg€s

Re: UTF-8 breakage

[Lloyd Zusman]

Simon Josefsson <jas@extundo.com> writes:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>
>> [1] <URL: http://my.gnus.org/Members/rsteib/howto_unify/>
>
> That seems useful.  Maybe it should say it is for Gnus 5.8 and Gnus
> 5.9?  I think Oort is supposed to unify at least across ISO-8859-*
> automatically when possible (which included the example on the page).
> But I don't use this often, so maybe it doesn't work any
> longer...  let's see:
>
> räksmörgås
> r€ksm€rg€s

Well, I'm running under XEmacs 21.4.8, and I don't get the prompt that's
described in the web page.  Also, the vowels show up just fine.  So far,
so good.  However, for me, these vowels are being displayed in an
oversized, bolded font.

I can't find any faces that control this, and I'd like these letters to
show up non-bolded, and at the same size as the rest of the letters.

Any ideas as to how I can accomplish this?

Thanks in advance.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: UTF-8 breakage

[Kai Großjohann]

Lloyd Zusman <ljz@asfast.com> writes:

> Well, I'm running under XEmacs 21.4.8, and I don't get the prompt that's
> described in the web page.  Also, the vowels show up just fine.  So far,
> so good.  However, for me, these vowels are being displayed in an
> oversized, bolded font.

In Emacs, the key word to look for in the documentation is `font set'
(or `fontset' or `font-set'...).

I'm using the GNU intlfonts package, which sadly does not contain a
latin-9 font, so latin-9 characters always look somewhat odd in my
Emacs.

Does anyone happen to know a font which looks nice and has the same
size as -etl-fixed-medium-r-normal--16-160-72-72-c-80-iso8859-1?
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: UTF-8 breakage

[Simon Josefsson]

Lloyd Zusman <ljz@asfast.com> writes:

>> räksmörgås
>> r€ksm€rg€s
>
> Well, I'm running under XEmacs 21.4.8, and I don't get the prompt that's
> described in the web page.  Also, the vowels show up just fine.  So far,
> so good.  However, for me, these vowels are being displayed in an
> oversized, bolded font.

That indicates a missing font for the character.  Try

apt-get install `apt-cache search font|grep ^xfonts|awk '{print $1}'|sort|uniq|grep -v xfonts-bochs`

or something to that effect.

Re: UTF-8 breakage

[Lloyd Zusman]

Simon Josefsson <jas@extundo.com> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
>
>>> räksmörgås
>>> r€ksm€rg€s
>>
>> Well, I'm running under XEmacs 21.4.8, and I don't get the prompt that's
>> described in the web page.  Also, the vowels show up just fine.  So far,
>> so good.  However, for me, these vowels are being displayed in an
>> oversized, bolded font.
>
> That indicates a missing font for the character.  Try
>
> apt-get install `apt-cache search font|grep ^xfonts|awk '{print
> $1}'|sort|uniq|grep -v xfonts-bochs`
>
> or something to that effect.

Since I'm a non-Debian user, I'm not sure what the analog to "apt-get"
and "apt-cache" would be for me (RedHat 8.0).  I guess that what you're
saying is that I need to install all standard(?) fonts whose names start
with the string "xfonts", but not anything whose name contains the
string "xfonts-bochs".

Fair enough, but are there any fonts in particular that I should have?
At the moment, it will probably be easier for me to locate specific
fonts than to do the kind of global search-and-installation that you
suggested.

Of course, I could always just switch to Debian :) ...

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: UTF-8 breakage

[Ted Zlatanov]

On Sun, 01 Dec 2002, ljz@asfast.com wrote:
> Since I'm a non-Debian user, I'm not sure what the analog to
> "apt-get" and "apt-cache" would be for me (RedHat 8.0).  I guess
> that what you're saying is that I need to install all standard(?)
> fonts whose names start with the string "xfonts", but not anything
> whose name contains the string "xfonts-bochs".

(off-topic but the previous post did mention apt-cache)

You can get a very nice port of apt-get and friends (things like
apt-cache work just fine) from freshrpms.net.  I love it, it makes
system updates trivial through the freshrpms.net repository.  The GTK
frontend to apt-get "synaptic" is very clean and efficient.

Ted

Re: UTF-8 breakage

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Lloyd Zusman <ljz@asfast.com> writes:
>>
>> [ ... ]
>>
>> That indicates a missing font for the character.  Try
>>
>> apt-get install `apt-cache search font|grep ^xfonts|awk '{print
>> $1}'|sort|uniq|grep -v xfonts-bochs`
>>
>> or something to that effect.
>
> Since I'm a non-Debian user, I'm not sure what the analog to "apt-get"
> and "apt-cache" would be for me (RedHat 8.0).  [ ... ]
>
> Fair enough, but are there any fonts in particular that I should have?
> At the moment, it will probably be easier for me to locate specific
> fonts than to do the kind of global search-and-installation that you
> suggested.
>
> Of course, I could always just switch to Debian :) ...

Well, just to bring this issue to conclusion, I want to report that I
finally bit the bullet and switched to debian.  I then ran the command
above (or something very similar, actually), and the problem I mentioned
indeed went away.

And now that I'm debian-ized, I'm finding it a to be lot easier to keep
my system in a self-consistent state.  I heartily recommend this to
other non-debian linux users.

Thanks for your suggestion.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: UTF-8 breakage

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Lloyd Zusman <ljz@asfast.com> writes:
>
>>> räksmörgås
>>> r€ksm€rg€s

That's a very rich sandwich.

> apt-get install `apt-cache search font|grep ^xfonts|awk '{print $1}'|sort|uniq|grep -v xfonts-bochs`

Cool.  That fixed the problem for me, too.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: UTF-8 breakage

[Reiner Steib]

On Sun, Dec 01 2002, Simon Josefsson wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>
>> [1] <URL: http://my.gnus.org/Members/rsteib/howto_unify/>
>
> That seems useful.  Maybe it should say it is for Gnus 5.8 and Gnus
> 5.9?  

I didn't mention (and test) Gnus 5.8.8, because I though that it's not
recommended to use Emacs 21.x together with Gnus 5.8.8 (as Gnus 5.9 is
shipped with Emacs 21.x).

> I think Oort is supposed to unify at least across ISO-8859-*
> automatically when possible [...]
> räksmörgås
> r€ksm€rg€s

When I *dis*able unify-8859-on-{de,en}coding-mode and add a `ß'
(Latin-1) replying to your message, I get utf-8 (checked with
`mml-preview') instead of Latin-9.

In the German Gnus newsgroup, XEmacs users reported that it's possible
to get unification (with latin-unity) with XEmacs 21.4 + Oort but
_not_ with Gnus 5.8.8.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: UTF-8 breakage

[Simon Josefsson]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> On Sun, Dec 01 2002, Simon Josefsson wrote:
>
>> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>>
>>> [1] <URL: http://my.gnus.org/Members/rsteib/howto_unify/>
>>
>> That seems useful.  Maybe it should say it is for Gnus 5.8 and Gnus
>> 5.9?  
>
> I didn't mention (and test) Gnus 5.8.8, because I though that it's not
> recommended to use Emacs 21.x together with Gnus 5.8.8 (as Gnus 5.9 is
> shipped with Emacs 21.x).

Ah.  I was thinking of XEmacs users, but perhaps the page was about
Emacs only.

>> I think Oort is supposed to unify at least across ISO-8859-*
>> automatically when possible [...]
>> räksmörgås
>> r€ksm€rg€s
>
> When I *dis*able unify-8859-on-{de,en}coding-mode and add a `ß'
> (Latin-1) replying to your message, I get utf-8 (checked with
> `mml-preview') instead of Latin-9.

Do you instruct Emacs or Gnus to prefer UTF-8 anywhere?  I think the
unification is to the preferred charset.

Re: UTF-8 breakage

[Reiner Steib]

On Mon, Dec 02 2002, Simon Josefsson wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>> On Sun, Dec 01 2002, Simon Josefsson wrote:

>> I didn't mention (and test) Gnus 5.8.8, because I though that it's not
>> recommended to use Emacs 21.x together with Gnus 5.8.8 (as Gnus 5.9 is
>> shipped with Emacs 21.x).
>
> Ah.  I was thinking of XEmacs users, but perhaps the page was about
> Emacs only.

It is about Emacs only. For XEmacs, I only know that there's the
latin-unity package. But, as I mentioned in the last post, people
report that they can't get proper unification with XEmacs 21.4 and
Gnus 5.8.8.

>>> I think Oort is supposed to unify at least across ISO-8859-*
>>> automatically when possible [...] räksmörgås r€ksm€rg€s

>> When I *dis*able unify-8859-on-{de,en}coding-mode and add a `ß'
>> (Latin-1) replying to your message, I get utf-8 (checked with
>> `mml-preview') instead of Latin-9.
>
> Do you instruct Emacs or Gnus to prefer UTF-8 anywhere?  

No, at least not by purpose. I tested it with a minimal setup now:

- Starting Emacs 21.1 (LC_CTYPE=en_US.ISO_8859-1)
- reloading `utf-8', enable unify-8859-on-{de,en}coding-mode [0]
- start Oort Gnus
- replying to your message and inserting Latin-1 characters
- disable unify-8859-on-{de,en}coding-mode
- C-u C-c RET P
==> utf-8

- Starting Emacs 21.1 and Oort Gnus (LC_CTYPE=en_US.ISO_8859-1)
- replying to your message and inserting Latin-1 characters
  (LC_CTYPE=en_US.ISO_8859-1)
- C-u C-c RET P
==> Latin-9

> I think the unification is to the preferred charset.

It works (without unify-8-o-*-mode) sometimes, but not always:

- Starting Emacs 21.1 and Oort Gnus (LC_CTYPE=en_US.ISO_8859-1)
- Reply to news:m3fzthfiyl.fsf@merlin.emma.line.org (Article with a
  `ß' from Latin-9).
- insert a Latin-1 Currency sign or acute accent[1] (not codable in
  Latin-9!)
- C-u C-c RET P
==> "A message part needs to be split into 2 charset parts.  Really send?"

With unify-8-o-*-mode, I get unification to Latin-1.

- Starting Emacs 21.1 and Oort Gnus (LC_CTYPE=en_US.ISO_8859-1)
- start with a new article
- insert a Latin-1 `ä'
- insert a unicode € [2]
- C-u C-c RET P
==> "... split into 2 charset parts ..."
    --> charset=iso-8859-15 (Part 1)
    --> charset=charset=utf-8 (Part 2)

With unify-8-o-*-mode, I get unification to Latin-9 in this case.

So I think that even with Oort ucs-tables is still useful.

Bye, Reiner.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[0] This is what the file `rs-gnus-unify.el' does (apart from some tests).
    <URL: http://my.gnus.org/Members/rsteib/howto_unify/>
    
[1] (insert (string (make-char 'latin-iso8859-1 164))) ; CURRENCY SIGN
    (insert (string (make-char 'latin-iso8859-1 180))) ; ACUTE ACCENT

[2] (insert (string (make-char 'mule-unicode-0100-24ff 116 76))); EURO
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: UTF-8 breakage

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>
>> [1] <URL: http://my.gnus.org/Members/rsteib/howto_unify/>
>
> That seems useful.  Maybe it should say it is for Gnus 5.8 and Gnus
> 5.9?  I think Oort is supposed to unify at least across ISO-8859-*
> automatically when possible 

I didn't work for me with latin-3.  I needed the updated version of
utf-8.el to send latin-3 as utf-8.

Re: UTF-8 breakage

[Matthias Andree]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> With Emacs 21.[1-3], you also need a newer version of utf-8.el and
> load it with (load-library "utf-8"), see [1]:
>
> | The version of `utf-8.el' shipped with 21.1 or 21.2 is _not_ sufficient.
> | Moreover (because the code of `utf-8.el' is dumped into the emacs binary
> | at build time), it's _not_ enough to replace `utf-8.el*' in the directory
> | share/emacs/21.?/lisp/international by the new ones.

I find that section unclear, because it does not tell me what to do with
Emacs 21.1 or 21.2. Is "load-library" sufficient? Will I have to
recompile Emacs?

(BTW, I find 21.2 is considerably slower than 21.1, has this been
addresses by the CVS versions?)

-- 
Matthias Andree

Re: UTF-8 breakage

[Reiner Steib]

On Tue, Dec 10 2002, Matthias Andree wrote:

> Reiner Steib <4uce.02.r.steib@gmx.net> writes:
>
>> With Emacs 21.[1-3], you also need a newer version of utf-8.el and
>> load it with (load-library "utf-8"), see [1]:
>>
>> | The version of `utf-8.el' shipped with 21.1 or 21.2 is _not_ sufficient.
>> | Moreover (because the code of `utf-8.el' is dumped into the emacs binary
>> | at build time), it's _not_ enough to replace `utf-8.el*' in the directory
>> | share/emacs/21.?/lisp/international by the new ones.
>
> I find that section unclear, because it does not tell me what to do with
> Emacs 21.1 or 21.2. 

The cited section is *not* the whole story.  Is it still unclear, when
you read the rest (especially the "Preparation" and "Installation"
sections in [1])?  

I think it clearly says, that for Emacs 21.2 you need to install
`rs-gnus-unify.el', `utf-8.el' and `ucs-tables.el' and "(require
'rs-gnus-unify)"?  If not, could you please suggest improvements?

Shortened version of [1]:

;;; Preparation:

;; Required files for Emacs 21.1 or 21.2:
;;
;; - This file `rs-gnus-unify.el'.
;;
;; - `utf-8.el' and `ucs-tables.el'
[...]
;;   The version of `utf-8.el' shipped with 21.1 or 21.2 is _not_ sufficient.
[...]
;; Required files for Emacs 21.4 or later:
;;
;; - Emacs 21.4 (?) or later already contains suitable versions of `utf-8.el'
;; and `ucs-tables.el', so in that case you can omit downloading them
;; separately.
;;
;; - So you only need only this file: `rs-gnus-unify.el'.

;;; Installation:

;; Put `rs-gnus-unify.el' (together with `utf-8.el' and `ucs-tables.el' in
;; case of Emacs 21.[1-3]) in a directory that's at the beginning of your
;; `load-path', e.g. ~/lisp:
;;
;; (setq load-path (nconc (list ~/lisp) load-path))
;; 
;; To setup the unification, you'll need to put the following in your startup
;; file (usually ~/.emacs):
;;
;; (require 'rs-gnus-unify)
;;
;; That's all.

> Is "load-library" sufficient? 

Yes.

> Will I have to recompile Emacs?

No.

> (BTW, I find 21.2 is considerably slower than 21.1, has this been
> addresses by the CVS versions?)

I have no idea (I don't even have Emacs 21.2 installed).

Bye, Reiner.

[1] http://theotp1.physik.uni-ulm.de/~ste/comp/emacs/gnus/rs-gnus-unify.el
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo--- PGP key available via WWW   http://rsteib.home.pages.de/

Re: UTF-8 breakage

[Kai Großjohann]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> I find that section unclear, because it does not tell me what to do with
> Emacs 21.1 or 21.2. Is "load-library" sufficient? Will I have to
> recompile Emacs?

Doing load-library on it is sufficient, but require is not.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)