Re: How can MH-E handle application/octet-stream ?

Re: How can MH-E handle application/octet-stream ?

[Reiner Steib]

[ From the MH-E list; Added Gnus list. ]

On Fri, May 13 2005, Bill Wohler wrote:

> Axel Jantsch <axel@imit.kth.se> writes:
>> I often get a pdf file (or other well known file types) with
>> application/octet-stream mime type. In MH-E such an attachment is
>> displayed as
>>
>> [2. Maj.pdf --- application/octet-stream; Maj.pdf]
>>
>> Although this is obviously a pdf file, MH-E does not know about it
>> and does not start a pdf reader.
[...]
> MH-E uses gnus to render its multimedia bits. I imagine that Gnus uses
> the Content-Type header field, not the Content-Disposition field
> (which contains the filename), for determining what viewer to use.

Yes.

> I've always just saved these files and launched gpdf separately, but I
> agree that's a pain.

In Gnus, you can use `v gpdf %s RET' on the button to launch gpdf.

> Perhaps a mechanism already exists, or perhaps they would be willing
> to put in a workaround. If so, please share it with us on mh-e-users
> mailing list. 

I'm not aware of a more simple solution or workaround in Gnus.  But if
someone wants to implement overriding of the Content-Type, it would be
nice to have it in the MIME library (mm*.el) so that MH-E and Gnus
could use it.

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


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: How can MH-E handle application/octet-stream ?

[Yair Friedman]

On Sun, 15 May 2005 18:24:12 +0200, 
Reiner Steib <reinersteib+gmane@imap.cc> writes:

> [ From the MH-E list; Added Gnus list. ]
>
> On Fri, May 13 2005, Bill Wohler wrote:
>
>> Axel Jantsch <axel@imit.kth.se> writes:
>>> I often get a pdf file (or other well known file types) with
>>> application/octet-stream mime type. In MH-E such an attachment is
>>> displayed as
>>>
>>> [2. Maj.pdf --- application/octet-stream; Maj.pdf]
>>>
>>> Although this is obviously a pdf file, MH-E does not know about it
>>> and does not start a pdf reader.
> [...]
>> MH-E uses gnus to render its multimedia bits. I imagine that Gnus uses
>> the Content-Type header field, not the Content-Disposition field
>> (which contains the filename), for determining what viewer to use.
>
> Yes.
>
>> I've always just saved these files and launched gpdf separately, but I
>> agree that's a pain.
>
> In Gnus, you can use `v gpdf %s RET' on the button to launch gpdf.
>
>> Perhaps a mechanism already exists, or perhaps they would be willing
>> to put in a workaround. If so, please share it with us on mh-e-users
>> mailing list. 

Usually in those cases I use gnus-mime-view-part-as-type which is bound to
Key "t" on the attachment button. Most of the time Gnus guesses
correctly the right type (based on extension?), if not auto-completion
works well enough.  

Re: How can MH-E handle application/octet-stream ?

[Axel Jantsch]

The gnus-mime-view-part-as-type would be what I would love to have, I
guess. But it is not available in the MH-E buffer now.

So the right thing would be to make the gnus-mime-view-part-as-type
functionality available as a command and key stroke from the MH-E
folder buffer?

Regards
Axel

Yair Friedman <yairfr@icts-tech.com> wrote:

> On Sun, 15 May 2005 18:24:12 +0200, 
> Reiner Steib <reinersteib+gmane@imap.cc> writes:
> 
> > [ From the MH-E list; Added Gnus list. ]
> >
> > On Fri, May 13 2005, Bill Wohler wrote:
> >
> >> Axel Jantsch <axel@imit.kth.se> writes:
> >>> I often get a pdf file (or other well known file types) with
> >>> application/octet-stream mime type. In MH-E such an attachment is
> >>> displayed as
> >>>
> >>> [2. Maj.pdf --- application/octet-stream; Maj.pdf]
> >>>
> >>> Although this is obviously a pdf file, MH-E does not know about it
> >>> and does not start a pdf reader.
> > [...]
> >> MH-E uses gnus to render its multimedia bits. I imagine that Gnus uses
> >> the Content-Type header field, not the Content-Disposition field
> >> (which contains the filename), for determining what viewer to use.
> >
> > Yes.
> >
> >> I've always just saved these files and launched gpdf separately, but I
> >> agree that's a pain.
> >
> > In Gnus, you can use `v gpdf %s RET' on the button to launch gpdf.
> >
> >> Perhaps a mechanism already exists, or perhaps they would be willing
> >> to put in a workaround. If so, please share it with us on mh-e-users
> >> mailing list. 
> 
> Usually in those cases I use gnus-mime-view-part-as-type which is bound to
> Key "t" on the attachment button. Most of the time Gnus guesses
> correctly the right type (based on extension?), if not auto-completion
> works well enough.  
> 


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click

Re: How can MH-E handle application/octet-stream ?

[Bill Wohler]

[Still plodding along...]

Axel Jantsch <axel@imit.kth.se> wrote:

> The gnus-mime-view-part-as-type would be what I would love to have, I
> guess. But it is not available in the MH-E buffer now.
> 
> So the right thing would be to make the gnus-mime-view-part-as-type
> functionality available as a command and key stroke from the MH-E
> folder buffer?

Axel,

When I get an application/octet-stream attachment, I use `K e'
(`mh-display-with-external-viewer') to view the attachment (also shown
in the quoted text below). I think this is a better solution than
expecting the user to select an appropriate MIME type.

Since the Gnus function does appear to do some guessing and provides
completion, if you have some reasonable use cases where an
mh-display-part-as-type function would be preferable to `K e' that I
haven't thought of, please lodge a feature request at SourceForge. If
others would prefer this function of `K e', it would be helpful if you
chimed in (on the feature request) as well.

> Yair Friedman <yairfr@icts-tech.com> wrote:
> 
> > On Sun, 15 May 2005 18:24:12 +0200, 
> > Reiner Steib <reinersteib+gmane@imap.cc> writes:
> > 
> > > [ From the MH-E list; Added Gnus list. ]
> > >
> > > On Fri, May 13 2005, Bill Wohler wrote:
> > >
> > >> Axel Jantsch <axel@imit.kth.se> writes:
> > >>> I often get a pdf file (or other well known file types) with
> > >>> application/octet-stream mime type. In MH-E such an attachment is
> > >>> displayed as
> > >>>
> > >>> [2. Maj.pdf --- application/octet-stream; Maj.pdf]
> > >>>
> > >>> Although this is obviously a pdf file, MH-E does not know about it
> > >>> and does not start a pdf reader.
> > > [...]
> > >> MH-E uses gnus to render its multimedia bits. I imagine that Gnus uses
> > >> the Content-Type header field, not the Content-Disposition field
> > >> (which contains the filename), for determining what viewer to use.
> > >
> > > Yes.
> > >
> > >> I've always just saved these files and launched gpdf separately, but I
> > >> agree that's a pain.
> > >
> > > In Gnus, you can use `v gpdf %s RET' on the button to launch gpdf.
> > >
> > >> Perhaps a mechanism already exists, or perhaps they would be willing
> > >> to put in a workaround. If so, please share it with us on mh-e-users
> > >> mailing list. 
> > 
> > Usually in those cases I use gnus-mime-view-part-as-type which is bound to
> > Key "t" on the attachment button. Most of the time Gnus guesses
> > correctly the right type (based on extension?), if not auto-completion
> > works well enough.  
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
> _______________________________________________
> mh-e-users mailing list
> mh-e-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mh-e-users
> 

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV