Features before the next millenium

Features before the next millenium

[Hrvoje Niksic]

The manual says:

    Newest Features
    ---------------

    Also known as the "todo list".  Sure to be implemented before the next
    millennium.

    Be afraid.  Be very afraid.

       * Native MIME support is something that should be done.
       * Really do unbinhexing.

Does this mean we get to see native MIME support in Gnus by the year
2000?  It's getting awfully near!  :-)

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.

Re: Features before the next millenium

[Karl Kleinpaste]

Hrvoje Niksic <hniksic@srce.hr> quotes the todo list:
>        * Really do unbinhexing.

Just hack in an interface to http://tom.cs.cmu.edu/.

Problem solved. :-)

Re: Features before the next millenium

[Aaron M. Ucko]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Does this mean we get to see native MIME support in Gnus by the year
> 2000?  It's getting awfully near!  :-)

No, just by 2001. :-)

-- 
Aaron M. Ucko <amu@mit.edu> (finger amu@monk.mit.edu) [Stark raving sane]

Re: Features before the next millenium

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

>     Also known as the "todo list".  Sure to be implemented before the next
>     millennium.

[...]

> Does this mean we get to see native MIME support in Gnus by the year
> 2000?  It's getting awfully near!  :-)

I meant the 2008-3008 millennium.  Not that other, more popular one.

I'd still really like to see native MIME support in Gnus.  I thought
that tm would be it, but, uhm, it didn't quite look like what I had in
mind.  What I would love to see is a general, basic MIME library that
does nothing smart at all.  Just something that provides functionality
like, uh, `mime-decode-buffer', `mime-decode-buffer-to-file',
`mime-decode-string'.  You know.  *Basic* things.  Then I could (and
would) use it in Gnus.

Writing packages that work the other way around (i.e., provides
functionality to lots of packages by "infecting" them) never works
properly. 

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

Re: Features before the next millenium

[Steinar Bang]

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

> I'd still really like to see native MIME support in Gnus.  I thought
> that tm would be it, but, uhm, it didn't quite look like what I had in
> mind.  What I would love to see is a general, basic MIME library that
> does nothing smart at all.  Just something that provides functionality
> like, uh, `mime-decode-buffer', `mime-decode-buffer-to-file',
> `mime-decode-string'.  You know.  *Basic* things.  Then I could (and
> would) use it in Gnus.

Could you write up a functional spec of what you need? (Not that I'm
promising to write it, mind.  I know MIME fairly well, but hardly any
emacs lisp).  Just an initial one:
 - a list of functions
 - short descriptions of the functions, where they are getting their
   input, where they are putting their output, and what they should do
   with the input

Eg. something like:
 - mime-parse-buffer: runs through a buffer holding a MIME message,
   and returns a list of records holding the MIME type, the encoding
   used, and the start an end positions of all message parts found in
   the buffer

(seems like a reasonable place to start)

Re: Features before the next millenium

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> Could you write up a functional spec of what you need? (Not that I'm
> promising to write it, mind.  I know MIME fairly well, but hardly any
> emacs lisp).  Just an initial one:
>  - a list of functions
>  - short descriptions of the functions, where they are getting their
>    input, where they are putting their output, and what they should do
>    with the input

I'm not exactly sure what I'd like to have, really.  I don't know
which MIME features would be required and stuff.

> Eg. something like:
>  - mime-parse-buffer: runs through a buffer holding a MIME message,
>    and returns a list of records holding the MIME type, the encoding
>    used, and the start an end positions of all message parts found in
>    the buffer

Yes; that sounds very nice.  :-)

Let's see...  Perhaps something like:

------
(mime-parse-buffer BUFFER)

Return a list of MIME handles based on the contents of BUFFER.

(mime-insert HANDLE)

Take a MIME handle and insert it after point.

(mime-save HANDLE FILE)

Take a MIME handle and save it to FILE.
------

That is, I don't want to know anything about MIME things at all.  I'd
guess these MIME handles would consist of a buffer, a BEG mark and an
END mark, but perhaps more data would be required.

`mime-insert' would do the expected with text under all Emacsen, but
pictures can't be inserted under Emacs, so a `mime-external-view'
might also be nice.  Which means that a `mime-external-p' predicate
function would be nice to have to say whether something could be
displayed in a buffer or not.

With basic building blocks like this, I think making Gnus totally
MIME-aware (as a reader, anyway; composition is a different matter)
would be very simple.

With a single-part MIME article (ie., an article which
`mime-parse-buffer' responds with a list that has only one element),
Gnus would show the article as usual.  With multipart articles, Gnus
could add pseudo-articles for the additional parts, or other types of
buttons.  Whatever.  And then display these with `mime-insert' or
`mime-external-view'.

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

