* MIME variables @ 1999-07-04 5:21 Lars Magne Ingebrigtsen 1999-07-04 15:55 ` Hrvoje Niksic 1999-07-04 20:06 ` Kai.Grossjohann 0 siblings, 2 replies; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-04 5:21 UTC (permalink / raw) I think the following should reflect the state in 0.91: Customization ============= `mm-inline-media-tests' This is an alist where the key is a MIME type, the second element is a function to display the part "inline" (i.e., inside Emacs), and the third element is a form to be `eval'ed to say whether the part can be displayed inline. This variable specifies whether a part _can_ be displayed inline, and, if so, how to do it. It does not say whether parts are _actually_ displayed inline. `mm-inlines-types' This, on the other hand, says what types are to be displayed inline, if they satisfy the conditions set by the variable above. It's a list of MIME media types. `mm-automatic-display' This is a list of types that are to be displayed "automatically", but only if the above variable allows it. That is, only inlinable parts are usually displayed automatically, but in the end, this is up to the display agent that's using the MIME library. `mm-attachment-override-types' Some MIME agents create parts that have a content-disposition of `attachment'. This variable allows overriding that disposition and displaying the part inline. `mm-discouraged-alternatives' List of MIME types that are discouraged when viewing `multipart/alternative'. Viewing agents are supposed to view the last possible part of a message, as that is supposed to be the richest. However, users may prefer other types instead, and this list says what types are most unwanted. If, for instance, `text/html' parts are very unwanted, and `text/richtech' parts are somewhat unwanted, then the value of this variable should be set to: ("text/html" "text/richtext") `mm-all-images-fit' If non-`nil', all images will be deemed to fit into the buffer, even when they don't. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-04 5:21 MIME variables Lars Magne Ingebrigtsen @ 1999-07-04 15:55 ` Hrvoje Niksic 1999-07-04 20:09 ` Kai.Grossjohann 1999-07-05 4:16 ` Lars Magne Ingebrigtsen 1999-07-04 20:06 ` Kai.Grossjohann 1 sibling, 2 replies; 16+ messages in thread From: Hrvoje Niksic @ 1999-07-04 15:55 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > I think the following should reflect the state in 0.91: > > Customization > ============= > > `mm-inline-media-tests' > This is an alist where the key is a MIME type, the second element > is a function to display the part "inline" (i.e., inside Emacs), > and the third element is a form to be `eval'ed to say whether the > part can be displayed inline. I think the third element should be a function that will be called with one argument, the MIME part. Besides being more Lispy, it allows the programmer to inspect the part when making the decision. Also, the variable could probably stand a better name. `mm-inline-media-tests' is, uhm, less than suggestive. > `mm-inlines-types' > This, on the other hand, says what types are to be displayed > inline, if they satisfy the conditions set by the variable above. > It's a list of MIME media types. Maybe this should also allow a function, or a list of them. > `mm-automatic-display' > This is a list of types that are to be displayed "automatically", > but only if the above variable allows it. That is, only inlinable > parts are usually displayed automatically, but in the end, this is > up to the display agent that's using the MIME library. Another one that could be named better. I, for one, am not sure what "automatical" display means, and how it differs from "inline". > `mm-attachment-override-types' > Some MIME agents create parts that have a content-disposition of > `attachment'. This variable allows overriding that disposition and > displaying the part inline. I think this variable is misconceived, at least as far as text/plain goes. Many patches are rightfully sent out as "attachments", and I don't get the button for them (I have to press `K b' explicitly, which is quite slow.) Mind you, it's perfectly fine for the type to be *displayed* by default, but the button should still be there for attachments. Broken software that generates bogus content-dispositions should not be catered to. On the other hand, text/x-vcard probably fits this variable perfectly, so I guess it's only its default value I have a problem with. > `mm-all-images-fit' > If non-`nil', all images will be deemed to fit into the buffer, > even when they don't. This requires further explanation and possibly a rename. How about: When displaying inline images that are larger than the window inline, XEmacs does not enable scrolling, which means that you cannot see the whole image. To prevent this, Gnus tries to determine the image size before displaying it inline, and if it doesn't fit the window, Gnus will display it externally (e.g. with ImageMagick or xv). Setting this variable to nil disables this check and makes Gnus display all inline images as inline, regardless of their size. Consequently, a good name could be something like `mm-display-large-images-externally' or `mm-display-externally-images-larger-than-window', or... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-04 15:55 ` Hrvoje Niksic @ 1999-07-04 20:09 ` Kai.Grossjohann 1999-07-05 4:17 ` Lars Magne Ingebrigtsen 1999-07-05 4:16 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 16+ messages in thread From: Kai.Grossjohann @ 1999-07-04 20:09 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > Another one that could be named better. I, for one, am not sure what > "automatical" display means, and how it differs from "inline". I think automatic display means that you see the part without having to press the corresponding button. Suppose I use xv to display images, then automatic display of images means that xv is started, err, _automatically_ ;-) So you could say that text/html is displayed inline but not automatically. This way, you'd have to hit RET on the corresponding button to have w3 render the part in the buffer. Though the documentation seems to suggest (at least half-way) that externally-displayed parts are never displayed automatically... kai -- Life is hard and then you die. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-04 20:09 ` Kai.Grossjohann @ 1999-07-05 4:17 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-05 4:17 UTC (permalink / raw) Kai.Grossjohann@CS.Uni-Dortmund.DE writes: > Though the documentation seems to suggest (at least half-way) that > externally-displayed parts are never displayed automatically... Yup. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-04 15:55 ` Hrvoje Niksic 1999-07-04 20:09 ` Kai.Grossjohann @ 1999-07-05 4:16 ` Lars Magne Ingebrigtsen 1999-07-05 13:15 ` Hrvoje Niksic 1 sibling, 1 reply; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-05 4:16 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > I think the third element should be a function that will be called > with one argument, the MIME part. Besides being more Lispy, it allows > the programmer to inspect the part when making the decision. Yes, but it's more convenient the current way. The default value is ("image/gif" mm-inline-image (mm-valid-and-fit-image-p 'gif handle)) ("image/tiff" mm-inline-image (mm-valid-and-fit-image-p 'tiff handle)) [...] ("text/html" mm-inline-text (locate-library "w3")) Of course, I could just wrap all these in `lambda's, which would make things more better, although more verbose. As well as making the magic `handle' dynamic variable explicit. I dunno. > Also, the variable could probably stand a better name. > `mm-inline-media-tests' is, uhm, less than suggestive. Well, they are tests to see whether media can be displayed inline... :-) > > `mm-inlines-types' > > This, on the other hand, says what types are to be displayed > > inline, if they satisfy the conditions set by the variable above. > > It's a list of MIME media types. > > Maybe this should also allow a function, or a list of them. The idea is that the first variable says whether something is possible, and if so, how to do it, while the second says whether we want it or not, so I don't see any need to re-specify a function here. The first variable will probably not be altered by the user, while the second probably will be. > > `mm-automatic-display' > > This is a list of types that are to be displayed "automatically", > > but only if the above variable allows it. That is, only inlinable > > parts are usually displayed automatically, but in the end, this is > > up to the display agent that's using the MIME library. > > Another one that could be named better. I, for one, am not sure what > "automatical" display means, and how it differs from "inline". In a Gnus context, this specifies which types that are displayed when you select an article. This is usually a subset of the types that can we want to be inlined. For instance, we can inline audio/*, but we don't want it to be displayed automatically. > > `mm-attachment-override-types' > > Some MIME agents create parts that have a content-disposition of > > `attachment'. This variable allows overriding that disposition and > > displaying the part inline. > > I think this variable is misconceived, at least as far as text/plain > goes. Many patches are rightfully sent out as "attachments", and I > don't get the button for them (I have to press `K b' explicitly, which > is quite slow.) But patches shouldn't be text/plain, since they aren't... > Mind you, it's perfectly fine for the type to be *displayed* by > default, but the button should still be there for attachments. Broken > software that generates bogus content-dispositions should not be > catered to. I agree with that. Perhaps I should just alter the default to exclude text/plain, and then the user who want to cater to such software can add it? > > `mm-all-images-fit' > > If non-`nil', all images will be deemed to fit into the buffer, > > even when they don't. > > This requires further explanation and possibly a rename. How about: I've included your version. > Consequently, a good name could be something like > `mm-display-large-images-externally' or > `mm-display-externally-images-larger-than-window', or... `mm-inline-large-images'. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-05 4:16 ` Lars Magne Ingebrigtsen @ 1999-07-05 13:15 ` Hrvoje Niksic 1999-07-05 13:52 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 16+ messages in thread From: Hrvoje Niksic @ 1999-07-05 13:15 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > ("image/gif" mm-inline-image (mm-valid-and-fit-image-p 'gif handle)) > ("image/tiff" mm-inline-image (mm-valid-and-fit-image-p 'tiff handle)) > > [...] > > ("text/html" mm-inline-text (locate-library "w3")) > > Of course, I could just wrap all these in `lambda's, which would > make things more better, although more verbose. As well as making > the magic `handle' dynamic variable explicit. Please please do. At the cost of a few more words, the code will be much saner, and easier to replace with something else. > > Also, the variable could probably stand a better name. > > `mm-inline-media-tests' is, uhm, less than suggestive. > > Well, they are tests to see whether media can be displayed inline... > :-) How about `mm-types-displayable-inline'? > > > `mm-inlines-types' > > > This, on the other hand, says what types are to be displayed > > > inline, if they satisfy the conditions set by the variable above. > > > It's a list of MIME media types. > > > > Maybe this should also allow a function, or a list of them. > > The idea is that the first variable says whether something is > possible, and if so, how to do it, while the second says whether we > want it or not, so I don't see any need to re-specify a function > here. The first variable will probably not be altered by the user, > while the second probably will be. How about `mm-types-displayed-inline'? :-) > > > `mm-attachment-override-types' > > > Some MIME agents create parts that have a content-disposition of > > > `attachment'. This variable allows overriding that disposition and > > > displaying the part inline. > > > > I think this variable is misconceived, at least as far as > > text/plain goes. Many patches are rightfully sent out as > > "attachments", and I don't get the button for them (I have to > > press `K b' explicitly, which is quite slow.) > > But patches shouldn't be text/plain, since they aren't... Huh? > > Mind you, it's perfectly fine for the type to be *displayed* by > > default, but the button should still be there for attachments. Broken > > software that generates bogus content-dispositions should not be > > catered to. > > I agree with that. Perhaps I should just alter the default to > exclude text/plain, and then the user who want to cater to such > software can add it? Please do. I've asked for this before, but I guess the mail got lost. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-05 13:15 ` Hrvoje Niksic @ 1999-07-05 13:52 ` Lars Magne Ingebrigtsen 1999-07-05 13:54 ` Hrvoje Niksic 0 siblings, 1 reply; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-05 13:52 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > Please please do. At the cost of a few more words, the code will be > much saner, and easier to replace with something else. Well, I agree about the sanity, but how would this make it easier to replace it with something else? > > > Also, the variable could probably stand a better name. > > > `mm-inline-media-tests' is, uhm, less than suggestive. > > > > Well, they are tests to see whether media can be displayed inline... > > :-) > > How about `mm-types-displayable-inline'? I like my name better. :-) > > But patches shouldn't be text/plain, since they aren't... > > Huh? Patches should be application/octet-stream or application/x-patch. > > I agree with that. Perhaps I should just alter the default to > > exclude text/plain, and then the user who want to cater to such > > software can add it? > > Please do. Ok; I've removed it. > I've asked for this before, but I guess the mail got lost. Probably not lost, but I have 323 unread articles in nnml:misc and 168 unread in nnml:gnus-bug. I'll get to them Any Day Now. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-05 13:52 ` Lars Magne Ingebrigtsen @ 1999-07-05 13:54 ` Hrvoje Niksic 1999-07-06 4:42 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 16+ messages in thread From: Hrvoje Niksic @ 1999-07-05 13:54 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Hrvoje Niksic <hniksic@srce.hr> writes: > > > Please please do. At the cost of a few more words, the code will be > > much saner, and easier to replace with something else. > > Well, I agree about the sanity, but how would this make it easier to > replace it with something else? Well, I can do: (defun my-handle-tester (handle) ... lots of code here ...) ...and then I can stick `my-handle-tester' as the function. And it's more Lispy anyway. :-) > > > > Also, the variable could probably stand a better name. > > > > `mm-inline-media-tests' is, uhm, less than suggestive. > > > > > > Well, they are tests to see whether media can be displayed inline... > > > :-) > > > > How about `mm-types-displayable-inline'? > > I like my name better. :-) What you'll name the variable "Lars Magne Ingebrigtsen"??? :-) > > > But patches shouldn't be text/plain, since they aren't... > > > > Huh? > > Patches should be application/octet-stream or application/x-patch. Yuck. As an example, patches sent to xemacs-reviews are meant to be read by humans as least as much as they are meant for the machine. I think it's perfectly fine to send them off as text/plain. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-05 13:54 ` Hrvoje Niksic @ 1999-07-06 4:42 ` Lars Magne Ingebrigtsen 1999-07-06 15:17 ` Hrvoje Niksic 0 siblings, 1 reply; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-06 4:42 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > (defun my-handle-tester (handle) > ... lots of code here ...) > > ...and then I can stick `my-handle-tester' as the function. You can just stick `(my-handle-tester handle)' into the alist. > And it's more Lispy anyway. :-) I agree with that, so I've now lambdified the variable. > What you'll name the variable "Lars Magne Ingebrigtsen"??? :-) > > Patches should be application/octet-stream or application/x-patch. > > Yuck. As an example, patches sent to xemacs-reviews are meant to be > read by humans as least as much as they are meant for the machine. I > think it's perfectly fine to send them off as text/plain. text/x-patch would perhaps be better? That would mean that they are human-readable, but not plain. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-06 4:42 ` Lars Magne Ingebrigtsen @ 1999-07-06 15:17 ` Hrvoje Niksic 1999-07-06 16:01 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 16+ messages in thread From: Hrvoje Niksic @ 1999-07-06 15:17 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > text/x-patch would perhaps be better? That would mean that they are > human-readable, but not plain. Probably. Yes. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-06 15:17 ` Hrvoje Niksic @ 1999-07-06 16:01 ` Lars Magne Ingebrigtsen 1999-07-06 21:41 ` David Kågedal 0 siblings, 1 reply; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-06 16:01 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > > text/x-patch would perhaps be better? That would mean that they are > > human-readable, but not plain. > > Probably. Yes. I'm just off for bed, but does the MIME RFC's say anything in particular about doing stuff like text/x-patch? I know that it's common to do application/x-whatever, but I don't really recall seeing many x-whatevers as subtypes of the text type... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-06 16:01 ` Lars Magne Ingebrigtsen @ 1999-07-06 21:41 ` David Kågedal 1999-07-07 11:53 ` Robert Bihlmeyer 0 siblings, 1 reply; 16+ messages in thread From: David Kågedal @ 1999-07-06 21:41 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Hrvoje Niksic <hniksic@srce.hr> writes: > > > > text/x-patch would perhaps be better? That would mean that they are > > > human-readable, but not plain. > > > > Probably. Yes. > > I'm just off for bed, but does the MIME RFC's say anything in > particular about doing stuff like text/x-patch? I know that it's > common to do application/x-whatever, but I don't really recall seeing > many x-whatevers as subtypes of the text type... Looking at RFC 2045, I see tht the BNF grammar allows subtypes of the x-* variety. Scanning quickly through the document, I see no other restrictions. RFC 2046 has the following to say about text/*: (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched". [...] The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden. This rule applies regardless of format or character set or sets involved. [...] 4.1.4. Unrecognized Subtypes Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset. Unrecognized subtypes which also specify an unrecognized charset should be treated as "application/octet- stream". -- David Kågedal <davidk@lysator.liu.se> http://www.lysator.liu.se/~davidk/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-06 21:41 ` David Kågedal @ 1999-07-07 11:53 ` Robert Bihlmeyer 1999-07-08 7:11 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 16+ messages in thread From: Robert Bihlmeyer @ 1999-07-07 11:53 UTC (permalink / raw) Hi, >>>>> On 06 Jul 1999 23:41:34 +0200 >>>>> davidk@lysator.liu.se (David Kågedal) said: David> Looking at RFC 2045, I see tht the BNF grammar allows subtypes David> of the x-* variety. Scanning quickly through the document, I David> see no other restrictions. So it's not forbidden. David> RFC 2046 has the following to say about text/*: 2046> (1) text -- textual information. The subtype "plain" in 2046> particular indicates plain text containing no formatting 2046> commands or directives of any sort. Plain text is intended to 2046> be displayed "as-is". No special software is required to get 2046> the full meaning of the text, aside from support for the 2046> indicated character set. This would imply text/plain, though. text/x-patch is in all ways better than any application/foo-bar, because: 2046> Unrecognized subtypes of "text" should be treated as subtype 2046> "plain" as long as the MIME implementation knows how to handle 2046> the charset. I still think text/x-patch is better, since it would make it so easy to have a different default action for patches. And they are differently formated than plain text after all ... 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] 16+ messages in thread
* Re: MIME variables 1999-07-07 11:53 ` Robert Bihlmeyer @ 1999-07-08 7:11 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-08 7:11 UTC (permalink / raw) Robert Bihlmeyer <e9426626@stud2.tuwien.ac.at> writes: > I still think text/x-patch is better, since it would make it so easy > to have a different default action for patches. And they are > differently formated than plain text after all ... I'm now defaulting *.patch to text/x-patch. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-04 5:21 MIME variables Lars Magne Ingebrigtsen 1999-07-04 15:55 ` Hrvoje Niksic @ 1999-07-04 20:06 ` Kai.Grossjohann 1999-07-05 4:20 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 16+ messages in thread From: Kai.Grossjohann @ 1999-07-04 20:06 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > `mm-inline-media-tests' > `mm-inlines-types' ^ Why this `s'? It seems inconsistent. But maybe there's a good reason... > `mm-automatic-display' > This is a list of types that are to be displayed "automatically", > but only if the above variable allows it. In this sentence, you say that non-inlined parts are *never* displayed automatically. > That is, only inlinable parts are usually displayed automatically, > but in the end, this is up to the display agent that's using the > MIME library. Here, you say that non-inlined parts are *seldom* displayed automatically. Which one is right? kai -- Life is hard and then you die. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: MIME variables 1999-07-04 20:06 ` Kai.Grossjohann @ 1999-07-05 4:20 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 16+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-07-05 4:20 UTC (permalink / raw) Kai.Grossjohann@CS.Uni-Dortmund.DE writes: > > `mm-inline-media-tests' > > `mm-inlines-types' > ^ > Why this `s'? It seems inconsistent. But maybe there's a good > reason... Typo. Should be "d". > > `mm-automatic-display' > > This is a list of types that are to be displayed "automatically", > > but only if the above variable allows it. > > In this sentence, you say that non-inlined parts are *never* displayed > automatically. Yup. Which is good, since that's the case. :-) > > That is, only inlinable parts are usually displayed automatically, > > but in the end, this is up to the display agent that's using the > > MIME library. > > Here, you say that non-inlined parts are *seldom* displayed > automatically. Which one is right? I've now deleted this last part. I'm not quite sure what I was getting it here... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1999-07-08 7:11 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-07-04 5:21 MIME variables Lars Magne Ingebrigtsen 1999-07-04 15:55 ` Hrvoje Niksic 1999-07-04 20:09 ` Kai.Grossjohann 1999-07-05 4:17 ` Lars Magne Ingebrigtsen 1999-07-05 4:16 ` Lars Magne Ingebrigtsen 1999-07-05 13:15 ` Hrvoje Niksic 1999-07-05 13:52 ` Lars Magne Ingebrigtsen 1999-07-05 13:54 ` Hrvoje Niksic 1999-07-06 4:42 ` Lars Magne Ingebrigtsen 1999-07-06 15:17 ` Hrvoje Niksic 1999-07-06 16:01 ` Lars Magne Ingebrigtsen 1999-07-06 21:41 ` David Kågedal 1999-07-07 11:53 ` Robert Bihlmeyer 1999-07-08 7:11 ` Lars Magne Ingebrigtsen 1999-07-04 20:06 ` Kai.Grossjohann 1999-07-05 4:20 ` Lars Magne Ingebrigtsen
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).