mm-fill-flowed and f=f article decoding

mm-fill-flowed and f=f article decoding

[Ralf Angeli]

Hi everybody,

for some time now I am seeing format=flowed articles not being decoded
anymore.  The result is, that e.g. raw quoted-printable or UTF-8
characters are displayed in the article buffer of respective
messages.  Obviously the raw characters will get yanked into a reply
to those articles as well.

Katsumi Yamaoka[1] already identified the cause for it in
<URL:http://article.gmane.org/gmane.emacs.gnus.general/58678>.  As I
customized `mm-fill-flowed' to nil, the change mentioned in this
article prevents decoding of f=f articles for me.

It would be great if this could be corrected.


Footnotes: 
[1] I am always unsure which one is the first name and which the
surname in Japanese names.

-- 
Ralf

OT: Japanese names (was Re: mm-fill-flowed and f=f article decoding)

[Katsumi Yamaoka]

>>>>> In <cjtlk1$sqd$1@sea.gmane.org> Ralf Angeli wrote:

> Katsumi Yamaoka[1]

> Footnotes: 
> [1] I am always unsure which one is the first name and which the
> surname in Japanese names.

Katsumi is my first name, but we usually say in Japan the family
name first.  If we write our names in the Japanese style, we often
use upper case letters for the family name like YAMAOKA Katsumi.
Almost Japanese people call me Yamaoka or Yamaoka-san, not Katsumi,
though foreign friends normally call me Katsumi.  I don't mind
which of them you use. ;-)

Re: OT: Japanese names

[Ralf Angeli]

* Katsumi Yamaoka (2004-10-05) writes:

>>>>>> In <cjtlk1$sqd$1@sea.gmane.org> Ralf Angeli wrote:
>
>> Katsumi Yamaoka[1]
>
>> Footnotes: 
>> [1] I am always unsure which one is the first name and which the
>> surname in Japanese names.
>
> Katsumi is my first name, but we usually say in Japan the family
> name first.  If we write our names in the Japanese style, we often
> use upper case letters for the family name like YAMAOKA Katsumi.
> Almost Japanese people call me Yamaoka or Yamaoka-san, not Katsumi,
> though foreign friends normally call me Katsumi.  I don't mind
> which of them you use. ;-)

Thanks for the clarification. (c:

-- 
Ralf

Re: mm-fill-flowed and f=f article decoding

[Xavier Maillard]

On  5 oct 2004, Ralf Angeli wrote:

> Hi everybody,

Yo,
 
> for some time now I am seeing format=flowed articles not being
> decoded anymore. The result is, that e.g. raw quoted-printable
> or UTF-8 characters are displayed in the article buffer of
> respective messages. Obviously the raw characters will get
> yanked into a reply to those articles as well.

Yeah, I had the same problem and fixed it setting mm-fill-flowed
to t (as it is per default). Without this customization, results
was poor and people were crying :/
 
> Katsumi Yamaoka[1] already identified the cause for it in
> <URL:http://article.gmane.org/gmane.emacs.gnus.general/58678>.
> As I customized `mm-fill-flowed' to nil, the change mentioned
> in this article prevents decoding of f=f articles for me.
> 
> It would be great if this could be corrected.