Re: Features before the next millenium

[Steinar Bang]

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

> ------
> (mime-parse-buffer BUFFER)

> Return a list of MIME handles based on the contents of BUFFER.

> (mime-insert HANDLE)

> Take a MIME handle and insert it after point.

> (mime-save HANDLE FILE)

> Take a MIME handle and save it to FILE.
> ------

> That is, I don't want to know anything about MIME things at all.  I'd
> guess these MIME handles would consist of a buffer, a BEG mark and an
> END mark, but perhaps more data would be required.

The content-type, for sure, with all its parameters
(eg. content-disposition and filename).  The content-transfer-endcoding
almost for sure (though you may wish to have the option to decode
stuff automagically).

Then you'd want some kind of mapping from content-type to actions.  As
I understand Bill Perry has already written something like this for
w3-mode. 

> `mime-insert' would do the expected with text under all Emacsen, but
> pictures can't be inserted under Emacs, so a `mime-external-view'
> might also be nice.  Which means that a `mime-external-p' predicate
> function would be nice to have to say whether something could be
> displayed in a buffer or not.

Again, there should be some sort of tabular mapping from content-type
to action.  Preferrably on some standardized form, like a mailcap file.

> With basic building blocks like this, I think making Gnus totally
> MIME-aware (as a reader, anyway; composition is a different matter)
> would be very simple.

Composition already works fairly well with tm-edit.el from TM, and
before that, all the way back to 1993, I was using Masanobu Umeda's
mime.el. 

> With a single-part MIME article (ie., an article which
> `mime-parse-buffer' responds with a list that has only one element),
> Gnus would show the article as usual.  With multipart articles, Gnus
> could add pseudo-articles for the additional parts, or other types of
> buttons.  Whatever.  And then display these with `mime-insert' or
> `mime-external-view'.

Other types of buttons, I'd say.  Similar to what Gnus+TM does today.


- Steinar

Re: Features before the next millenium

[Hrvoje Niksic]

Steinar Bang <sb@metis.no> writes:

> > With a single-part MIME article (ie., an article which
> > `mime-parse-buffer' responds with a list that has only one element),
> > Gnus would show the article as usual.  With multipart articles, Gnus
> > could add pseudo-articles for the additional parts, or other types of
> > buttons.  Whatever.  And then display these with `mime-insert' or
> > `mime-external-view'.
> 
> Other types of buttons, I'd say.  Similar to what Gnus+TM does
> today.

What TM does today is very bad.  The right way to do it is via
pseudo-articles, which is how `X u' works, for instance.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Psychos _do not_ explode when sunlight hits them."

Re: Features before the next millenium

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

> Steinar Bang <sb@metis.no> writes:
>> > With a single-part MIME article (ie., an article which
>> > `mime-parse-buffer' responds with a list that has only one element),
>> > Gnus would show the article as usual.  With multipart articles, Gnus
>> > could add pseudo-articles for the additional parts, or other types of
>> > buttons.  Whatever.  And then display these with `mime-insert' or
>> > `mime-external-view'.
>> 
>> Other types of buttons, I'd say.  Similar to what Gnus+TM does
>> today.

> What TM does today is very bad.  The right way to do it is via
> pseudo-articles, which is how `X u' works, for instance.

I saw that used in Mew.  A terrible idea from a UI viewpoint, IMHO.

I prefer the TM way.  Exactly _why_ is it bad, in your opinion?

Re: Features before the next millenium

[Hrvoje Niksic]

Steinar Bang <sb@metis.no> writes:

> > What TM does today is very bad.  The right way to do it is via
> > pseudo-articles, which is how `X u' works, for instance.
> 
> I saw that used in Mew.  A terrible idea from a UI viewpoint, IMHO.
> 
> I prefer the TM way.  Exactly _why_ is it bad, in your opinion?

Because it's not possible to use the various Summary buffer commands
(like process-marking) to operate on stuff.  I don't know what Mew
does, but I know how I'd *like* to see it look.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
4.  Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if
    it bee the sig of the Inner Circle.

Re: Features before the next millenium

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

> Steinar Bang <sb@metis.no> writes:
>> > What TM does today is very bad.  The right way to do it is via
>> > pseudo-articles, which is how `X u' works, for instance.
>> 
>> I saw that used in Mew.  A terrible idea from a UI viewpoint, IMHO.
>> 
>> I prefer the TM way.  Exactly _why_ is it bad, in your opinion?

> Because it's not possible to use the various Summary buffer commands
> (like process-marking) to operate on stuff.  

Except for replying to a MIME encapsulated forwarded message, or
refoldering this message, I fail to see how this could be useful
(however... those two I've frequently wanted to do).


- Steinar

Re: Features before the next millenium

[Robert Bihlmeyer]

Hi,

>>>>> On 16 Dec 1997 08:00:42 +0100
>>>>> Steinar Bang <sb@metis.no> said:

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

 >> Because it's not possible to use the various Summary buffer
 >> commands (like process-marking) to operate on stuff.

 Steinar> Except for replying to a MIME encapsulated forwarded
 Steinar> message, or refoldering this message, I fail to see how this
 Steinar> could be useful (however... those two I've frequently wanted
 Steinar> to do).

I'd like to be able to reply to (and quote) PGP-encrypted mail. I
can't do this in the buttonized way. With pseudo-articles I simply "R" 
the decrypted thing in the summary buffer.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: Features before the next millenium

[Dave Love]

Surely the Right Thing is to be configurable for buttons or new
articles.

Re: Features before the next millenium

[Jason L Tibbitts III]

>>>>> "SB" == Steinar Bang <sb@metis.no> writes:

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

>> What TM does today is very bad.  The right way to do it is via
>> pseudo-articles, which is how `X u' works, for instance.

SB> I saw that used in Mew.  A terrible idea from a UI viewpoint, IMHO.

I find it much easier to just expand a message to a list of its parts and
select the first than to do the TM thing and have to scan the article for
the hard-to-see separators.  And if I actually want to do something with a
single part, I have to change buffers and scroll around.  That's far from
intuitive for me.  So far, in fact, that I find it easier to just do it by
hand.  Looking at a multipart message with TM is like reading an unbursted
digest.  I think I'd even prefer it if Gnus treated MIME-multipart articles
like it treats digests.  (I.e. pop open a new summary buffer with the
pieces displayed.)  Not as ideal as popping open a list of parts in the
same Summary buffer, but more sensible to me than what TM does.

Good MIME handling was what kept me using Mew for my mail for over a year
after I switched my newsreading to Gnus.

 - J<

Re: Features before the next millenium

[Lars Magne Ingebrigtsen]

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

> I find it much easier to just expand a message to a list of its parts and
> select the first than to do the TM thing and have to scan the article for
> the hard-to-see separators.

Well -- this is Gnus, so we can do it both ways.  :-)

Well, if we had the MIME library, that is.  I'm not sure what method I
would prefer to use myself, but I think the tm way isn't my cup of
tea.  I don't want to leave the summary buffer, I think.

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

Re: Features before the next millenium

[Alan Shutko]

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

L> Well, if we had the MIME library, that is.  I'm not sure what
L> method I would prefer to use myself, but I think the tm way isn't
L> my cup of tea.  I don't want to leave the summary buffer, I think.

Personally, I'd like it both ways at once!

There are a lot of content types which would make sense to be
displayed inline, such as text/plain, enriched, html, images, etc.  On
the other hand, if I want to save one, it would be nice to do it from
the summary buffer.

(BTW, one thing on the todo list if we get the mime library... _I want
to be able to quote HTML when replying!_  TM makes me throw it up in a
web browser, so I can't yank in text I'm replying to....

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
Comedy, like Medicine, was never meant to be practiced by the general public.

Re: Features before the next millenium

[Steinar Bang]

>>>>> Alan Shutko <ats@acm.org>:

>>>>> "L" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
L> Well, if we had the MIME library, that is.  I'm not sure what
L> method I would prefer to use myself, but I think the tm way isn't
L> my cup of tea.  I don't want to leave the summary buffer, I think.

> Personally, I'd like it both ways at once!

After closer thought.  I agree.

> There are a lot of content types which would make sense to be
> displayed inline, such as text/plain, enriched, html, images, etc. 

Yep.  This was what annoyed me about the Mew way.  I didn't make sense
to me that a GIF meant to be inline, should be a "separate article".

> On the other hand, if I want to save one, it would be nice to do it
> from the summary buffer.

True.  But it would be nice if message parts meant to be displayed
inline, actually were displayed inline, in a single *Article* buffer.

But like others have said: pseudo articles makes sense for forwarded
messages (well... *I* said that...), digests and PGP signed articles. 

> (BTW, one thing on the todo list if we get the mime library... _I want
> to be able to quote HTML when replying!_  TM makes me throw it up in a
> web browser, so I can't yank in text I'm replying to....

Agreed.  I've been thinking about hacking TM to use w3-mode.el to
smooth out the HTML, and then hopefully being able to reply to it.
But I've never found the energy to do so.


- Steinar

Re: Features before the next millenium

[Justin Sheehy]

Steinar Bang <sb@metis.no> writes:

> But it would be nice if message parts meant to be displayed inline,
> actually were displayed inline, in a single *Article* buffer.

This is tangential to the real discussion here, but how can a message
part[0] be "meant" to be displayed inline?

Email and Usenet are not page layout media.[1]  How would you 
specify in an email that some attachment should be `inline'?

And why on earth would you want to?

The strongest thing about email (and news) is that it is ubiquitous.
This is possible because it uses something nice and portable.  Text.

Then again, HTML wasn't meant to be a page layout language either, and
it's ended up as one.  Very unfortunate.

> Agreed.  I've been thinking about hacking TM to use w3-mode.el to
> smooth out the HTML, and then hopefully being able to reply to it.

I suppose.

For me, the only response that makes sense to an HTMLized email or
news post is "I have deleted your message unread."

To each their own, I guess.

[0]  making the big assumption for the moment that a `message' is
     generally either email or usenet.  although I can't think of
     anything that i would consider a message that this would be
     different for.

[1]  well, except for alt.fan.warlord, but.

-- 
Justin Sheehy

In a cloud bones of steel.
  

Re: Features before the next millenium

[William M. Perry]

Justin Sheehy <justin@linus.mitre.org> writes:

> Steinar Bang <sb@metis.no> writes:
> 
> > But it would be nice if message parts meant to be displayed inline,
> > actually were displayed inline, in a single *Article* buffer.
> 
> This is tangential to the real discussion here, but how can a message
> part[0] be "meant" to be displayed inline?

  The content-disposition header allows you to specify this.  'inline'
means simply that it is part of the message flow, not an attachment that
should just show up as something to be extracted from the message and saved 
to disk, etc.  At least in my understanding. :)

-Bill P.

Re: Features before the next millenium

[Justin Sheehy]

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

> > This is tangential to the real discussion here, but how can a message
> > part[0] be "meant" to be displayed inline?
> 
>   The content-disposition header allows you to specify this.  'inline'
> means simply that it is part of the message flow, not an attachment that
> should just show up as something to be extracted from the message and saved 
> to disk, etc.

Okay.  Conceded.

I only know as much MIME as I need to, so I never really noticed that.

I still see little point in it.

But that's just me.

-- 
Justin Sheehy

In a cloud bones of steel.
  

Re: Features before the next millenium

[Kai Grossjohann]

>>>>> On 17 Dec 1997, Justin Sheehy said:

  Justin> This is tangential to the real discussion here, but how can a message
  Justin> part[0] be "meant" to be displayed inline?

  Justin> Email and Usenet are not page layout media.[1]  How would you 
  Justin> specify in an email that some attachment should be `inline'?

There is a MIME header Contend-disposition.  Many MUAs seem to use
Content-disposition=attachment (or whatever the syntax is).

-- 
Kai Grossjohann, Informatik VI        grossjohann@ls6.cs.uni-dortmund.de
Uni Dortmund, D-44221 Dortmund        http://ls6-www.cs.uni-dortmund.de/
                                      Vox +49 231 755 5670, Fax -2405
I like both kinds of music.

Re: Features before the next millenium

[Dave Love]

>>>>> "Steinar" == Steinar Bang <sb@metis.no> writes:

 Steinar> Agreed.  I've been thinking about hacking TM to use
 Steinar> w3-mode.el to smooth out the HTML, and then hopefully being
 Steinar> able to reply to it.

If one can't merely to junk html-ized mail (sigh), one possibility for
a pseudo-external browser for TM is to invoke W3 via gnudoit a la
browse-url, but assuming gnuclient is running in the current Emacs
rather than a separate one.  You might need a trivial wrapper script
to get the gnudoit command line right.

Re: Features before the next millenium

[Alan Shutko]

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

D> If one can't merely to junk html-ized mail (sigh), one possibility
D> for a pseudo-external browser for TM is to invoke W3 via gnudoit a
D> la browse-url, but assuming gnuclient is running in the current
D> Emacs rather than a separate one.  You might need a trivial wrapper
D> script to get the gnudoit command line right.

It'll already do a browse-url on it, running whatever browser you
want.  That's ok if all you want to do is view it (with considerable
pain).  But if you want to reply to it, you're screwed.

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
Anything free is worth what you pay for it.

Re: Features before the next millenium

[Justin Sheehy]

Alan Shutko <ats@acm.org> writes:

(Regarding HTML email)

> But if you want to reply to it, you're screwed.

You can reply to HTML email.

Just like you can reply to a GIF that someone sends you in email.

Same idea.

If what you meant was HTML as if it were a valid format for the actual
text of messages... that very idea is, to use your words, screwed.

-- 
Justin Sheehy

In a cloud bones of steel.
  

Re: Features before the next millenium

[Robert Bihlmeyer]

Hi,

>>>>> On 17 Dec 1997 20:31:24 -0500
>>>>> Justin Sheehy <justin@linus.mitre.org> said:

 Justin> You can reply to HTML email.
             ^^^
suppose you meant "can't" there.

 Justin> Just like you can reply to a GIF that someone sends you in
 Justin> email.

There are trivial methods to get text from HTML, which is not true for 
GIF. So your comparison is somewhat ... ehh ... screwed.

If you want to reply non-flameish to HTML mail. I don't.

	Robbe

-- 
Robert Bihlmeyer	reads: Deutsch, English, MIME, Latin-1, NO SPAM!
<robbe@orcus.priv.at>	<http://stud2.tuwien.ac.at/~e9426626/sig.html>

Re: Features before the next millenium

[Dave Love]

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

 Lars> Well, if we had the MIME library, that is.  

Has mm.el and/or the guts of rmime.el been examined and found
unsuitable?

Re: Features before the next millenium

[William M. Perry]

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

> >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
>  Lars> Well, if we had the MIME library, that is.  
> 
> Has mm.el and/or the guts of rmime.el been examined and found
> unsuitable?

  mm.el might be a good place to start, but it needs a lot of work.  I
know, I wrote it.  The only piece I'd _really_ like to see used out of
there is the standard mailcap parsing stuff.  I _really_ don't think you
want to go and invent yet another mime registry in elisp for what viewers
get used when, etc.

-Bill P.

Re: Features before the next millenium

[Alan Shutko]

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

B> I _really_
B> don't think you want to go and invent yet another mime registry in
B> elisp for what viewers get used when, etc.

Can the current setup handle things where you want elisp to display
types?

-- 
Alan Shutko <ats@acm.org> - By consent of the corrupted
Any fool can paint a picture, but it takes a wise person to be able to sell it.

Re: Features before the next millenium

[William M. Perry]

Alan Shutko <ats@acm.org> writes:

> >>>>> "B" == William M Perry <wmperry@aventail.com> writes:
> 
> B> I _really_
> B> don't think you want to go and invent yet another mime registry in
> B> elisp for what viewers get used when, etc.
> 
> Can the current setup handle things where you want elisp to display
> types?

  You can.  You can even have tests based upon emacs lisp code (as oppsed
to shell-based stuff like the mailcap stuff uses), as well as mix the two.
There is a programmatic access to the registry from elisp, but it doesn't
go so far as to actually edit the mailcap file on disk, but that is on the
todo/would-be-nice list.

-Bill P.

Re: Features before the next millenium

[Dave Love]

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

 Lars> What I would love to see is a general, basic MIME library that
 Lars> does nothing smart at all.  Just something that provides
 Lars> functionality like, uh, `mime-decode-buffer',
 Lars> `mime-decode-buffer-to-file', `mime-decode-string'.  You know.
 Lars> *Basic* things.  Then I could (and would) use it in Gnus.

Bill Perry is Ghod!  (mm.el in W3 is at least a start.)

 Lars> Writing packages that work the other way around (i.e., provides
 Lars> functionality to lots of packages by "infecting" them) never
 Lars> works properly.

rmime is a matter of 
  (setq gnus-show-mime-method 'rmime-format)
and a mailcap file, so it's not highly infectious and looks as though
it might decompose reasonably.  It isn't obviously being maintained
and could probably do with some tarting up (modulo copyright
assignment?).  <URL:http://www.cinti.net/~rmoody/rmime>

Presumably MULEtilation is required these days; a little demotivating
for hacking.