Those MIME requirements

Those MIME requirements

[Lars Magne Ingebrigtsen]

>From Steinar's (ouch. it hurts to use an apostrophe before the
posessive "s" after Norwegian names) list of MIME requirements.

(I've skipped the composition reqs.)

> ******
> REQ-1 - automatic decoding of text
> I would like automatic decoding of q-b or base64 encoded text/plain 
> message parts
> (19980825 Steinar Bang <sb@metis.no>)

Check.

> ******
> REQ-2 - inline image attachments
> I would like to view images (JPEG, GIF, PNG) inline in the message
> (19980825 Steinar Bang <sb@metis.no>)

Check.

> ******
> REQ-3 - saving image attachments
> I would like a simple way to save image attachments
> (19980825 Steinar Bang <sb@metis.no>)

Check.

> ******
> REQ-4 - navigation in multipart/mixed messages
> I would like a simple way of navigating through a multipart
> message, and view and save the parts.  I rather like the current TM
>  behaviour for this
> (19980825 Steinar Bang <sb@metis.no>)

How does TM navigate through the multipart/mixed messages?

> ******
> REQ-5 - display of text/html
> I would like to see text/html message parts formatted inline in the
> message (using W3, I guess), both where they are the only alternative,
> and where they are part of a multipart/alternative
> (19980825 Steinar Bang <sb@metis.no>)

Don't w3 have to display things in its own buffer?  Anyway, 0.27 will
display html with w3 in a separate buffer, which brings up the
question: How is Gnus supposed to display things that are displayed by 
Emacs, but not in the article buffer?  Gnus has to pop up a new
buffer, but is that buffer supposed to replace the article buffer, or
what? 

> ******
> REQ-6 - toggle between text/html and text/plain
> I would like to be easily able to toggle between text/plain and
> text/html parts of a multipart/alternative
> (19980825 Steinar Bang <sb@metis.no>)

Ooh.  multipart/alternative.  It's not handled exactly the same way as 
multipart/mixed, which is obviously not good, but I can't visualize
how this is supposed to look with the current buttonized scheme.

> ******
> REQ-7 - replying to text/html
> I would like to be able to reply to a text/html message part as if it
> had been a text/plain message (ie. I would like to see the HTML
> formatted into plain text before it's taken into a *message* buffer
> and quoted)
> (19980825 Steinar Bang <sb@metis.no>)

And this goes for all things that Emacs display, but not in the
article buffer (see REQ-5).  Or?

> ******
> REQ-8 - formatted MSWord documents shown inline
> I would like attached MSWord documents to be shown inline as the
> results of catdoc or other filter, while keeping it easy to save the
> MSWord file to disk
> (19980825 Steinar Bang <sb@metis.no>)

Sure.  Send me rules to plonk into `mailcap-mime-data' (as default
settings) for doing this and other wonderful things.  (I mean --
displaying weird formats and stuff.)

> ******
> REQ-9 - prompt for filename when saving attachments
> I would like to be prompted for directory and filename, when saving
> attachments 
> (19980825 Alan Shutko <ats@acm.org>)
> (19980825 Jan Vroonhof <vroonhof@math.ethz.ch>)

Check.

> ******
> REQ-10 - implement everything in elisp
> I would like the MIME support in Gnus to be completely implemented in
> elisp, and to rely on external programs only as a speedup option
> (19980825 Jan Vroonhof <vroonhof@math.ethz.ch>)

Check.  Well, it relies on C-layer support to speed things up.  base64 
de/encoding in C will be in Emacs 20.4, for instance.

> ******
> REQ-11 - extract part to buffer
> I would like to be able to extract a message part to an emacs buffer
> (19980825 Jan Vroonhof <vroonhof@math.ethz.ch>)

Fix in Pterodactyl Gnus v0.27.

> ******
> REQ-12 - use richest format by default
> I presume the best bet is automatically using the richest format possible
> in a given environment, or at least, have user options stating preferences.
> Manual intervention could be required to alter the choice (a bit like there
> are washing commands to alter presentation after the fact, even if these
> commands are hook-able), but I would not say that having such commands for
> selection among alternative MIME parts would make Gnus less interesting.
> All the contrary: it's better having a choice than none.  Yet, selection
> among alternative parts should be automated by default.
> (19980825 François Pinard <pinard@iro.umontreal.ca>)

I've now added a `mm-alternative-precedence' variable that would
determine which alternative part is to be displayed, but the way to
display the "other" parts has to be worked out.

> ******
> REQ-16 - display of message parts
> The user can configure what MIME types should be displayed inline
> (meaning that it is either displayed in a buffer or directly via an
> external program). [VM behaviour]
> (19980826 Kees de Bruin <kees_de_bruin@tasking.com>)

Check.

> ******
> REQ-17 - saving message parts
> For non-inline MIME types buttons are generated the user can use to save
> the MIME part to a file, or open it in some external viewer. [VM behaviour]
> (19980826 Kees de Bruin <kees_de_bruin@tasking.com>)

Check

> ******
> REQ-18 - message parts converted into plain text
> Alternative display of MIME messages: plain text (no conversions), using
> inline display, or all buttons. [VM behaviour]
> (19980826 Kees de Bruin <kees_de_bruin@tasking.com>)

Check.  (I think.)

> ******
> REQ-19 - handling of MIME digests
> I would like Gnus to handle MIME digests [a closer description, maybe?]
> (19980826 Kees de Bruin <kees_de_bruin@tasking.com>)

nndoc takes care of this.  

> ******
> REQ-20 - integration of MIME support with nnimap
> I would like the MIME support to cooperate with the upcoming
> nnimap, in such a way that loading of attachments can be delayed
> until you actually wish to show or save it (delay the download of
> that 5MB PowerPoint file your boss sent you (real example: it
> happened to me today) until you can plug your laptop into the LAN at
> work)
> (19980826 Steinar Bang <sb@metis.no>)

That would be nice.

> ******
> REQ-21 - handling of message-internal URIs
> In some MIME type, like vcard, there is a possible to make special URL
> beginning with cid:...
> These relate to other MIME attachement of the same message. It would be
> nice for the people developping MIME types extension that Gnus provides
> function to handles these URL smoothly.
> (19980826 Jean-Yves Perrier <perrier@nagra-kudelski.ch>)

In what way are these used?

> ******
> REQ-22 - a choice when handling attachments
> I would like nice handling of file attachments.  There should be a 
> choice whether you want to save the attachment (and it should query
> for a file name), view the attachment in an Emacs buffer, or start
> an external command on the attachment.
> (19980826 Hrvoje Niksic <hniksic@srce.hr>)

Check.

> ******
> REQ-23 - support for mailcap
> I would like support for .mailcap.  This is important, as well-configured
> systems (such as Debian Linux releases) are actually using mailcaps to
> specify external programs associated to various document formats.  I 
> haven't looked at Bill's code, so I don't know how applicable it is.
> (19980826 Hrvoje Niksic <hniksic@srce.hr>)
> I think mailcap/mimetype support is fundamental.
> (19980826 Simon Josefsson <jas@pdc.kth.se>)

Check.

> ******
> REQ-24 - support for RFC2047 in headers
> I would like support for decoding/encoding of RFC2047 headers.  This is
> partially connected with Mule, but not necessarily.
> (19980826 Hrvoje Niksic <hniksic@srce.hr>)

Check.

> ******
> REQ-27 - mailcap support for elisp
> I would like mailcap files to be able to execute emacs lisp functions
> on the contents of a message part.
> (19980826 Jean-Yves Perrier <perrier@nagra-kudelski.ch>)

application/emacs-lisp will eval Emacs Lisp functions.  (After asking, 
of course.)  Is that what you mean?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Lars Magne Ingebrigtsen said:

  Lars> How does TM navigate through the multipart/mixed messages?

You can move from one button to the next with `n'.  There's `p', too.
And SPC is like n except if the current part extends beyond
window-end, then it's like C-v.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@ifi.uio.no>:

>> ******
>> REQ-4 - navigation in multipart/mixed messages
>> I would like a simple way of navigating through a multipart
>> message, and view and save the parts.  I rather like the current TM
>> behaviour for this
>> (19980825 Steinar Bang <sb@metis.no>)

> How does TM navigate through the multipart/mixed messages?

You use the command "v" (for "view") in the summary buffer, which puts 
you in the buttonized article buffer, where you can skip backwards and
forwards between message parts, by using "p" and "n".

When you're standing on a message part, "x" will save the contents to
a file, after decoding any CTE, and "v" will play it using an external 
method.

"q" takes you back to the summary buffer.

It has a feel similar to dired.

>> ******
>> REQ-5 - display of text/html
>> I would like to see text/html message parts formatted inline in the
>> message (using W3, I guess), both where they are the only alternative,
>> and where they are part of a multipart/alternative
>> (19980825 Steinar Bang <sb@metis.no>)

> Don't w3 have to display things in its own buffer?  Anyway, 0.27 will
> display html with w3 in a separate buffer, which brings up the
> question: How is Gnus supposed to display things that are displayed by 
> Emacs, but not in the article buffer?  Gnus has to pop up a new
> buffer, but is that buffer supposed to replace the article buffer, or
> what? 

Hm... I don't know.  I sort of thought of w3 just formatting the HTML, 
and inserting it into the displayed message, fonts and all.

But obviously this won't work for live links, and images and stuff.

Is it possible to make w3 use part of a buffer, that is handed to it
by Gnus? Bill...?

>> ******
>> REQ-6 - toggle between text/html and text/plain
>> I would like to be easily able to toggle between text/plain and
>> text/html parts of a multipart/alternative
>> (19980825 Steinar Bang <sb@metis.no>)

> Ooh.  multipart/alternative.  It's not handled exactly the same way as 
> multipart/mixed, which is obviously not good, but I can't visualize
> how this is supposed to look with the current buttonized scheme.

How about a menu, or some way of cycling through the alternatives when
you're standing on top of a buttonized message part?

>> ******
>> REQ-7 - replying to text/html
>> I would like to be able to reply to a text/html message part as if it
>> had been a text/plain message (ie. I would like to see the HTML
>> formatted into plain text before it's taken into a *message* buffer
>> and quoted)
>> (19980825 Steinar Bang <sb@metis.no>)

> And this goes for all things that Emacs display, but not in the
> article buffer (see REQ-5).  Or?

Basically I would just like to be able to read and reply to messages
sent in HTML, with a minimum of intrusion.  If this breaks down to
always using the text/plain part of a multipart/alternative or
formatting text/html into plain text before displaying when you don't
have a simpler alternative, that's OK for now (at least for me).

Inline W3 handling of HTML is really a luxury item, that can wait for
later (but it sure would nice if we could swing it :-) ).

>> ******
>> REQ-8 - formatted MSWord documents shown inline
>> I would like attached MSWord documents to be shown inline as the
>> results of catdoc or other filter, while keeping it easy to save the
>> MSWord file to disk
>> (19980825 Steinar Bang <sb@metis.no>)

> Sure.  Send me rules to plonk into `mailcap-mime-data' (as default
> settings) for doing this and other wonderful things.  (I mean --
> displaying weird formats and stuff.)

OK. Will research and do sometime next week (if somebody doesn't beat
me to it)

Great work so far, Lars! I'm impressed at the speed of implementation! :-)


- Steinar

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen <larsi@ifi.uio.no>:

  Lars> Ooh.  multipart/alternative.  It's not handled exactly the
  Lars> same way as multipart/mixed, which is obviously not good, but
  Lars> I can't visualize how this is supposed to look with the
  Lars> current buttonized scheme.

>>>>> On 11 Sep 1998, Steinar Bang said:

  Steinar> How about a menu, or some way of cycling through the
  Steinar> alternatives when you're standing on top of a buttonized
  Steinar> message part?

Right.  Nice idea.  Do it like Custom does for its buffers: on mouse
press, pop up a menu.  On keypress, pop up a buffer displaying the
choices.  Of course, it should be mouse-2 and RET, I think.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Lars Magne Ingebrigtsen <larsi@ifi.uio.no>:
>>> ******
>>> REQ-4 - navigation in multipart/mixed messages
>>> I would like a simple way of navigating through a multipart
>>> message, and view and save the parts.  I rather like the current TM
>>> behaviour for this
>>> (19980825 Steinar Bang <sb@metis.no>)

>> How does TM navigate through the multipart/mixed messages?

> You use the command "v" (for "view") in the summary buffer, which puts 
> you in the buttonized article buffer, where you can skip backwards and
> forwards between message parts, by using "p" and "n".

> When you're standing on a message part, "x" will save the contents to
> a file, after decoding any CTE, and "v" will play it using an external 
> method.

Sorry! "e" is the "extract contents to file", command of TM.
(my fingers remembered, when my head forgot)

> "q" takes you back to the summary buffer.

> It has a feel similar to dired.

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> > How does TM navigate through the multipart/mixed messages?
> 
> You use the command "v" (for "view") in the summary buffer, which puts 
> you in the buttonized article buffer, where you can skip backwards and
> forwards between message parts, by using "p" and "n".
> 
> When you're standing on a message part, "x" will save the contents to
> a file, after decoding any CTE, and "v" will play it using an external 
> method.

Is this satisfactory?  I'd really like not to leave the summary
buffer, but I don't quite see how...

> > Ooh.  multipart/alternative.  It's not handled exactly the same way as 
> > multipart/mixed, which is obviously not good, but I can't visualize
> > how this is supposed to look with the current buttonized scheme.
> 
> How about a menu, or some way of cycling through the alternatives when
> you're standing on top of a buttonized message part?

A menu, and a keystroke to cycle sounds like good ideas, but how is
the user to be told that there are alternative parts?  In the article
buffer mode line?

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

Re: Those MIME requirements

[Jason L Tibbitts III]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> Is this satisfactory?  I'd really like not to leave the summary
LMI> buffer, but I don't quite see how...

Way in the past I remember talking about showing the various parts of
multipart messages in the Summary buffer as if they were children in an
thread.  This is how MEW did it.  It also works nicely for nested
multiparts.  I'd prefer to be able to navigate all of the parts of an
article without leaving the Summary buffer and preferably without entirely
replacing the summary buffer (as when reading digests).

There used to be some info on this somewhere, in a TODO list or something.

 - J<

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Jason L Tibbitts said:

  Jason> Way in the past I remember talking about showing the various
  Jason> parts of multipart messages in the Summary buffer as if they
  Jason> were children in an thread.

Yeah, that would also be cool.  Problem is, there is no one method
which works for all messages and all people.  Not even one person and
all messages.  And deciding which method to use is AI-complete.

I think the combined possibility of using TM-style
within-the-article-buffer viewing and entering digests is a good
compromise.  But maybe you want to argue for the
within-the-summary-buffer alternative, too?

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Jason L Tibbitts III <tibbs@hpc.uh.edu> writes:

> Way in the past I remember talking about showing the various parts of
> multipart messages in the Summary buffer as if they were children in an
> thread.

We already have this -- `C-d' will open a new nndoc group based on a
MIME multipart article.

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

