\201 back again

\201 back again

[Karl Eichwalder]

[-- Attachment #1: Type: text/plain, Size: 143 bytes --]

Please check why the insidious \201 markers did appear in this mail.  I
guess, some mail client forgot to provide proper MIME header entries:


[-- Attachment #2: Type: message/rfc822, Size: 693 bytes --]

From: Richard Stallman <rms@gnu.org>
To: miles@gnu.org
Cc: monnier+gnu/emacs@rum.cs.yale.edu, handa@etl.go.jp, emacs-devel@gnu.org
Subject: Re: re-search-forward seems to be broken
Date: Fri, 06 Sep 2002 16:03:04 -0400
Message-ID: <E17nPJo-0007UF-00@fencepost.gnu.org>

      (re-search-forward "[«»{}()]" nil t)

    I get:

      Lisp error: (wrong-type-argument arrayp nil)

I fixed this.  Thanks.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel


[-- Attachment #3: Type: text/plain, Size: 273 bytes --]



-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: \201 back again

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Sat, 07 Sep 2002 11:00:34 +0200
> 
> Please check why the insidious \201 markers did appear in this mail.

I don't see any \201 characters on my system in that mail message.
RMAIL correctly decodes it as Latin-9.

> I guess, some mail client forgot to provide proper MIME header
> entries:

Here's the header I see on my system:

  Content-Type: text/plain; charset=iso-8859-15

This is perfectly valid, AFAICS.

Re: \201 back again

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I don't see any \201 characters on my system in that mail message.
> RMAIL correctly decodes it as Latin-9.

Gnus does not.

>> I guess, some mail client forgot to provide proper MIME header
>> entries:
>
> Here's the header I see on my system:
>
>   Content-Type: text/plain; charset=iso-8859-15
>
> This is perfectly valid, AFAICS.

Maybe, some mail gateway did add those lines for you.

But these lines were missing from the original posting -- RMS never
ever bothers to add such stuff, I guess ;) :

From rms@gnu.org  Fri Sep  6 21:03:04 2002
From: rms@gnu.org (Richard Stallman)
Date: Fri, 06 Sep 2002 16:03:04 -0400
Subject: re-search-forward seems to be broken
In-Reply-To: <buo8z2g3paa.fsf_-_@mcspd15.ucom.lsi.nec.co.jp> (message from
 Miles Bader on 06 Sep 2002 10:00:45 +0900)
References: <200208230625.PAA23426@etlken.m17n.org>
 [...]
Message-ID: <E17nPJo-0007UF-00@fencepost.gnu.org>

Cf. http://mail.gnu.org/pipermail/emacs-devel/2002-September.txt (I
just verified it).

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: \201 back again

[ShengHuo ZHU]

Karl Eichwalder <keichwa@gmx.net> writes:

> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
>
>> I don't see any \201 characters on my system in that mail message.
>> RMAIL correctly decodes it as Latin-9.
>
> Gnus does not.
>
>>> I guess, some mail client forgot to provide proper MIME header
>>> entries:
>>
>> Here's the header I see on my system:
>>
>>   Content-Type: text/plain; charset=iso-8859-15
>>
>> This is perfectly valid, AFAICS.
>
> Maybe, some mail gateway did add those lines for you.
>
> But these lines were missing from the original posting -- RMS never
> ever bothers to add such stuff, I guess ;) :

