* Features before the next millenium @ 1997-12-05 14:22 Hrvoje Niksic 1997-12-05 14:58 ` Karl Kleinpaste ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Hrvoje Niksic @ 1997-12-05 14:22 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-05 14:22 Features before the next millenium Hrvoje Niksic @ 1997-12-05 14:58 ` Karl Kleinpaste 1997-12-05 15:49 ` Aaron M. Ucko 1997-12-06 14:45 ` Lars Magne Ingebrigtsen 2 siblings, 0 replies; 30+ messages in thread From: Karl Kleinpaste @ 1997-12-05 14:58 UTC (permalink / raw) 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. :-) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-05 14:22 Features before the next millenium Hrvoje Niksic 1997-12-05 14:58 ` Karl Kleinpaste @ 1997-12-05 15:49 ` Aaron M. Ucko 1997-12-06 14:45 ` Lars Magne Ingebrigtsen 2 siblings, 0 replies; 30+ messages in thread From: Aaron M. Ucko @ 1997-12-05 15:49 UTC (permalink / raw) 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] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-05 14:22 Features before the next millenium Hrvoje Niksic 1997-12-05 14:58 ` Karl Kleinpaste 1997-12-05 15:49 ` Aaron M. Ucko @ 1997-12-06 14:45 ` Lars Magne Ingebrigtsen 1997-12-06 15:28 ` Steinar Bang 1997-12-06 18:23 ` Dave Love 2 siblings, 2 replies; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-12-06 14:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-06 14:45 ` Lars Magne Ingebrigtsen @ 1997-12-06 15:28 ` Steinar Bang 1997-12-14 10:33 ` Lars Magne Ingebrigtsen 1997-12-06 18:23 ` Dave Love 1 sibling, 1 reply; 30+ messages in thread From: Steinar Bang @ 1997-12-06 15:28 UTC (permalink / raw) >>>>> 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) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-06 15:28 ` Steinar Bang @ 1997-12-14 10:33 ` Lars Magne Ingebrigtsen 1997-12-15 7:06 ` Steinar Bang 0 siblings, 1 reply; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-12-14 10:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-14 10:33 ` Lars Magne Ingebrigtsen @ 1997-12-15 7:06 ` Steinar Bang 1997-12-15 13:23 ` Hrvoje Niksic 0 siblings, 1 reply; 30+ messages in thread From: Steinar Bang @ 1997-12-15 7:06 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-15 7:06 ` Steinar Bang @ 1997-12-15 13:23 ` Hrvoje Niksic 1997-12-15 16:34 ` Steinar Bang 0 siblings, 1 reply; 30+ messages in thread From: Hrvoje Niksic @ 1997-12-15 13:23 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-15 13:23 ` Hrvoje Niksic @ 1997-12-15 16:34 ` Steinar Bang 1997-12-15 18:29 ` Hrvoje Niksic 1997-12-16 8:24 ` Jason L Tibbitts III 0 siblings, 2 replies; 30+ messages in thread From: Steinar Bang @ 1997-12-15 16:34 UTC (permalink / raw) >>>>> 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? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-15 16:34 ` Steinar Bang @ 1997-12-15 18:29 ` Hrvoje Niksic 1997-12-16 7:00 ` Steinar Bang 1997-12-16 8:24 ` Jason L Tibbitts III 1 sibling, 1 reply; 30+ messages in thread From: Hrvoje Niksic @ 1997-12-15 18:29 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-15 18:29 ` Hrvoje Niksic @ 1997-12-16 7:00 ` Steinar Bang 1997-12-16 16:31 ` Robert Bihlmeyer 0 siblings, 1 reply; 30+ messages in thread From: Steinar Bang @ 1997-12-16 7:00 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-16 7:00 ` Steinar Bang @ 1997-12-16 16:31 ` Robert Bihlmeyer 1997-12-16 18:51 ` Dave Love 0 siblings, 1 reply; 30+ messages in thread From: Robert Bihlmeyer @ 1997-12-16 16:31 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-16 16:31 ` Robert Bihlmeyer @ 1997-12-16 18:51 ` Dave Love 0 siblings, 0 replies; 30+ messages in thread From: Dave Love @ 1997-12-16 18:51 UTC (permalink / raw) Surely the Right Thing is to be configurable for buttons or new articles. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-15 16:34 ` Steinar Bang 1997-12-15 18:29 ` Hrvoje Niksic @ 1997-12-16 8:24 ` Jason L Tibbitts III 1997-12-16 17:07 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 30+ messages in thread From: Jason L Tibbitts III @ 1997-12-16 8:24 UTC (permalink / raw) >>>>> "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< ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-16 8:24 ` Jason L Tibbitts III @ 1997-12-16 17:07 ` Lars Magne Ingebrigtsen 1997-12-16 18:47 ` Alan Shutko 1997-12-17 19:31 ` Dave Love 0 siblings, 2 replies; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 1997-12-16 17:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-16 17:07 ` Lars Magne Ingebrigtsen @ 1997-12-16 18:47 ` Alan Shutko 1997-12-17 7:04 ` Steinar Bang 1997-12-17 19:31 ` Dave Love 1 sibling, 1 reply; 30+ messages in thread From: Alan Shutko @ 1997-12-16 18:47 UTC (permalink / raw) >>>>> "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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-16 18:47 ` Alan Shutko @ 1997-12-17 7:04 ` Steinar Bang 1997-12-17 18:12 ` Justin Sheehy 1997-12-17 19:31 ` Dave Love 0 siblings, 2 replies; 30+ messages in thread From: Steinar Bang @ 1997-12-17 7:04 UTC (permalink / raw) >>>>> 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 7:04 ` Steinar Bang @ 1997-12-17 18:12 ` Justin Sheehy 1997-12-17 18:28 ` William M. Perry 1997-12-17 18:45 ` Kai Grossjohann 1997-12-17 19:31 ` Dave Love 1 sibling, 2 replies; 30+ messages in thread From: Justin Sheehy @ 1997-12-17 18:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 18:12 ` Justin Sheehy @ 1997-12-17 18:28 ` William M. Perry 1997-12-17 18:31 ` Justin Sheehy 1997-12-17 18:45 ` Kai Grossjohann 1 sibling, 1 reply; 30+ messages in thread From: William M. Perry @ 1997-12-17 18:28 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 18:28 ` William M. Perry @ 1997-12-17 18:31 ` Justin Sheehy 0 siblings, 0 replies; 30+ messages in thread From: Justin Sheehy @ 1997-12-17 18:31 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 18:12 ` Justin Sheehy 1997-12-17 18:28 ` William M. Perry @ 1997-12-17 18:45 ` Kai Grossjohann 1 sibling, 0 replies; 30+ messages in thread From: Kai Grossjohann @ 1997-12-17 18:45 UTC (permalink / raw) Cc: ding >>>>> 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 7:04 ` Steinar Bang 1997-12-17 18:12 ` Justin Sheehy @ 1997-12-17 19:31 ` Dave Love 1997-12-18 0:02 ` Alan Shutko 1 sibling, 1 reply; 30+ messages in thread From: Dave Love @ 1997-12-17 19:31 UTC (permalink / raw) >>>>> "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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 19:31 ` Dave Love @ 1997-12-18 0:02 ` Alan Shutko 1997-12-18 1:31 ` Justin Sheehy 0 siblings, 1 reply; 30+ messages in thread From: Alan Shutko @ 1997-12-18 0:02 UTC (permalink / raw) Cc: ding >>>>> "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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-18 0:02 ` Alan Shutko @ 1997-12-18 1:31 ` Justin Sheehy 1997-12-18 11:37 ` Robert Bihlmeyer 0 siblings, 1 reply; 30+ messages in thread From: Justin Sheehy @ 1997-12-18 1:31 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-18 1:31 ` Justin Sheehy @ 1997-12-18 11:37 ` Robert Bihlmeyer 0 siblings, 0 replies; 30+ messages in thread From: Robert Bihlmeyer @ 1997-12-18 11:37 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-16 17:07 ` Lars Magne Ingebrigtsen 1997-12-16 18:47 ` Alan Shutko @ 1997-12-17 19:31 ` Dave Love 1997-12-17 19:57 ` William M. Perry 1 sibling, 1 reply; 30+ messages in thread From: Dave Love @ 1997-12-17 19:31 UTC (permalink / raw) >>>>> "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? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 19:31 ` Dave Love @ 1997-12-17 19:57 ` William M. Perry 1997-12-17 23:59 ` Alan Shutko 0 siblings, 1 reply; 30+ messages in thread From: William M. Perry @ 1997-12-17 19:57 UTC (permalink / raw) Cc: ding 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 19:57 ` William M. Perry @ 1997-12-17 23:59 ` Alan Shutko 1997-12-18 14:54 ` William M. Perry 0 siblings, 1 reply; 30+ messages in thread From: Alan Shutko @ 1997-12-17 23:59 UTC (permalink / raw) Cc: Dave Love, ding >>>>> "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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-17 23:59 ` Alan Shutko @ 1997-12-18 14:54 ` William M. Perry 0 siblings, 0 replies; 30+ messages in thread From: William M. Perry @ 1997-12-18 14:54 UTC (permalink / raw) Cc: Dave Love, ding 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. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Features before the next millenium 1997-12-06 14:45 ` Lars Magne Ingebrigtsen 1997-12-06 15:28 ` Steinar Bang @ 1997-12-06 18:23 ` Dave Love 1 sibling, 0 replies; 30+ messages in thread From: Dave Love @ 1997-12-06 18:23 UTC (permalink / raw) >>>>> "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. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~1997-12-18 14:54 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-12-05 14:22 Features before the next millenium Hrvoje Niksic 1997-12-05 14:58 ` Karl Kleinpaste 1997-12-05 15:49 ` Aaron M. Ucko 1997-12-06 14:45 ` Lars Magne Ingebrigtsen 1997-12-06 15:28 ` Steinar Bang 1997-12-14 10:33 ` Lars Magne Ingebrigtsen 1997-12-15 7:06 ` Steinar Bang 1997-12-15 13:23 ` Hrvoje Niksic 1997-12-15 16:34 ` Steinar Bang 1997-12-15 18:29 ` Hrvoje Niksic 1997-12-16 7:00 ` Steinar Bang 1997-12-16 16:31 ` Robert Bihlmeyer 1997-12-16 18:51 ` Dave Love 1997-12-16 8:24 ` Jason L Tibbitts III 1997-12-16 17:07 ` Lars Magne Ingebrigtsen 1997-12-16 18:47 ` Alan Shutko 1997-12-17 7:04 ` Steinar Bang 1997-12-17 18:12 ` Justin Sheehy 1997-12-17 18:28 ` William M. Perry 1997-12-17 18:31 ` Justin Sheehy 1997-12-17 18:45 ` Kai Grossjohann 1997-12-17 19:31 ` Dave Love 1997-12-18 0:02 ` Alan Shutko 1997-12-18 1:31 ` Justin Sheehy 1997-12-18 11:37 ` Robert Bihlmeyer 1997-12-17 19:31 ` Dave Love 1997-12-17 19:57 ` William M. Perry 1997-12-17 23:59 ` Alan Shutko 1997-12-18 14:54 ` William M. Perry 1997-12-06 18:23 ` Dave Love
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).