Re: Those MIME requirements

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jason L Tibbitts III <tibbs@hpc.uh.edu> writes:
> 
> > Way in the past I remember talking about showing the various parts of
> > multipart messages in the Summary buffer as if they were children in an
> > thread.
> 
> We already have this -- `C-d' will open a new nndoc group based on a
> MIME multipart article.

Yes, but nndoc attempts to do a slew of other stuff, and it does some
ugly thing with the headers, and.....  It's not right, really.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Yes, but nndoc attempts to do a slew of other stuff, and it does some
> ugly thing with the headers, and.....  It's not right, really.

I think it does the right thing with the headers -- uses the ones from
the parent as a default, and filling in with the headers from the
part.  Makes it trivial to respond to parts.

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

Re: Those MIME requirements

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think it does the right thing with the headers -- uses the ones from
> the parent as a default, and filling in with the headers from the
> part.  Makes it trivial to respond to parts.

Hmm, the last time I tried to respond to an rfc822 message part, it
failed miserably.  Perhaps it has been fixed in the meantime.  Also,
should save the message without the headers (unless, again, we are
talking about a message/rfc822 part), and so on.  A much nicer
behaviour is needed, and nndoc is not good enough to provide it.

Try getting used to mutt's `v' command, and you'll see what I mean.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Union break!

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Hmm, the last time I tried to respond to an rfc822 message part, it
> failed miserably.  Perhaps it has been fixed in the meantime.

I think so.

> Also, should save the message without the headers (unless, again, we
> are talking about a message/rfc822 part), and so on.

`O b' saves bodies...

> Try getting used to mutt's `v' command, and you'll see what I mean.

I've never used `v', so I don't know how that works.  Could you
describe it?

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

Re: Those MIME requirements

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > Also, should save the message without the headers (unless, again, we
> > are talking about a message/rfc822 part), and so on.
> 
> `O b' saves bodies...

The whole point is that the default save command should do the right
thing with MIME parts.  Requiring people to just *remember* that they
have to press `o' at one time, `O b' at some other time, etc. is
simply wrong.