Don't panic. The original email is emacs-mule encoded without the
content-type header. You can type `0 g emacs-mule RET' to fix it.

ShengHuo

Re: \201 back again

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Fri, 20 Sep 2002 19:04:47 +0200
> 
> > Here's the header I see on my system:
> >
> >   Content-Type: text/plain; charset=iso-8859-15
> >
> > This is perfectly valid, AFAICS.
> 
> Maybe, some mail gateway did add those lines for you.
> 
> But these lines were missing from the original posting -- RMS never
> ever bothers to add such stuff, I guess ;) :

Sorry,  I now see that I looked at a wrong message, not the one you
had in mind.

Richard's message indeed shows \201 characters, but that's only
because they were present in the message itself:

      (re-search-forward "[=C2=81=C2=AB=C2=81=C2=BB{}()]" nil t)

See those 0xC2 characters before each 8-bit Latin-9 code?

As for the encoding, it says this:

   Content-Type: text/plain; charset=utf-8

So the question now is how come Richard's Emacs sent such a badly
encoded message, and why did it think it was in UTF-8 when in fact it
was in emacs-mule?

Re: \201 back again

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> Richard's message indeed shows \201 characters, but that's only
> because they were present in the message itself:
>
>       (re-search-forward "[=C2=81=C2=AB=C2=81=C2=BB{}()]" nil t)
>
> See those 0xC2 characters before each 8-bit Latin-9 code?
>
> As for the encoding, it says this:
>
>    Content-Type: text/plain; charset=utf-8

The archived message lacks this line.  Rmail must learn to add proper
MIME header lines.

> So the question now is how come Richard's Emacs sent such a badly
> encoded message, and why did it think it was in UTF-8 when in fact it
> was in emacs-mule?

Maybe, Emacs asked whether the user wanted to use this "secure
encoding" -- the problem might go away automatically with 21.3 where
unification is enabled.


ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Don't panic. The original email is emacs-mule encoded without the
> content-type header. You can type `0 g emacs-mule RET' to fix it.

Thanks for tracking down the problem and telling a work around.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: \201 back again

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Sat, 21 Sep 2002 14:47:16 +0200
> 
> > As for the encoding, it says this:
> >
> >    Content-Type: text/plain; charset=utf-8
> 
> The archived message lacks this line.

I think the archiving scripts remove that line.

> Rmail must learn to add proper MIME header lines.

??? RMAIL should not add such headers, they should be present in the
original message.  In this case, the header is in the message, RMAIL
conceals it by default, but you can toggle that with the `t' RMAIL
command.

> > Don't panic. The original email is emacs-mule encoded without the
> > content-type header. You can type `0 g emacs-mule RET' to fix it.
> 
> Thanks for tracking down the problem and telling a work around.

The same effect can be achieved with RMAIL: see rmail-redecode-body.

Re: \201 back again

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> I think the archiving scripts remove that line.

The message I received also didn't contain it.  You said it were tagged
as "utf-8" -- but according to ShengHuo ZHU it was emacs-mule, not
UTF-8.

Also, please use uppercase letters for UTF-8 inside the MIME headers.

> ??? RMAIL should not add such headers, they should be present in the
> original message.

Sure.  I meant the mail composing/sending function.  I forgot, RMAIL is
for receiving messages only :-(

> The same effect can be achieved with RMAIL: see rmail-redecode-body.

Good.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: \201 back again

[Richard Stallman]

    As for the encoding, it says this:

       Content-Type: text/plain; charset=utf-8

    So the question now is how come Richard's Emacs sent such a badly
    encoded message, and why did it think it was in UTF-8 when in fact it
    was in emacs-mule?

I don't know where the Content-Type field came from, but certainly not
from Emacs.  sendmail.el doesn't know about them.

As for the strangeness of the encoding, I think that is coming from
the Emacs on fencepost that I am using to finally send my mail.
I should build the latest Emacs and use that instead.

Re: \201 back again

[Eli Zaretskii]

On Sat, 21 Sep 2002, Karl Eichwalder wrote:

> "Eli Zaretskii" <eliz@is.elta.co.il> writes:
> 
> > I think the archiving scripts remove that line.
> 
> The message I received also didn't contain it.  You said it were tagged
> as "utf-8" -- but according to ShengHuo ZHU it was emacs-mule, not
> UTF-8.

It was tagged as utf-8, but actually was encoded in emacs-mule.

Re: \201 back again

[Stefan Monnier]

> > > As for the encoding, it says this:
> > >    Content-Type: text/plain; charset=utf-8
> > The archived message lacks this line.
> I think the archiving scripts remove that line.

Bug alert!!


	Stefan

Re: \201 back again

[Andreas Schwab]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

|> > > > As for the encoding, it says this:
|> > > >    Content-Type: text/plain; charset=utf-8
|> > > The archived message lacks this line.
|> > I think the archiving scripts remove that line.
|> 
|> Bug alert!!

The message as I received it did not contain any MIME headers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."