viewing attachments

viewing attachments

[Katsumi Yamaoka]

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

Hello,

I had many opportunities to need to see attachments containing
non-ASCII text or parts which have been compressed by gzip or
bzip2.  ARISAWA Akihiro suggested one solution to make it handy;
it was setting of the `gnus-summary-show-article-charset-alist'
variable as follows:

(setq gnus-summary-show-article-charset-alist
      '((0 . undecided)
	(1 . shift_jis)
	(2 . iso-2022-7bit)
	(3 . euc-japan)
	(4 . utf-8)))

It is very useful, especially for Japanese.  I can see a part
containing Japanese text (e.g., it is an ELisp program, a patch,
etc.) by typing `0 i' (or `1 i', `2 i',...) on the part button.
Still, I had to save a compressed part to a file and to use the
`less' command or something in order to see it.

On the other hand, TSUCHIYA Masatoshi proposed an idea that Gnus
supports sending and receiving the MIME charsets even for
attachments.  It seemed to be useful although there aren't
necessarily the MIME charsets corresponding to all the coding
systems (for example, there's no MIME charset for the
iso-2022-7bit coding system which is used in the etc/HELLO file).

I hit on another idea while considering about it last week.  The
plan is to add the charset parameter to the MIME header of an
attachment part automatically if there is a coding cookie in the
file and the MIME charset corresponding to it exists.  Even if
it cannot be done automatically, Gnus should recognize the
charset parameter which a user may add to the MML tag manually.
And then, Gnus will be able to decode and display such a part in
which the charset parameter is specified.  In addition to this,
I also noticed Gnus can decode an attachment if the coding
cookie is there even if the charset parameter is not specified.

I've installed them (including decompressing of compressed parts)
in the Gnus trunk.  Here are two examples compressed by gzip and
bzip2.  You can see them by simply typing `i' at the part buttons.
The charset parameter in the first part was added manually, and
the one in the second part was added automatically.


[-- Attachment #2: t0.el.gz --]
[-- Type: application/x-gzip, Size: 137 bytes --]

[-- Attachment #3: t1.el.bz2 --]
[-- Type: application/x-bzip2, Size: 179 bytes --]

[-- Attachment #4: Type: text/plain, Size: 85 bytes --]

XEmacs users need the APEL XEmacs package or the original version
of APEL.

Regards,

Re: viewing attachments

[Kevin Ryde]

Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
> I had many opportunities to need to see attachments containing
> non-ASCII text or parts which have been compressed by gzip or
> bzip2.

Handa made a change to jka-compr in the emacs cvs (2003-01-24), adding
decode-coding-inserted-region which I believe is meant to do emacs'
usual charset guessing and priorities, like find-file.

I had meant to propose a patch (for gnus-mime-copy-part actually) to
make use of that, either by copying that code from the cvs, or just
using it if emacs is new enough to have it.  Unfortunately I never got
around to working out the details.

> I hit on another idea while considering about it last week.  The
> plan is to add the charset parameter to the MIME header of an
> attachment part automatically if there is a coding cookie in the
> file and the MIME charset corresponding to it exists.

If there's a cookie in the file, can't emacs just use that, without
needing a mime charset parameter?

> I've installed them (including decompressing of compressed parts)

Maybe you can use jka-compr the same way that
gnus-mime-jka-compr-maybe-uncompress does.  Or that function becomes
gnus-mime-copy-part-jka-insert with a patch I'm proposing - see other
message.  That would have the advantage of letting the user customize
compression methods.

Re: viewing attachments

[Katsumi Yamaoka]

>>>>> In <87acqgnf7s.fsf@zip.com.au> Kevin Ryde wrote:

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

>> I had many opportunities to need to see attachments containing
>> non-ASCII text or parts which have been compressed by gzip or
>> bzip2.

> Handa made a change to jka-compr in the emacs cvs (2003-01-24), adding
> decode-coding-inserted-region which I believe is meant to do emacs'
> usual charset guessing and priorities, like find-file.

I see.  The recent jka-compr uses `no-conversion' for reading
the output from the process which runs gzip, etc., and the
contents are decoded by `decode-coding-inserted-region'.  OTOH,
the earlier version uses `undecided' in order to decode the
contents while reading the output from the process.  That the
former is better is `decode-coding-inserted-region' recognizes
the coding cookies (and also `file-coding-system-alist').