Then, there is also the fact that the headers are fabricated (I don't
really like the merging between the parent and multipart headers, as
much as it may be useful for replying to multipart attachments.)

> > Try getting used to mutt's `v' command, and you'll see what I mean.
> 
> I've never used `v', so I don't know how that works.  Could you
> describe it?

It shows a simple menu of MIME attachment, sort of like C-d in Gnus,
but its keybindings are better suited for doing stuff with the
multipart stuff.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Those who like sausages, laws, and standards are well advised not
to learn how they are made.

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Lars Magne Ingebrigtsen said:

  Lars> A menu, and a keystroke to cycle sounds like good ideas, but
  Lars> how is the user to be told that there are alternative parts?
  Lars> In the article buffer mode line?

No, a multipart/alternative can be one part of a multipart/mixed.
How about making the button reflect that it's alternative.

Your buttons now look like [text/html], maybe {text/html} could be
used for alternative?  Or [alt: text/html]?  Or sumpin?

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> No, a multipart/alternative can be one part of a multipart/mixed.

Hm...  Yes...  Could you mail me a multipart/mixed message that
contains a multipart/alternative part?

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

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Lars Magne Ingebrigtsen said:

  Lars> Don't w3 have to display things in its own buffer?  Anyway,
  Lars> 0.27 will display html with w3 in a separate buffer, which
  Lars> brings up the question: How is Gnus supposed to display things
  Lars> that are displayed by Emacs, but not in the article buffer?
  Lars> Gnus has to pop up a new buffer, but is that buffer supposed
  Lars> to replace the article buffer, or what?

I think that would be the logical choice, goes well with the digesting
stuff which re-uses the summary window.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Lars Magne Ingebrigtsen said:

  Lars> Ooh.  multipart/alternative.  It's not handled exactly the
  Lars> same way as multipart/mixed, which is obviously not good, but
  Lars> I can't visualize how this is supposed to look with the
  Lars> current buttonized scheme.

 .-----
 | [ ] text/plain   [*] text/html
 | 
 | ...html text goes here...
 `-----

Clicking on the [ ] next to text/plain exchanges html text against
plain text and moves the * to text/plain.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

>   Lars> Ooh.  multipart/alternative.  It's not handled exactly the
>   Lars> same way as multipart/mixed, which is obviously not good, but
>   Lars> I can't visualize how this is supposed to look with the
>   Lars> current buttonized scheme.
> 
>  .-----
>  | [ ] text/plain   [*] text/html
>  | 
>  | ...html text goes here...
>  `-----
> 
> Clicking on the [ ] next to text/plain exchanges html text against
> plain text and moves the * to text/plain.

This definitely sounds workable.  I'll try this and see how it feels. 

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

Re: Those MIME requirements

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> > REQ-5 - display of text/html
> > I would like to see text/html message parts formatted inline in the
> > message (using W3, I guess), both where they are the only alternative,
> > and where they are part of a multipart/alternative
> > (19980825 Steinar Bang <sb@metis.no>)
> 
> Don't w3 have to display things in its own buffer?

No.  VM can render a part of the buffer as HTML using W3.

> Anyway, 0.27 will display html with w3 in a separate buffer, which
> brings up the question: How is Gnus supposed to display things that
> are displayed by Emacs, but not in the article buffer?  Gnus has to
> pop up a new buffer, but is that buffer supposed to replace the
> article buffer, or what?

That would be fine, I think.  Whether the new buffer is opened should
depend on the content-disposition, shouldn't it?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> No.  VM can render a part of the buffer as HTML using W3.

Right.  I'll look into it.

> > Anyway, 0.27 will display html with w3 in a separate buffer, which
> > brings up the question: How is Gnus supposed to display things that
> > are displayed by Emacs, but not in the article buffer?  Gnus has to
> > pop up a new buffer, but is that buffer supposed to replace the
> > article buffer, or what?
> 
> That would be fine, I think.  Whether the new buffer is opened should
> depend on the content-disposition, shouldn't it?

Currently, I don't do anything with Content-Disposition.  Shouldn't
display of elements be up to the recipient, and not the sender?  But I 
haven't read the MIME RFC concerning that header, so I'm just guessing 
what its purpose is.  :-)

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

Re: Those MIME requirements

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > That would be fine, I think.  Whether the new buffer is opened
> > should depend on the content-disposition, shouldn't it?
> 
> Currently, I don't do anything with Content-Disposition.  Shouldn't
> display of elements be up to the recipient, and not the sender?

The sender should be allowed to express a preference.  For example, a
set of huge pictures attached to a message can be hazardous to insert
in the buffer.  In this case, sender can ask the recipient not to
inline it.  Or can't it?

I'm not any kind of expert on MIME, though.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

Re: Those MIME requirements

[William M. Perry]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > > That would be fine, I think.  Whether the new buffer is opened
> > > should depend on the content-disposition, shouldn't it?
> > 
> > Currently, I don't do anything with Content-Disposition.  Shouldn't
> > display of elements be up to the recipient, and not the sender?
> 
> The sender should be allowed to express a preference.  For example, a
> set of huge pictures attached to a message can be hazardous to insert
> in the buffer.  In this case, sender can ask the recipient not to
> inline it.  Or can't it?
> 
> I'm not any kind of expert on MIME, though.

  Content-disposition should be honored.  If someone mails me a word file
and I have a converter set up in my mailcap for showing it (or however we
might do such a thing), I might not want to have it shown inline anyway.

  Content-disposition is a good thing.

-Bill P.

Re: Those MIME requirements

[Alan Shutko]

>>>>> "B" == William M Perry <wmperry@aventail.com> writes:

B>   Content-disposition should be honored.  If someone mails me a
B> word file and I have a converter set up in my mailcap for showing
B> it (or however we might do such a thing), I might not want to have
B> it shown inline anyway.

OTOH, there are a number of mailers which don't have the concept of
showing things inline, so they always call things attachments.  And I
think it's a terrible pain not to be able to view text files inline,
simply because the other end told me not to.

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
Two cars in every pot and a chicken in every garage.

Re: Those MIME requirements

[Richard Coleman]

> B>   Content-disposition should be honored.  If someone mails me a
> B> word file and I have a converter set up in my mailcap for showing
> B> it (or however we might do such a thing), I might not want to have
> B> it shown inline anyway.
> 
> OTOH, there are a number of mailers which don't have the concept of
> showing things inline, so they always call things attachments.  And I
> think it's a terrible pain not to be able to view text files inline,
> simply because the other end told me not to.

Content-Disposition only specifies the default action that should
be taken for an attachment.  It's more of a hint than a rule.

So if a part of a multipart is labeled "attachment" by the
Content-Disposition header, the RFC says that the part should
not be displayed unless further action is taken by the reader.
It doesn't say it can't be displayed at all.  A menu (or button)
so that the reader can choose to view or save the attachment would
be the right thing.

Content-Disposition is a good thing.

--
Richard Coleman
coleman@math.gatech.edu

Re: Those MIME requirements

[William M. Perry]

Alan Shutko <ats@acm.org> writes:

> >>>>> "B" == William M Perry <wmperry@aventail.com> writes:
> 
> B>   Content-disposition should be honored.  If someone mails me a
> B> word file and I have a converter set up in my mailcap for showing
> B> it (or however we might do such a thing), I might not want to have
> B> it shown inline anyway.
> 
> OTOH, there are a number of mailers which don't have the concept of
> showing things inline, so they always call things attachments.  And I
> think it's a terrible pain not to be able to view text files inline,
> simply because the other end told me not to.

  Nothing says there can't be a 'show inline' keybinding active in the
button that shows the attachments, and a matching menu item in the
context-sensitive menu.

-bill p.

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Currently, I don't do anything with Content-Disposition.  Shouldn't
> > display of elements be up to the recipient, and not the sender?
> 
> The sender should be allowed to express a preference.  For example, a
> set of huge pictures attached to a message can be hazardous to insert
> in the buffer.  In this case, sender can ask the recipient not to
> inline it.  Or can't it?

Yup.  I've now made the automatic inlining functions respect the
Content-Disposition header.

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

HTML (was: Re: Those MIME requirements)

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Don't w3 have to display things in its own buffer? 

No.  I'd like text/html by default to be formatted like `W h' does
now, i.e. as plain text.  Maybe with a button to send it to
`browse-url'. 

Re: HTML (was: Re: Those MIME requirements)

[William M. Perry]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> > Don't w3 have to display things in its own buffer? 
> 
> No.  I'd like text/html by default to be formatted like `W h' does
> now, i.e. as plain text.  Maybe with a button to send it to
> `browse-url'. 

  Ummm.. `W h' uses Emacs/W3.

  It would be nice if at least the widgets were copied from the temp w3
buffer so that you could follow hyperlinks, etc.

-Bill P.

Re: HTML (was: Re: Those MIME requirements)

[Per Abrahamsen]

wmperry@aventail.com (William M. Perry) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> > 
> > > Don't w3 have to display things in its own buffer? 
> > 
> > No.  I'd like text/html by default to be formatted like `W h' does
> > now, i.e. as plain text.  Maybe with a button to send it to
> > `browse-url'. 
> 
>   Ummm.. `W h' uses Emacs/W3.

I know.  It still formats it like plain text.

>   It would be nice if at least the widgets were copied from the temp w3
> buffer so that you could follow hyperlinks, etc.

It would be nice if Gnus could just call

	(widget-create 'html STRING-OR-BUFFER-WITH-HTML-CODE)

inside the article buffer.  Don't you think so too?

Re: HTML (was: Re: Those MIME requirements)

[William M. Perry]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> wmperry@aventail.com (William M. Perry) writes:
> 
> > Per Abrahamsen <abraham@dina.kvl.dk> writes:
> > 
> > > Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> > > 
> > > > Don't w3 have to display things in its own buffer? 
> > > 
> > > No.  I'd like text/html by default to be formatted like `W h' does
> > > now, i.e. as plain text.  Maybe with a button to send it to
> > > `browse-url'. 
> > 
> >   Ummm.. `W h' uses Emacs/W3.
> 
> I know.  It still formats it like plain text.
> 
> >   It would be nice if at least the widgets were copied from the temp w3
> > buffer so that you could follow hyperlinks, etc.
> 
> It would be nice if Gnus could just call
> 
> 	(widget-create 'html STRING-OR-BUFFER-WITH-HTML-CODE)
> 
> inside the article buffer.  Don't you think so too?

  Hmmm... that's a little weird, but yes, that'd be really cool.

-Bill P.

Re: HTML (was: Re: Those MIME requirements)

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   It would be nice if at least the widgets were copied from the temp w3
> buffer so that you could follow hyperlinks, etc.

Indeedy.  The mm-view code now does that, and the HTML sections show
up all nice and colorful in the Gnus article buffer.  But the links
don't work, since the Gnus article keymap is in place.  It would be
very, very nice if w3 were to use `local-map' and `keymap' text props
on the hyperlinks so bind keys to the w3 commands when point is over
the w3 buttons.

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

Re: HTML (was: Re: Those MIME requirements)

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> It would be very, very nice if w3 were to use `local-map' and
> `keymap' text props on the hyperlinks so bind keys to the w3
> commands when point is over the w3 buttons.

These properties don't work well with the mouse.  When you push a
mouse button, the location of point (the text cursor) and not the
mouse pointer will determine what keymap is used.

I think it would be better to inherit the article keymap from
`widget-keymap'.  Even better would be if Gnus used standard widget
buttons in the article, then it would work together with W3 perfectly.

You can "buttonize" existing text by calling `widget-convert-button'.

Re: HTML (was: Re: Those MIME requirements)

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> These properties don't work well with the mouse.  When you push a
> mouse button, the location of point (the text cursor) and not the
> mouse pointer will determine what keymap is used.

That's true, but can't that be worked around?  The default mouse-2
function might look whether there is some local keymap where the user
clicked the mouse pointer, and if there is and the mouse-2 function is
bound there as well, then the default function could call that other
function instead.

> I think it would be better to inherit the article keymap from
> `widget-keymap'.  Even better would be if Gnus used standard widget
> buttons in the article, then it would work together with W3 perfectly.
> 
> You can "buttonize" existing text by calling `widget-convert-button'.

Right.  And then how would things be called and stuff?  (I tried the
Widget manual, but it didn't mention this function...)

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

Re: HTML (was: Re: Those MIME requirements)

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > These properties don't work well with the mouse.  When you push a
> > mouse button, the location of point (the text cursor) and not the
> > mouse pointer will determine what keymap is used.
> 
> That's true, but can't that be worked around?  The default mouse-2
> function might look whether there is some local keymap where the user
> clicked the mouse pointer, and if there is and the mouse-2 function is
> bound there as well, then the default function could call that other
> function instead.

  This sounds like a completely bogus bug in Emacs and XEmacs to me.
Make them fix it. :)

> > I think it would be better to inherit the article keymap from
> > `widget-keymap'.  Even better would be if Gnus used standard widget
> > buttons in the article, then it would work together with W3 perfectly.
> > 
> > You can "buttonize" existing text by calling `widget-convert-button'.
> 
> Right.  And then how would things be called and stuff?  (I tried the
> Widget manual, but it didn't mention this function...)

  Emacs/W3 uses widget-convert-text, like so:

(widget-convert-text 'link start-pos end-pos start-pos end-pos link-info)

  You just have an appropriate :action specified in link-info and just make 
that function do what you want.

-Bill P.

Re: HTML (was: Re: Those MIME requirements)

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   Emacs/W3 uses widget-convert-text, like so:
> 
> (widget-convert-text 'link start-pos end-pos start-pos end-pos link-info)
> 
>   You just have an appropriate :action specified in link-info and just make 
> that function do what you want.

Right.  I've now converted all the buttons to use widget.

But there's one thing about the widget keymap I don't get -- isn't TAB 
supposed to go to the next widget?  I've made widget-keymap the parent 
of gnus-article-mode-keymap (and I don't define TAB in the latter
keymap), but under Emacs 20.3, TAB still gives me indent-for-tab.  It
works OK under XEmacs 21, though...

(The same with RET.)

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

Re: HTML (was: Re: Those MIME requirements)

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But there's one thing about the widget keymap I don't get -- isn't TAB 
> supposed to go to the next widget? 

Yes.  And it does so when I try it with the function `widget-example'
in the widget manual with Emacs 20.3.

Can you send a small example where it doesn't work?

Re: HTML (was: Re: Those MIME requirements)

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Yes.  And it does so when I try it with the function `widget-example'
> in the widget manual with Emacs 20.3.
> 
> Can you send a small example where it doesn't work?

widget-keymap
=> (keymap (13 . widget-button-press) (down-mouse-2 . widget-button-click) (backtab . widget-backward) (S-tab . widget-backward) (9 . widget-forward))

(lookup-key widget-keymap (kbd "TAB"))
=> widget-forward

Hm.  I don't seem to be able to reproduce the bug any more.

Oh, well.

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

Re: HTML (was: Re: Those MIME requirements)

[Per Abrahamsen]

wmperry@aventail.com (William M. Perry) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > That's true, but can't that be worked around?  The default mouse-2
> > function might look whether there is some local keymap where the user
> > clicked the mouse pointer, and if there is and the mouse-2 function is
> > bound there as well, then the default function could call that other
> > function instead.

Sure, but how would this help the widget package to achieve total
world domination (or at least Emacs pseudo-GUI domination)?

> > > You can "buttonize" existing text by calling `widget-convert-button'.
> > 
>   Emacs/W3 uses widget-convert-text, like so:
> 
> (widget-convert-text 'link start-pos end-pos start-pos end-pos link-info)

And the only difference with `widget-convert-button' is that you don't
have to state the start and end pos twice ;-)

Re: HTML (was: Re: Those MIME requirements)

[Jan Vroonhof]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> These properties don't work well with the mouse.  When you push a
> mouse button, the location of point (the text cursor) and not the
> mouse pointer will determine what keymap is used.

Isn't this really an Emacs bug/problem?

Jan

Re: HTML (was: Re: Those MIME requirements)

[Dave Love]

>>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:

 Per> These properties don't work well with the mouse.  When you push
 Per> a mouse button, the location of point (the text cursor) and not
 Per> the mouse pointer will determine what keymap is used.

Uhm?  AFAICT in Emacs 20.3 it works as documented in `(elisp)Clickable
Text'.  The original go at the Help mode hyperlinks used local-map
properties and it worked fine for mouse clicks.  I'm not sure that
there was actually a good reason to change it.

[The hyperlinks probably should use widgets and be consistent with
custom, but rms wanted to postpone work on that.]

Re: HTML (was: Re: Those MIME requirements)

[Per Abrahamsen]

Dave Love <d.love@dl.ac.uk> writes:

> >>>>> "Per" == Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
>  Per> These properties don't work well with the mouse.  When you push
>  Per> a mouse button, the location of point (the text cursor) and not
>  Per> the mouse pointer will determine what keymap is used.
> 
> Uhm?  AFAICT in Emacs 20.3 it works as documented in `(elisp)Clickable
> Text'.

It might have been fixed in 20.3.  It used to work as I describe.

Re: HTML (was: Re: Those MIME requirements)

[Hrvoje Niksic]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > It would be very, very nice if w3 were to use `local-map' and
> > `keymap' text props on the hyperlinks so bind keys to the w3
> > commands when point is over the w3 buttons.
> 
> These properties don't work well with the mouse.  When you push a
> mouse button, the location of point (the text cursor) and not the
> mouse pointer will determine what keymap is used.

Not so under XEmacs.  This is why widget uses `keymap' properties
under XEmacs.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I luv the smell of nature in the morning.  Smells like manure!

Re: Those MIME requirements

[Hallvard B Furuseth]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
>> REQ-27 - mailcap support for elisp
>> I would like mailcap files to be able to execute emacs lisp functions
>> on the contents of a message part.
>> (19980826 Jean-Yves Perrier <perrier@nagra-kudelski.ch>)
> 
> application/emacs-lisp will eval Emacs Lisp functions.  (After asking, 
> of course.)

Should be application/x-emacs-lisp, since it's not registered with IANA
<URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/>.
Or if someone else invented application/emacs-lisp so you must stay
compatible, get them to register it (see rfc2048).

-- 
Hallvard

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> Should be application/x-emacs-lisp, since it's not registered with IANA
> <URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/>.
> Or if someone else invented application/emacs-lisp so you must stay
> compatible, get them to register it (see rfc2048).

It's just one of the defaults in the mm-mime-data alist, but I don't
know whether it has been used.

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

Re: Those MIME requirements

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
> 
> > Should be application/x-emacs-lisp, since it's not registered with IANA
> > <URL:ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/>.
> > Or if someone else invented application/emacs-lisp so you must stay
> > compatible, get them to register it (see rfc2048).
> 
> It's just one of the defaults in the mm-mime-data alist, but I don't
> know whether it has been used.

  No, it has not been used very much.

-Bill P.

Re: Those MIME requirements

[Kai Grossjohann]

>>>>> On 11 Sep 1998, Lars Magne Ingebrigtsen said:

  >> ******
  >> REQ-27 - mailcap support for elisp
  >> I would like mailcap files to be able to execute emacs lisp functions
  >> on the contents of a message part.
  >> (19980826 Jean-Yves Perrier <perrier@nagra-kudelski.ch>)

  Lars> application/emacs-lisp will eval Emacs Lisp functions.  (After
  Lars> asking, of course.)  Is that what you mean?

I think he's saying it should be possible to put Lisp in ~/.mailcap
which gets the content of a part as input, somehow.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:

> I think he's saying it should be possible to put Lisp in ~/.mailcap
> which gets the content of a part as input, somehow.

Hm...  Does the mailcap format allow that?

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

Lisp in mailcap file (Re: Those MIME requirements)

[Jean-Yves Perrier]

Lars writes:

> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:
> 
> > I think he's saying it should be possible to put Lisp in ~/.mailcap
> > which gets the content of a part as input, somehow.
> 
> Hm...  Does the mailcap format allow that?

Mmmh, Simon Josefsson asked for the mailcap support and I pointed out
that it should be nice if lisp function could be triggered inside Gnus
(like now :-) ),

Simon pointed then out :

Simon wrote on 26 Aug 1998 18:05:31 +0200:

> The mailcap file format allows for client specific settings.
> 
> image/gif: xv %s; \
> 	  x-gnus=mime-show-inline-gif; \
> 	  description="GIF Image"
> 
> You could also have different Gnus settings for Emacs/XEmacs.

I don't know whether it is a good thing or not to have this...

Regards,
-- 
Jean-Yves

Re: Those MIME requirements

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> writes:
> 
> > I think he's saying it should be possible to put Lisp in ~/.mailcap
> > which gets the content of a part as input, somehow.
> 
> Hm...  Does the mailcap format allow that?

  There are a lot of % escapes that you need to handle for mailcap.  Look
at mm-unescape-mime-test for some of them.  Here's a synopsis (at least of
what mm.el supports):

In viewers, you can put:
%u = URL
%s = filename

In tests, you can put:
%t = content-type
%{xxx} = header named xxx

It also recognizes but doesn't support:
%F = ""
%M = ""
%n = ""

I don't remember what those are for anymore... they were something that
wasn't real important for most of the tests in existence.

We could easily make the Emacs lisp portion of the mailcap to deal with
lisp viewers look like:

image/gif; xv %s; x-emacs-test=(builtin-emacs-viewer "%t"); \
           x-emacs-viewer=(message "Should view %f (%u) (%t)")

-Bill P.

CID (Was Re: Those MIME requirements)

[Jean-Yves Perrier]

Lars wrote:
> > REQ-21 - handling of message-internal URIs
> > In some MIME type, like vcard, there is a possible to make special URL
> > beginning with cid:...
> > These relate to other MIME attachement of the same message. It would be
> > nice for the people developping MIME types extension that Gnus provides
> > function to handles these URL smoothly.
> > (19980826 Jean-Yves Perrier <perrier@nagra-kudelski.ch>)
> 
> In what way are these used?

URL beginning with cid: refers to other part of the message. Each part may have
a Content-ID entry (see RFC2045, page 26, point 7.)

CID are more widely used in multipart/related messages (see RFC 2112).

The VCard specification use it too, for example to transmit an image
in another part of the message rather than in the vcard itself. (RFC 2425, page
17, point 7  & page 20 point 8.4)

Of course, I don't expect Gnus to handle cid's url, but the Content-ID headers.

In order to be able to be able to write type handlers for such types, it
would be greatly useful that Gnus provides a non-interactive like this:

(gnus-give-message-part content-id).

-- 
Jean-Yves

Re: CID (Was Re: Those MIME requirements)

[Lars Magne Ingebrigtsen]

Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes:

> CID are more widely used in multipart/related messages (see RFC 2112).

I see.  Well, I think I'll wait a bit with multipart/related.

> In order to be able to be able to write type handlers for such types, it
> would be greatly useful that Gnus provides a non-interactive like this:
> 
> (gnus-give-message-part content-id).

I'm not sure I follow you...

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

Re: CID (Was Re: Those MIME requirements)

[William M. Perry]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jean-Yves Perrier <perrier@nagra-kudelski.ch> writes:
> 
> > CID are more widely used in multipart/related messages (see RFC 2112).
> 
> I see.  Well, I think I'll wait a bit with multipart/related.
> 
> > In order to be able to be able to write type handlers for such types, it
> > would be greatly useful that Gnus provides a non-interactive like this:
> > 
> > (gnus-give-message-part content-id).
> 
> I'm not sure I follow you...

  There should be some way from within, say Emacs/W3, when someone does an
<img src="cid:blahblah"> for me to get at it.  We should really have some
sort of a 'standard' function that can be used by the various MIME agents
out there.  Something like (mime-message-fetch-content-id "blahblah") or
something like that.

-Bill P.

Re: CID (Was Re: Those MIME requirements)

[Lars Magne Ingebrigtsen]

wmperry@aventail.com (William M. Perry) writes:

>   There should be some way from within, say Emacs/W3, when someone does an
> <img src="cid:blahblah"> for me to get at it.  We should really have some
> sort of a 'standard' function that can be used by the various MIME agents
> out there.  Something like (mime-message-fetch-content-id "blahblah") or
> something like that.

I've now added this.

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

Those updated MIME requirements

[Steinar Bang]

A little bit of housekeeping at the MIME requirements found at:
	http://www.metis.no/private/sb/gnusmimereqs.html

I moved all larsi's "check"'d requirements from to a "completed" section:
	http://www.metis.no/private/sb/gnusmimereqs.html#implemented

I also added a new requirement that I just thought of:
	http://www.metis.no/private/sb/gnusmimereqs.html#REQ-28


- Steinar

Re: Those MIME requirements

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> How does TM navigate through the multipart/mixed messages?

'n' for next entity, 'p' for previous entity and 'u' for upper entity.

Also, I think Gnus should number the entities. Walking around in
articles that contains attachments with nestled entities is almost
impossible since the article structure is not preserved by Gnus right
now.

A possible rendering of an article would be:

[1 <text/plain>]
[2 <multipart/alternative>]
[2.1 <text/plain>]
[2.2 <message/external-body>]
[3 <text/plain>]

(I'm not sure if this is the best way to render 'alternative'
attachments, but you get the idea)

> > REQ-20 - integration of MIME support with nnimap
> > I would like the MIME support to cooperate with the upcoming
> > nnimap, in such a way that loading of attachments can be delayed
> > until you actually wish to show or save it (delay the download of
> > that 5MB PowerPoint file your boss sent you (real example: it
> > happened to me today) until you can plug your laptop into the LAN at
> > work)
> > (19980826 Steinar Bang <sb@metis.no>)
> 
> That would be nice.

One way would be to request a body structure of the article from the
backend and then only fetch the TEXT/PLAIN entities (by user
configuration, of course) and display the article.

The representation used by IMAP uses paranthesis nesting and could
probably be used without much changes, it looks something like this
(same article as in the rendering above):

(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1248 45)(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 77 5)("MESSAGE" "EXTERNAL-BODY" ("ACCESS-TYPE" "anon-ftp" "SITE" "ftp.jaist.ac.jp" "DIRECTORY" "/pub/GNU/elisp/apel" "NAME" "apel-8.18.tar.gz" "MODE" "image") NIL NIL "7BIT" 99) "ALTERNATIVE")("TEXT" "PLAIN" ("CHARSET" "ISO-8859-1") NIL NIL "QUOTED-PRINTABLE" 336 7) "MIXED")

The syntax is described in detail on page 59 ("BODYSTRUCTURE") of
RFC2060.

/s

Re: Those MIME requirements

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> > How does TM navigate through the multipart/mixed messages?
> 
> 'n' for next entity, 'p' for previous entity and 'u' for upper entity.

I think the Widget keystrokes are better -- TAB and M-TAB.

Hey, after converting all the Gnus buttons to Widget buttons, one can
TAB through all of the buttons.  Neat!

Uhm...  The Widget movement commands seem to also go through the
invisible and intangible buttons...  Is that a bug, Per?

> A possible rendering of an article would be:
> 
> [1 <text/plain>]
> [2 <multipart/alternative>]
> [2.1 <text/plain>]
> [2.2 <message/external-body>]
> [3 <text/plain>]

`C-d' renders in this fashion.

> One way would be to request a body structure of the article from the
> backend and then only fetch the TEXT/PLAIN entities (by user
> configuration, of course) and display the article.

Right.  I think this would be a good idea, but I think we should wait
a smidgen.

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

Re: Those MIME requirements

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think the Widget keystrokes are better -- TAB and M-TAB.

Note that, under FSF, it is TAB and Shift-TAB.

> Uhm...  The Widget movement commands seem to also go through the
> invisible and intangible buttons...  Is that a bug, Per?

I'll look into fixing this for XEmacs.

> `C-d' renders in this fashion.

C-d is losing for other reasons.  I'll elaborate in a separate
message.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
By any chance, have you seen a summoned 9th order fire elemental
wandering around?  No?  Oh..  Tell me if you do.

Re: Those MIME requirements

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Uhm...  The Widget movement commands seem to also go through the
> invisible and intangible buttons...  Is that a bug, Per?

I don't know.  The question `How to deal with invisible or intangible
buttons?' never crossed my mind when designing the system

I guess now that C-s ignores invisible text, so should widget for
consistency.