??
-- 
Xavier MAILLARD (GnuPG: 1024D/1E028EA5)
EmacsOS user (http://emacsfr.org)
APRIL (http://www.april.org)

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

>>>>> In <cjtlk1$sqd$1@sea.gmane.org> Ralf Angeli wrote:

> for some time now I am seeing format=flowed articles not being decoded
> anymore.  The result is, that e.g. raw quoted-printable or UTF-8
> characters are displayed in the article buffer of respective
> messages.  Obviously the raw characters will get yanked into a reply
> to those articles as well.

> Katsumi Yamaoka[1] already identified the cause for it in
> <URL:http://article.gmane.org/gmane.emacs.gnus.general/58678>.  As I
> customized `mm-fill-flowed' to nil, the change mentioned in this
> article prevents decoding of f=f articles for me.

> It would be great if this could be corrected.

I believe I've fixed it.  When the change which caused the
problem was made[1] in order to let Gnus handle PGP signed
format=flowed articles as multipart messages, Simon left a
comment as follows:

>>>>> In <iluacwswsgq.fsf@latte.josefsson.org> Simon Josefsson wrote:

> ;; FIXME: This is a kludge.  Proper fix is to make gnus-display-mime
> ;; invoke mm-uu-dissect on all textual MIME parts, and stop using
> ;; mm-fill-flowed here.

I only worked just like that.

[1] http://news.gmane.org/group/gmane.emacs.gnus.general/thread=58293

Re: mm-fill-flowed and f=f article decoding

[Ralf Angeli]

* Katsumi Yamaoka (2004-10-06) writes:

>>>>>> In <cjtlk1$sqd$1@sea.gmane.org> Ralf Angeli wrote:
>
>> for some time now I am seeing format=flowed articles not being decoded
>> anymore.  The result is, that e.g. raw quoted-printable or UTF-8
>> characters are displayed in the article buffer of respective
>> messages.  Obviously the raw characters will get yanked into a reply
>> to those articles as well.
>
>> Katsumi Yamaoka[1] already identified the cause for it in
>> <URL:http://article.gmane.org/gmane.emacs.gnus.general/58678>.  As I
>> customized `mm-fill-flowed' to nil, the change mentioned in this
>> article prevents decoding of f=f articles for me.
>
>> It would be great if this could be corrected.
>
> I believe I've fixed it.  When the change which caused the
> problem was made[1] in order to let Gnus handle PGP signed
> format=flowed articles as multipart messages

The display of quoted-printable articles and the like is correct
again.  I don't know about the PGP signed articles, though.

Thank you very much.

-- 
Ralf

Re: mm-fill-flowed and f=f article decoding

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I believe I've fixed it.  When the change which caused the
> problem was made[1] in order to let Gnus handle PGP signed
> format=flowed articles as multipart messages, Simon left a
> comment as follows:
>
>>>>>> In <iluacwswsgq.fsf@latte.josefsson.org> Simon Josefsson wrote:
>
>> ;; FIXME: This is a kludge.  Proper fix is to make gnus-display-mime
>> ;; invoke mm-uu-dissect on all textual MIME parts, and stop using
>> ;; mm-fill-flowed here.
>
> I only worked just like that.
>
> [1] http://news.gmane.org/group/gmane.emacs.gnus.general/thread=58293

Nice!  Thanks.  Perhaps it should apply mm-uu-dissect on text/.*,
instead of only text/plain, though, but that's a quibble.  I'll test
it now...

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> In <<ilu7jq4mf8x.fsf@latte.josefsson.org> Simon Josefsson wrote:

> Nice!  Thanks.  Perhaps it should apply mm-uu-dissect on text/.*,
> instead of only text/plain, though, but that's a quibble.  I'll test
> it now...


This is <bold>just</bold> an examle (inline PGP + text/enriched).
I've never seen an article like this, though. ;-)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBY9L3LGVAwA4tiLkRAhOGAKCU977aDfKgp42kiKYEfakDyycrdwCfTCth
2JQIwOarvgqvweWzrRa3YaM=
=hALq
-----END PGP SIGNATURE-----

Re: mm-fill-flowed and f=f article decoding

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>>> In <ilu7jq4mf8x.fsf@latte.josefsson.org> Simon Josefsson wrote:
>> Nice!  Thanks.  Perhaps it should apply mm-uu-dissect on text/.*,
>> instead of only text/plain, though, but that's a quibble.  I'll test
>> it now...
>
> This is just an examle (inline PGP + text/enriched).  I've never seen
> an article like this, though. ;-)

Your message was flowed, which might cause the inline PGP detection
code to fail.  But why was it flowed?  Is that the right thing for
text/enriched?  I forget.

OTOH, I can't get simpler text/plain samples to work.  See gnus.test
tests.  Any ideas?

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

>>>>> In <ilu3c0s9h5n.fsf@latte.josefsson.org> 
>>>>>	Simon Josefsson <jas@extundo.com> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> This is just an examle (inline PGP + text/enriched).  I've never seen
>> an article like this, though. ;-)

> Your message was flowed, which might cause the inline PGP detection
> code to fail.  But why was it flowed?  Is that the right thing for
> text/enriched?  I forget.

I also felt it's strange.  I'll look into it tomorrow.

> OTOH, I can't get simpler text/plain samples to work.  See gnus.test
> tests.  Any ideas?

Do you mean you weren't successful to verify the sign?  That
looks right to me, though I presently don't have your public
key.  BTW, I'm using the following:

(setq gnus-buttonized-mime-types '("multipart/signed"))

Re: mm-fill-flowed and f=f article decoding

[Simon Josefsson]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> OTOH, I can't get simpler text/plain samples to work.  See gnus.test
>> tests.  Any ideas?
>
> Do you mean you weren't successful to verify the sign?  That
> looks right to me, though I presently don't have your public
> key.  BTW, I'm using the following:
>
> (setq gnus-buttonized-mime-types '("multipart/signed"))

The messages aren't fill-flowed for me.  So it seems there is no MIME
processing on the internal part.

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

>>>>> In <iluhdp798rf.fsf@latte.josefsson.org> Simon Josefsson wrote:

>> Do you mean you weren't successful to verify the sign?

> The messages aren't fill-flowed for me.  So it seems there is no MIME
> processing on the internal part.

Yup!  We have to pass MIME parameters to mm-uu-dissect in some
way.  I need to grapple with it...

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> In <b9y8yajl8l8.fsf@jpl.org> Katsumi Yamaoka wrote:

> Yup!  We have to pass MIME parameters to mm-uu-dissect in some 
> way.  I need to grapple with it...

I've done so.  This also fixes another bug; a non-ascii article
like this was not decoded since the `gnus-decoded' charset does
not always mean the part has been decoded.

Ｃａｎ ｙｏｕ ｒｅａｄ ｔｈｉｓ ｌｉｎｅ？
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBZOwnLGVAwA4tiLkRAjN5AJwO81xVLC+GfmVJMCP2RY4t9hcDUwCgh2Le
+hFR9whKlalPBdMIvgF/oZY=
=W3zx
-----END PGP SIGNATURE-----

Re: mm-fill-flowed and f=f article decoding

[Ralf Angeli]

* Katsumi Yamaoka (2004-10-07) writes:

>>>>>> In <b9y8yajl8l8.fsf@jpl.org> Katsumi Yamaoka wrote:
>
>> Yup!  We have to pass MIME parameters to mm-uu-dissect in some 
>> way.  I need to grapple with it...
>
> I've done so.  This also fixes another bug; a non-ascii article
> like this was not decoded since the `gnus-decoded' charset does
> not always mean the part has been decoded.
>
> Ｃａｎ ｙｏｕ ｒｅａｄ ｔｈｉｓ ｌｉｎｅ？

I can read it.

BTW, the article <news:b9ybrfg5c4c.fsf@jpl.org> in this thread is
still getting flowed.

-- 
Ralf

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

>>>>> In <ck2s98$jd4$1@sea.gmane.org>
>>>>>	Ralf Angeli <dev.null@iwi.uni-sb.de> wrote:

>> Ｃａｎ ｙｏｕ ｒｅａｄ ｔｈｉｓ ｌｉｎｅ？

> I can read it.

> BTW, the article <news:b9ybrfg5c4c.fsf@jpl.org> in this thread is
> still getting flowed.

Thanks.  I'll look into how text/enriched articles should be shown.

Re: mm-fill-flowed and f=f article decoding

[Katsumi Yamaoka]

>>>>> In <b9yy8ijx8qc.fsf@jpl.org> Katsumi Yamaoka wrote:

>> BTW, the article <news:b9ybrfg5c4c.fsf@jpl.org> in this thread is
>> still getting flowed.

> Thanks.  I'll look into how text/enriched articles should be shown.

In that article, newlines are handled specially.  It won't be
called flowed.  RFC1896 has made reference as follows about it.

Line break rules

    Line breaks (CRLF pairs in standard network representation)
    are handled specially.  In particular, isolated CRLF pairs
    are translated into a single SPACE character.  Sequences of
    N consecutive CRLF pairs, however, are translated into N-1
    actual line breaks...

In addition to this, long lines are broken by `enriched-decode'
simply using `fill-region'.  It is the reason why that article
looks funny.

BTW, I've changed mm-uu so that it might support all text types
as Simon suggested at the beginning:

>>>>> In <ilu7jq4mf8x.fsf@latte.josefsson.org> Simon Josefsson wrote:

> Perhaps it should apply mm-uu-dissect on text/.*, instead of
> only text/plain, though, but that's a quibble.

fetching pubkeys (was Re: mm-fill-flowed and f=f article decoding)

[Katsumi Yamaoka]

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

>>>>> In <yotlacuzubqk.fsf@jpl.org> Katsumi Yamaoka wrote:

> ...though I presently don't have your public key.

BTW, I remembered I can fetch GnuPG public keys semi-automatically.
This was given by courtesy of ARISAWA Akihiro.

(setq pgg-query-keyserver t
      pgg-insert-url-function #'w3m-retrieve)

To use it, You need to have emacs-w3m installed.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: fetching pubkeys

[Reiner Steib]

On Thu, Oct 07 2004, Katsumi Yamaoka wrote:

> (setq pgg-query-keyserver t
>       pgg-insert-url-function #'w3m-retrieve)
>
> To use it, You need to have emacs-w3m installed.

Shouldn't w3m-retrieve should be autoloaded (==> w3m-load.el)?  It
isn't in emacs-w3m-version 1.4.0.88.

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

Re: fetching pubkeys

[Katsumi Yamaoka]

>>>>> In <v98yaihoms.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

>> (setq pgg-query-keyserver t
>>       pgg-insert-url-function #'w3m-retrieve)

> Shouldn't w3m-retrieve should be autoloaded (==> w3m-load.el)?  It
> isn't in emacs-w3m-version 1.4.0.88.

I've added the autoload cookie.  Thanks.

Re: fetching pubkeys

[Jochen Küpper]

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

On Thu, 07 Oct 2004 17:08:20 +0900 Katsumi Yamaoka wrote:

>>>>>> In <yotlacuzubqk.fsf-NvgVpDro27E@public.gmane.org> Katsumi Yamaoka wrote:

>> ...though I presently don't have your public key.

Katsumi> BTW, I remembered I can fetch GnuPG public keys semi-automatically.
Katsumi> This was given by courtesy of ARISAWA Akihiro.

I use the following, how's your w3m solution "better"?
,----[gpg.conf]
| keyserver-options auto-key-retrieve
`----

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: fetching pubkeys

[Xavier Maillard]

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

On  7 oct 2004, Jochen Küpper wrote:

> On Thu, 07 Oct 2004 17:08:20 +0900 Katsumi Yamaoka wrote:
> 
> > > > > > > In <yotlacuzubqk.fsf@jpl.org> Katsumi Yamaoka wrote:
> 
> > > ...though I presently don't have your public key.
> 
> Katsumi> BTW, I remembered I can fetch GnuPG public keys
> Katsumi> semi-automatically. This was given by courtesy of
> Katsumi> ARISAWA Akihiro.
> 
> I use the following, how's your w3m solution "better"?
> ,----[gpg.conf]
> > keyserver-options auto-key-retrieve
> `----

Same here. Same question too :/

-- 
Xavier Maillard, zedek@gnu-rox.org


[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: fetching pubkeys

[Katsumi Yamaoka]

>>>>> In <plop87mzyyb5bf.fsf@gnu-rox.org> Xavier Maillard wrote:

> On  7 oct 2004, Jochen Küpper wrote:

>> I use the following, how's your w3m solution "better"?
>> ,----[gpg.conf]
>>> keyserver-options auto-key-retrieve
>> `----

> Same here. Same question too :/

Oops.  I completely forgot GnuPG itself can do that.  It may be
because it was impossible behind the firewall in the PGP2 (or
possibly PGP5) era.  Now I saw it works with no problem even at
the office.  My configuration for that is:

keyserver-options auto-key-retrieve
keyserver http://subkeys.pgp.net:11371
honor-http-proxy

Now, I lost the meaning of using emacs-w3m for it. ;-)
Thank you very much.

Re: fetching pubkeys

[Xavier Maillard]

On  8 oct 2004, Katsumi Yamaoka wrote:

> > > > > > In <plop87mzyyb5bf.fsf@gnu-rox.org> Xavier Maillard wrote:
> 
> > On  7 oct 2004, Jochen Küpper wrote:
> 
> > > I use the following, how's your w3m solution "better"?
> > > ,----[gpg.conf]
> > > > keyserver-options auto-key-retrieve
> > > `----
> 
> > Same here. Same question too :/
> 
> Oops.  I completely forgot GnuPG itself can do that.  It may be
> because it was impossible behind the firewall in the PGP2 (or
> possibly PGP5) era.  Now I saw it works with no problem even at
> the office.  My configuration for that is:
> 
> keyserver-options auto-key-retrieve
> keyserver http://subkeys.pgp.net:11371
> honor-http-proxy
> 
> Now, I lost the meaning of using emacs-w3m for it. ;-)
> Thank you very much.

No problem :/ You solution is quite cool too. I personnaly love,
just to use Emacs (and derived) for all sort of stuff.
-- 
Xavier Maillard

main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}