> I had meant to propose a patch (for gnus-mime-copy-part actually) to
> make use of that, either by copying that code from the cvs, or just
> using it if emacs is new enough to have it.  Unfortunately I never got
> around to working out the details.

I'll look into the patch later.

>> I hit on another idea while considering about it last week.  The
>> plan is to add the charset parameter to the MIME header of an
>> attachment part automatically if there is a coding cookie in the
>> file and the MIME charset corresponding to it exists.

> If there's a cookie in the file, can't emacs just use that, without
> needing a mime charset parameter?

The principal object of that change was to enable users to add
the MIME charset manually for files which don't contain the
coding cookie.  I didn't make Emacs presume the coding system
since the auto-detection doesn't always work and Gnus should
never add the wrong charset.  Though recipients may use the
auto-decoding and it may work.

Furthermore, to add the MIME charset might be useful for
recipients who don't use Emacs, I think.

>> I've installed them (including decompressing of compressed parts)

> Maybe you can use jka-compr the same way that
> gnus-mime-jka-compr-maybe-uncompress does.

Hm, I didn't find an API of jka-compr which is suitable to that
purpose.  However, that I wasn't aware there's such a function
is the fact. ;-)  Now I want to integrate
`gnus-mime-jka-compr-maybe-uncompress' and `mm-decompress-buffer'
if it is possible.

> Or that function becomes
> gnus-mime-copy-part-jka-insert with a patch I'm proposing - see other
> message.  That would have the advantage of letting the user customize
> compression methods.

Thanks.  I will achieve them.

Re: viewing attachments

[Katsumi Yamaoka]

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

> Thanks.  I will achieve them.

I've achieved them roughly in my system.  It includes:

1. Make `gnus-mime-copy-part' handle the MIME charset or the
   coding cookie, and allow the prefix argument as `i' does,
   noting the multibyteness of the buffer and the contents.

2. Merge `gnus-mime-jka-compr-maybe-uncompress' into
  `mm-decompress-buffer'.

I will be able to install them in the Gnus trunk within
tomorrow.

Regards,

Re: viewing attachments

[Katsumi Yamaoka]

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

> 1. Make `gnus-mime-copy-part' handle the MIME charset or the
>    coding cookie, and allow the prefix argument as `i' does,
>    noting the multibyteness of the buffer and the contents.

> 2. Merge `gnus-mime-jka-compr-maybe-uncompress' into
>   `mm-decompress-buffer'.

> I will be able to install them in the Gnus trunk within
> tomorrow.

Done.

Re: viewing attachments

[Kevin Ryde]

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

On a foo.gz attachment, with auto-compression-mode disabled, using
copy-part to get a buffer and then saving that buffer produces a file
different from the original.

I think this didn't work before either, but I think it prompted for a
coding system before, which is always a good clue that something evil
is happening and you're likely to get garbage.

Personally I only ever save stuff with "o", but it'd be nice if
copy-part could work too.

Re: viewing attachments

[Katsumi Yamaoka]

>>>>> In <87is50vv4q.fsf@zip.com.au> 
>>>>>	Kevin Ryde <user42@zip.com.au> wrote:

> On a foo.gz attachment, with auto-compression-mode disabled, using
> copy-part to get a buffer and then saving that buffer produces a file
> different from the original.

I see.  I need to make the flag which shows that the compressed
part wasn't uncompressed.  It is used to not decode the part by
the MIME charset.

> I think this didn't work before either, but I think it prompted for a
> coding system before, which is always a good clue that something evil
> is happening and you're likely to get garbage.

> Personally I only ever save stuff with "o", but it'd be nice if
> copy-part could work too.

I will complete it.  But, sorry, I might be unable to grapple
with it at once because of the Japanese holiday.

Re: viewing attachments

[Katsumi Yamaoka]

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

>>>>>> In <87is50vv4q.fsf@zip.com.au> Kevin Ryde wrote:

>> On a foo.gz attachment, with auto-compression-mode disabled, using
>> copy-part to get a buffer and then saving that buffer produces a file
>> different from the original.

> I see.  I need to make the flag which shows that the compressed
> part wasn't uncompressed.  It is used to not decode the part by
> the MIME charset.

I've fixed it.  Sorry for being late.