* Re: Automatic part insertion: åäö and 吃哪塞 on the same line [not found] <6f67buzzff.fsf@dna.lth.se> @ 1998-12-02 9:41 ` Lars Magne Ingebrigtsen 1998-12-02 10:00 ` Russ Allbery ` (3 more replies) 1998-12-02 12:39 ` Vladimir Volovich 1998-12-02 16:26 ` Michael Harnois 2 siblings, 4 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 9:41 UTC (permalink / raw) Wow! I'm impressed bu Gnus' handling of this -- it was rendered perfectly, without a slightest hint that there was anything MIMEish about the message. The Scandinavian and Chinese characters on the same line in the body and everything. *gloat* :-) Could someone take a quick peek at the message from Kurt in a non-Gnus MIME-aware reader and see what it does when presented with a message that contains only text/plain parts, but with different charsets? Kurt Swanson <ksw@dna.lth.se> writes: > But if one places the very same line in the body, sgml-#parts must be > added manually: [...] > Couldn't this be quickly scanned to have #part's automatically added? > I.e. one starts out with the group default coding and then goes > through the body until a character not belonging to that coding is > found - insert #part, and then repeat for that encoding... Yes, I think MML should do that. The result will be displayed very nicely -- seen from Gnus, at least. :-) However, if someone (inadvertantly) mixed (*really* mixed) Chinese and Scandianvian (for instance, talking about two people who's names contain characters from two different charsets), then that might result in that someone (inadvertantly) sending out a really long and winding MIME message that might be annoying for the non-Gnus recipient to receive... Of course, MML might just ask the user whether to go ahead and multipart away or not... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen @ 1998-12-02 10:00 ` Russ Allbery 1998-12-02 12:49 ` Kurt Swanson ` (3 more replies) 1998-12-02 10:27 ` Matt Armstrong ` (2 subsequent siblings) 3 siblings, 4 replies; 70+ messages in thread From: Russ Allbery @ 1998-12-02 10:00 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > However, if someone (inadvertantly) mixed (*really* mixed) Chinese and > Scandianvian (for instance, talking about two people who's names contain > characters from two different charsets), then that might result in that > someone (inadvertantly) sending out a really long and winding MIME > message that might be annoying for the non-Gnus recipient to receive... > Of course, MML might just ask the user whether to go ahead and multipart > away or not... "Warning: Your message contains 37 parts. Do you really want to send?" User settable warning limit. That's what makes the most sense to me, just like the warnings about lines over 80 columns. (And as an aside, I am *really* impressed at the new MIME support. So impressed that this is literally converting me from a MIME-hater to rather liking it, if it can do stuff this cool when well-programmed. It makes me think that there really isn't anything that wrong with MIME, it's just that all the existing implementations suck. Except, finally, one.) -- Russ Allbery (rra@stanford.edu) <URL:http://www.eyrie.org/~eagle/> ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 10:00 ` Russ Allbery @ 1998-12-02 12:49 ` Kurt Swanson 1998-12-02 17:19 ` Automatic part insertion: åäö and ÔÄû " François Pinard ` (2 subsequent siblings) 3 siblings, 0 replies; 70+ messages in thread From: Kurt Swanson @ 1998-12-02 12:49 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1589 bytes --] Russ Allbery <rra@stanford.edu> writes: > Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >> However, if someone (inadvertantly) mixed (*really* mixed) Chinese and >> Scandianvian (for instance, talking about two people who's names contain >> characters from two different charsets), then that might result in that >> someone (inadvertantly) sending out a really long and winding MIME >> message that might be annoying for the non-Gnus recipient to receive... >> Of course, MML might just ask the user whether to go ahead and multipart >> away or not... > "Warning: Your message contains 37 parts. Do you really want to send?" > User settable warning limit. That's what makes the most sense to me, just > like the warnings about lines over 80 columns. That sounds like the best solution - allows for experts to pass through, warns dummies, and (probably) easily incorporates into the existing structure of controls on message sending. > (And as an aside, I am *really* impressed at the new MIME support. So > impressed that this is literally converting me from a MIME-hater to rather > liking it, if it can do stuff this cool when well-programmed. It makes me > think that there really isn't anything that wrong with MIME, it's just > that all the existing implementations suck. Except, finally, one.) Hear, hear! I've even stopped saying "quoted-unreadable" and "mime-encrypted". Gnus is already, in my experience, the best the extensible, customizable, self-documenting real-time display mail/news-reader supporting mime. -- © 1998 Kurt Swanson AB (ksw@dna.lth.se) . ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and ÔÄû on the same line 1998-12-02 10:00 ` Russ Allbery 1998-12-02 12:49 ` Kurt Swanson @ 1998-12-02 17:19 ` François Pinard 1998-12-02 17:30 ` Hrvoje Niksic 1998-12-02 18:02 ` Automatic part insertion: åäö and 吃哪塞 " Lars Magne Ingebrigtsen 1998-12-02 19:32 ` Lars Magne Ingebrigtsen 3 siblings, 1 reply; 70+ messages in thread From: François Pinard @ 1998-12-02 17:19 UTC (permalink / raw) Cc: ding Russ Allbery <rra@stanford.edu> writes: > It makes me think that there really isn't anything that wrong with MIME, > it's just that [almost] all the existing implementations suck. Exactly my impression, too. For years, I had the impression that the worst enemies of MIME are those implementing it. :-) I'm not really a MIME lover, I find it a bit oldish already, and there are limitations to it. However, I think MIME addresses real problems, and it is nearly the only solution at hand that has a some chance to become widely accepted. It is taking really many long years to get there. I hardly imagine all the time it will take for some next better step! :-) -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and ÔÄû on the same line 1998-12-02 17:19 ` Automatic part insertion: åäö and ÔÄû " François Pinard @ 1998-12-02 17:30 ` Hrvoje Niksic 1998-12-02 17:55 ` Richard Coleman 0 siblings, 1 reply; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-02 17:30 UTC (permalink / raw) François Pinard <pinard@IRO.UMontreal.CA> writes: > I'm not really a MIME lover, I find it a bit oldish already, and > there are limitations to it. Yup. I wish there were a clean way to say that a MIME part is gzipped, a la HTTP's `Content-Transfer' or `Content-Encoding'. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and ÔÄû on the same line 1998-12-02 17:30 ` Hrvoje Niksic @ 1998-12-02 17:55 ` Richard Coleman 1998-12-03 8:53 ` Automatic part insertion: åao and ÔAû " Jari Aalto+list.ding 0 siblings, 1 reply; 70+ messages in thread From: Richard Coleman @ 1998-12-02 17:55 UTC (permalink / raw) > > I'm not really a MIME lover, I find it a bit oldish already, and > > there are limitations to it. > > Yup. I wish there were a clean way to say that a MIME part is > gzipped, a la HTTP's `Content-Transfer' or `Content-Encoding'. This has been discussed many times on comp.mail.mime. There have been several proposals made, but there is little chance that something like this will be adopted soon, since: 1. At this point, it would be virtually impossible to add another Content-Transfer-Encoding type. It would break too many existing readers. 2. Most MIME types that are very large (image/jpeg, video/mpeg, etc., already have their own internal compression). -- Richard Coleman coleman@math.gatech.edu ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åao and ÔAû on the same line 1998-12-02 17:55 ` Richard Coleman @ 1998-12-03 8:53 ` Jari Aalto+list.ding 0 siblings, 0 replies; 70+ messages in thread From: Jari Aalto+list.ding @ 1998-12-03 8:53 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 698 bytes --] |Wed 1998-12-02 Richard Coleman <coleman@math.gatech.edu> list.ding | > > I'm not really a MIME lover, I find it a bit oldish already, and | > > there are limitations to it. | > | > Yup. I wish there were a clean way to say that a MIME part is | > gzipped, a la HTTP's `Content-Transfer' or `Content-Encoding'. | | This has been discussed many times on comp.mail.mime. There have been | several proposals made, but there is little chance that something like | this will be adopted soon, since: | | 1. At this point, it would be virtually impossible to add another | Content-Transfer-Encoding type. It would break too many | existing readers. Hm. Tm used x-gzip like this: jari [-- Attachment #2: T.gz --] [-- Type: application/octet-stream, Size: 6 bytes --] 1 2 3 ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 10:00 ` Russ Allbery 1998-12-02 12:49 ` Kurt Swanson 1998-12-02 17:19 ` Automatic part insertion: åäö and ÔÄû " François Pinard @ 1998-12-02 18:02 ` Lars Magne Ingebrigtsen 1998-12-02 19:32 ` Lars Magne Ingebrigtsen 3 siblings, 0 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 18:02 UTC (permalink / raw) ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 10:00 ` Russ Allbery ` (2 preceding siblings ...) 1998-12-02 18:02 ` Automatic part insertion: åäö and 吃哪塞 " Lars Magne Ingebrigtsen @ 1998-12-02 19:32 ` Lars Magne Ingebrigtsen 3 siblings, 0 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 19:32 UTC (permalink / raw) Russ Allbery <rra@stanford.edu> writes: > "Warning: Your message contains 37 parts. Do you really want to send?" I've added this, but only when the user hasn't typed any <#part> thingies. So no multiparts should happen without anyone being notified, but the multipartedness of the thing might be more impressive than anticipated. > (And as an aside, I am *really* impressed at the new MIME support. So > impressed that this is literally converting me from a MIME-hater to rather > liking it, if it can do stuff this cool when well-programmed. It makes me > think that there really isn't anything that wrong with MIME, it's just > that all the existing implementations suck. Except, finally, one.) It's easy to become giddy with the possibilities new, er, stuff presents one with. I can imagine Netscape programmers enthusing about <BLINK>: "Hey! We can blink now! Neat! Blink!" But I must say that I'm enjoying MIME much more than I thought I would be. It's not pretty or elegant, but it works, and is flexible and extensible. And one can implement interfaces that makes the whole thing, like, go away, and just leave is with purty images and purty characters from different countries and stuff. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen 1998-12-02 10:00 ` Russ Allbery @ 1998-12-02 10:27 ` Matt Armstrong 1998-12-02 18:03 ` Lars Magne Ingebrigtsen 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1998-12-02 16:59 ` Hrvoje Niksic 1998-12-02 22:19 ` Karl Kleinpaste 3 siblings, 2 replies; 70+ messages in thread From: Matt Armstrong @ 1998-12-02 10:27 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Wow! I'm impressed bu Gnus' handling of this -- it was rendered > perfectly, without a slightest hint that there was anything MIMEish > about the message. The Scandinavian and Chinese characters on the > same line in the body and everything. *gloat* :-) > > Could someone take a quick peek at the message from Kurt in a non-Gnus > MIME-aware reader and see what it does when presented with a message > that contains only text/plain parts, but with different charsets? Netscape splits them up into different parts with an HTML-like <hr> line between them. -- matta ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 10:27 ` Matt Armstrong @ 1998-12-02 18:03 ` Lars Magne Ingebrigtsen 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 18:03 UTC (permalink / raw) ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 10:27 ` Matt Armstrong 1998-12-02 18:03 ` Lars Magne Ingebrigtsen @ 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1998-12-02 20:39 ` Simon Josefsson 1 sibling, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 19:12 UTC (permalink / raw) (Sorry about the previous, empty message.) Matt Armstrong <mattdav+matt@best.com> writes: > > Could someone take a quick peek at the message from Kurt in a non-Gnus > > MIME-aware reader and see what it does when presented with a message > > that contains only text/plain parts, but with different charsets? > > Netscape splits them up into different parts with an HTML-like <hr> > line between them. Ick. Did the different charsets display OK, though? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 19:12 ` Lars Magne Ingebrigtsen @ 1998-12-02 20:39 ` Simon Josefsson [not found] ` <6fyaopd2dz.fsf@dna.lth.se> 0 siblings, 1 reply; 70+ messages in thread From: Simon Josefsson @ 1998-12-02 20:39 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > > Netscape splits them up into different parts with an HTML-like <hr> > > line between them. > > Ick. Did the different charsets display OK, though? Not for me. I can't get my netscape to react on charset's in the article at all -- it always displays everything with the default character set. If I change the default character set to japanese, I get japanse signs in Kurt's article. That's horrible. If I select GB2312 as my default encoding I get the same behaviour as iso-8859-1 in my netscape, so I guess it's less than optimal. A picture at <URL:http://www.pdc.kth.se/~jas/netscape.png>. (Netscape 4.5. Against a IMAP server which provides correct MIME information on the article parts.) ^ permalink raw reply [flat|nested] 70+ messages in thread
[parent not found: <6fyaopd2dz.fsf@dna.lth.se>]
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line [not found] ` <6fyaopd2dz.fsf@dna.lth.se> @ 1998-12-03 18:39 ` Simon Josefsson 0 siblings, 0 replies; 70+ messages in thread From: Simon Josefsson @ 1998-12-03 18:39 UTC (permalink / raw) Kurt Swanson <ksw@dna.lth.se> writes: > To get it to work in netscape you need to: ... > 7. Choose, View->Character Set->Simplified Chinese. This step should not be necessary and that's why I don't think netscape "works". The character set is indicated in the article, so why should I have to tell it manually? ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen 1998-12-02 10:00 ` Russ Allbery 1998-12-02 10:27 ` Matt Armstrong @ 1998-12-02 16:59 ` Hrvoje Niksic 1998-12-02 22:19 ` Karl Kleinpaste 3 siblings, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-02 16:59 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Wow! I'm impressed bu Gnus' handling of this -- it was rendered > perfectly, without a slightest hint that there was anything MIMEish > about the message. The Scandinavian and Chinese characters on the > same line in the body and everything. *gloat* :-) Gloat? Gloat?! Gnus gloriously mucks things up when replying to such messages! :-( When creating reply headers, one should probably simply copy the MIME stuff, or information tends to get lost. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Q: What's an IBM man-year? A: 730 people trying to get a project done before noon. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen ` (2 preceding siblings ...) 1998-12-02 16:59 ` Hrvoje Niksic @ 1998-12-02 22:19 ` Karl Kleinpaste 1998-12-02 22:40 ` Hrvoje Niksic ` (2 more replies) 3 siblings, 3 replies; 70+ messages in thread From: Karl Kleinpaste @ 1998-12-02 22:19 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Could someone take a quick peek at the message from Kurt in a non-Gnus > MIME-aware reader and see what it does when presented with a message > that contains only text/plain parts, but with different charsets? Outlook Express under Win98: http://www.cs.cmu.edu/~karl/pgnus/mime-test/chinese.gif Not pretty. Viewed as one main part + 2 ISOified text attachments. The subject has been font-recognized but abused into ISOness, too. While I'm here... I'm one of the benighted many who don't see any of this neat stuff, apparently. I'm using non-MULE XEmacs 20.4 -- could some kind soul give me a quick rundown of what would be required to be fully Gnus/MIME/fonts-capable? I run RH5.1 Linux (soon to be 5.2) with the usual bland XFree fonts installed; Do I need a different XEmacs? Is there a suitable source for all these fonts? I've heard of something called (I think) xfsft; do I need this, and where is it found? ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 22:19 ` Karl Kleinpaste @ 1998-12-02 22:40 ` Hrvoje Niksic 1998-12-02 23:07 ` Lars Magne Ingebrigtsen 1998-12-03 0:10 ` Kai.Grossjohann 2 siblings, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-02 22:40 UTC (permalink / raw) Karl Kleinpaste <karl@justresearch.com> writes: > While I'm here... I'm one of the benighted many who don't see any > of this neat stuff, apparently. I'm using non-MULE XEmacs 20.4 -- > could some kind soul give me a quick rundown of what would be > required to be fully Gnus/MIME/fonts-capable? I run RH5.1 Linux > (soon to be 5.2) with the usual bland XFree fonts installed; Do I > need a different XEmacs? For starters, you need to compile with Mule. I can't help you about the fonts. Good luck! -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- If we get involved in a nuclear war, will the electromagnetic pulses from exploding bombs damage my videotapes? ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 22:19 ` Karl Kleinpaste 1998-12-02 22:40 ` Hrvoje Niksic @ 1998-12-02 23:07 ` Lars Magne Ingebrigtsen 1999-02-13 2:17 ` Neil Crellin 1998-12-03 0:10 ` Kai.Grossjohann 2 siblings, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 23:07 UTC (permalink / raw) Karl Kleinpaste <karl@justresearch.com> writes: > Outlook Express under Win98: > http://www.cs.cmu.edu/~karl/pgnus/mime-test/chinese.gif > Not pretty. Viewed as one main part + 2 ISOified text attachments. > The subject has been font-recognized but abused into ISOness, too. Not very pretty; no. > While I'm here... I'm one of the benighted many who don't see any of > this neat stuff, apparently. I'm using non-MULE XEmacs 20.4 -- could > some kind soul give me a quick rundown of what would be required to be > fully Gnus/MIME/fonts-capable? You need an Emacs/XEmacs with Mule -- for instance, reconfigure xemacs 20.4 with --with-mule and recompile. Then you need the intlfonts package. It's 19Mb of all sorts of wunnerful fonts. You can get if from the XEmacs ftp site, or do an ftpsearch for intlfont.tar.gz (or something similar). After you have that, you just say "xset +fp /that/directory; xset +fp rehash" (or something to that effect). -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 23:07 ` Lars Magne Ingebrigtsen @ 1999-02-13 2:17 ` Neil Crellin 1999-02-13 6:00 ` Dmitry Yaitskov 1999-02-19 13:58 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 70+ messages in thread From: Neil Crellin @ 1999-02-13 2:17 UTC (permalink / raw) So I installed intlfonts, and turned off standard-display-european, and was very impressed with how well this worked. But for one thing. The summary buffer lines display the subject as: Automatic part insertion: \201å\201ä\201ö and \201Ô\201Ä\201û on the same line despite it appearing correctly in the subject and body in the article buffer. This is with pgnus 0.76. Am I expecting more than I should, or should it work in the summary buffer lines as well? ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1999-02-13 2:17 ` Neil Crellin @ 1999-02-13 6:00 ` Dmitry Yaitskov 1999-02-13 12:59 ` Kai.Grossjohann 1999-02-19 13:58 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 70+ messages in thread From: Dmitry Yaitskov @ 1999-02-13 6:00 UTC (permalink / raw) Neil Crellin <neilc@wallaby.cc> writes: > So I installed intlfonts, and turned off standard-display-european, <snip> Pardon my ignorance, what *is* intlfonts? -- Cheers, -Dima. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1999-02-13 6:00 ` Dmitry Yaitskov @ 1999-02-13 12:59 ` Kai.Grossjohann 0 siblings, 0 replies; 70+ messages in thread From: Kai.Grossjohann @ 1999-02-13 12:59 UTC (permalink / raw) Dmitry Yaitskov <dimas@home.com> writes: > Pardon my ignorance, what *is* intlfonts? GNU intlfonts is a package of X11 fonts for all kinds of languages. Get it from any ftp.gnu.org mirror. kai -- I like _\bb_\bo_\bt_\bh kinds of music. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1999-02-13 2:17 ` Neil Crellin 1999-02-13 6:00 ` Dmitry Yaitskov @ 1999-02-19 13:58 ` Lars Magne Ingebrigtsen 1999-02-19 17:04 ` Neil Crellin 1 sibling, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1999-02-19 13:58 UTC (permalink / raw) Neil Crellin <neilc@wallaby.cc> writes: > So I installed intlfonts, and turned off standard-display-european, > and was very impressed with how well this worked. But for one thing. > The summary buffer lines display the subject as: > > Automatic part insertion: \201å\201ä\201ö and \201Ô\201Ä\201û on the same line That's interesting; I haven't seen those in months, now. Do you start Emacs with --unibyte or fiddle with enable-multibyte-characters anywhere? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1999-02-19 13:58 ` Lars Magne Ingebrigtsen @ 1999-02-19 17:04 ` Neil Crellin 0 siblings, 0 replies; 70+ messages in thread From: Neil Crellin @ 1999-02-19 17:04 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Neil Crellin <neilc@wallaby.cc> writes: > > > So I installed intlfonts, and turned off standard-display-european, > > and was very impressed with how well this worked. But for one thing. > > The summary buffer lines display the subject as: > > > > Automatic part insertion: \201å\201ä\201ö and \201Ô\201Ä\201û on the same line > > That's interesting; I haven't seen those in months, now. > > Do you start Emacs with --unibyte or fiddle with > enable-multibyte-characters anywhere? Nope. Tracked it down tho. I had entered those entries into the cache, and the cache .overview hadn't been regenerated and was presenting old wierd crappy subject lines. Easily fixed. -Neil ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 22:19 ` Karl Kleinpaste 1998-12-02 22:40 ` Hrvoje Niksic 1998-12-02 23:07 ` Lars Magne Ingebrigtsen @ 1998-12-03 0:10 ` Kai.Grossjohann 1998-12-03 6:38 ` Graham Murray 2 siblings, 1 reply; 70+ messages in thread From: Kai.Grossjohann @ 1998-12-03 0:10 UTC (permalink / raw) Karl Kleinpaste <karl@justresearch.com> writes: > While I'm here... I'm one of the benighted many who don't see any of > this neat stuff, apparently. I'm using non-MULE XEmacs 20.4 -- could > some kind soul give me a quick rundown of what would be required to be > fully Gnus/MIME/fonts-capable? That's very simple. You get the GNU intlfonts package (warning, large), unpack it and install it using the script given. Suppose you install it into /opt/local/lib/X11/fonts/intlfonts. Then you need to say xset fp+ /opt/local/lib/X11/fonts/intlfonts Maybe +fp (prepend) rather than fp+ (append). That's it. You can also put the new directory in XF86config. kai -- This gubblick contains many nonsklarkish English flutzpahs, but the overall pluggandisp can be glorked from context. -- David Moser ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-03 0:10 ` Kai.Grossjohann @ 1998-12-03 6:38 ` Graham Murray 1998-12-03 10:46 ` Kai.Grossjohann 1998-12-03 11:50 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 70+ messages in thread From: Graham Murray @ 1998-12-03 6:38 UTC (permalink / raw) Kai.Grossjohann@CS.Uni-Dortmund.DE writes: > That's very simple. You get the GNU intlfonts package (warning, > large), unpack it and install it using the script given. Suppose you > install it into /opt/local/lib/X11/fonts/intlfonts. Then you need to > say Do you also have to set (or unset) a font in .emacs? I set an iso8859-1 font in default-frame-alist, so would this prevent emacs/gnus from choosing a font with the appropriate charset? ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-03 6:38 ` Graham Murray @ 1998-12-03 10:46 ` Kai.Grossjohann 1998-12-03 11:50 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 70+ messages in thread From: Kai.Grossjohann @ 1998-12-03 10:46 UTC (permalink / raw) Graham Murray <graham@barnowl.demon.co.uk> writes: > Do you also have to set (or unset) a font in .emacs? I set an > iso8859-1 font in default-frame-alist, so would this prevent > emacs/gnus from choosing a font with the appropriate charset? Dunno. I have the following in .Xdefaults ,----- | Emacs*font: KAIFONT `----- where KAIFONT is either one of the etl fonts or lucida sans typewriter. Chinese works automagically in both cases. I have no other Emacs font setup (well, there's the menu bar font but that doesn't matter does it). kai -- This gubblick contains many nonsklarkish English flutzpahs, but the overall pluggandisp can be glorked from context. -- David Moser ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-03 6:38 ` Graham Murray 1998-12-03 10:46 ` Kai.Grossjohann @ 1998-12-03 11:50 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-03 11:50 UTC (permalink / raw) Graham Murray <graham@barnowl.demon.co.uk> writes: > Do you also have to set (or unset) a font in .emacs? I set an > iso8859-1 font in default-frame-alist, so would this prevent > emacs/gnus from choosing a font with the appropriate charset? I don't think so. I've done no Emacs charset config thing, and things work. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line [not found] <6f67buzzff.fsf@dna.lth.se> 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen @ 1998-12-02 12:39 ` Vladimir Volovich 1998-12-02 17:38 ` Shenghuo ZHU ` (3 more replies) 1998-12-02 16:26 ` Michael Harnois 2 siblings, 4 replies; 70+ messages in thread From: Vladimir Volovich @ 1998-12-02 12:39 UTC (permalink / raw) "KS" == Kurt Swanson writes: KS> Automatic part insertion: Well, very nice. :-) I take my words back about automatical parts insertions, _provided_that_ there is an RFC which specifies that some part should be displayed as a continuation of the line of previous part (as gnus did when displaying your message). Is it really documented? If so, then all is fine. Also, gnus should prefer to not create `automagical' mime parts if it _can_ find a single charset for the whole part. For example, a message with mixed russian+japanese seems to fit into japanese mime encoding. So, even if i'm sending this from a cyrillic environment in Emacs, gnus should prefer to encode the part with the mixed text using single charset, if available. Thus, when Emacs will support unicode, gnus will send messages with mixed chinese+scandinavian text without breaking into parts. Best regards, -- Vladimir. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 12:39 ` Vladimir Volovich @ 1998-12-02 17:38 ` Shenghuo ZHU 1998-12-02 18:34 ` Vladimir Volovich 1998-12-02 17:50 ` Hrvoje Niksic ` (2 subsequent siblings) 3 siblings, 1 reply; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-02 17:38 UTC (permalink / raw) This sounds cool! >>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes: VVV> Well, very nice. :-) I take my words back about automatical parts VVV> insertions, _provided_that_ there is an RFC which specifies that VVV> some part should be displayed as a continuation of the line of VVV> previous part (as gnus did when displaying your message). Is it VVV> really documented? If so, then all is fine. Also, gnus should VVV> prefer to not create `automagical' mime parts if it _can_ find a VVV> single charset for the whole part. For example, a message with VVV> mixed russian+japanese seems to fit into japanese mime VVV> encoding. So, even if i'm sending this from a cyrillic VVV> environment in Emacs, gnus should prefer to encode the part with VVV> the mixed text using single charset, if available. Thus, when VVV> Emacs will support unicode, gnus will send messages with mixed VVV> chinese+scandinavian text without breaking into parts. Does mule use the same (mule) charset for Russian characters in cyrillic-iso-8bit and japanese-iso-8bit? Possible not. In Gnu Emacs 20.3, cyrillic-iso8859-5 is not safe in japanese-iso-8bit. So I guess, Gnu Emacs itself can not safely encode cyrillic-iso8859-5 characters with japanese. There is a unicode package. But it only support utf-8 in Gnu Emacs. -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 17:38 ` Shenghuo ZHU @ 1998-12-02 18:34 ` Vladimir Volovich 1998-12-02 18:59 ` Shenghuo ZHU 0 siblings, 1 reply; 70+ messages in thread From: Vladimir Volovich @ 1998-12-02 18:34 UTC (permalink / raw) "ZSH" == Shenghuo ZHU writes: ZSH> Does mule use the same (mule) charset for Russian characters in ZSH> cyrillic-iso-8bit and japanese-iso-8bit? Possible not. In Gnu ZSH> Emacs 20.3, cyrillic-iso8859-5 is not safe in ZSH> japanese-iso-8bit. So I guess, Gnu Emacs itself can not safely ZSH> encode cyrillic-iso8859-5 characters with japanese. Well, according to mm-mime-mule-charset-alist defined in mm-util.el, the iso-2022-int-1 charset supports both cyrillic-iso8859-5 and japanese-* charsets (and much more): (iso-2022-int-1 latin-iso8859-1 latin-iso8859-2 cyrillic-iso8859-5 greek-iso8859-7 latin-jisx0201 japanese-jisx0208-1978 chinese-gb2312 japanese-jisx0208 korean-ksc5601 japanese-jisx0212 chinese-cns11643-1 chinese-cns11643-2 chinese-cns11643-3 chinese-cns11643-4 chinese-cns11643-5 chinese-cns11643-6 chinese-cns11643-7)) So, if gnus finds that the part contains e.g. cyrillic-iso8859-5 and japanese-* charsets, it should send the whole part (without breaking it into `automagical' subparts), using the iso-2022-int-1 MIME charset. Best regards, -- Vladimir. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 18:34 ` Vladimir Volovich @ 1998-12-02 18:59 ` Shenghuo ZHU 1998-12-02 19:43 ` Lars Magne Ingebrigtsen 1998-12-02 21:19 ` Automatic part insertion: åäö and 吃哪塞 on the same line Vladimir Volovich 0 siblings, 2 replies; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-02 18:59 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="iso-2022-int-1", Size: 479 bytes --] >>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes: VVV> So, if gnus finds that the part contains e.g. cyrillic-iso8859-5 and VVV> japanese-* charsets, it should send the whole part (without breaking VVV> it into `automagical' subparts), using the iso-2022-int-1 MIME VVV> charset. You are right. This is not multipart mail and not automatically generated by gnus. ^[-A\x0eedv\x0f and ^[$(A3TDDH{^[(B on the same line But, do most mailers support iso-2022-int-1? -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 18:59 ` Shenghuo ZHU @ 1998-12-02 19:43 ` Lars Magne Ingebrigtsen 1998-12-02 23:34 ` Info on Internationalization Richard Coleman 1998-12-02 21:19 ` Automatic part insertion: åäö and 吃哪塞 on the same line Vladimir Volovich 1 sibling, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 19:43 UTC (permalink / raw) Shenghuo ZHU <zsh@cs.rochester.edu> writes: > But, do most mailers support iso-2022-int-1? Which reminds me -- does anyone have a reference to something (say, a web site or whatever) that has a good overview of charset issues? Things like this ("Is iso-2022-int-1 supported by anything but Emacs?") is something I wonder about from time to time... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-02 19:43 ` Lars Magne Ingebrigtsen @ 1998-12-02 23:34 ` Richard Coleman 1998-12-03 0:05 ` Lars Magne Ingebrigtsen 1998-12-03 0:06 ` Shenghuo ZHU 0 siblings, 2 replies; 70+ messages in thread From: Richard Coleman @ 1998-12-02 23:34 UTC (permalink / raw) > > But, do most mailers support iso-2022-int-1? > > Which reminds me -- does anyone have a reference to something (say, a > web site or whatever) that has a good overview of charset issues? > Things like this ("Is iso-2022-int-1 supported by anything but > Emacs?") is something I wonder about from time to time... I got the following information from the IMC mailing list several months ago. The IMC website is a good place to look for e-mail related info. IMC News New IMC Internationalization Report Available Many mail users need to send messages to people outside their own country, and mail user agents (MUAs) have to be able to send and receive messages in an interoperable fashion. To this end, the IMC has released its report on which standards MUAs should implement in order to be considered "internationalized". Internationalization is a complex and still-changing field, and IMC's report should help its members determine what steps they have to take in order to meet the needs of the widest variety of users. The report is available at <http://www.imc.org/mail-i18n.html> -- Richard Coleman coleman@math.gatech.edu ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-02 23:34 ` Info on Internationalization Richard Coleman @ 1998-12-03 0:05 ` Lars Magne Ingebrigtsen 1998-12-03 0:17 ` Shenghuo ZHU ` (2 more replies) 1998-12-03 0:06 ` Shenghuo ZHU 1 sibling, 3 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-03 0:05 UTC (permalink / raw) Richard Coleman <coleman@math.gatech.edu> writes: > The report is available at <http://www.imc.org/mail-i18n.html> Quite interesting. Summary of the document: UTF-8! UTF-8! UTF-8! So, is there any UTF-8 support on the horizon for the Emacsen? (I found the terminology in the document interesting, though -- they refer to UFT-8 as a "charset". Hee hee hee hee! Ok, they explain that it's really a CES (character encoding scheme), but it's a charset anyway. (Not a character set; that's different. A charset. :-) The document is clearly advocacy, though. They acknowledge that no clients have UTF-8 support, but they then go on to say things like this: ------ Recommendation: All mail-creating programs created or revised after January 1, 1999, must be able to create mail using the UTF-8 charset. Another way to say this is that any program created or revised after January 1, 1999, that cannot create mail using the UTF-8 charset should be considered deficient and lacking in standard internationalization capabilities. Of course, all mail-creating programs should try to meet this requirement as early as possible. ------ Lack *this*, IMC! :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 0:05 ` Lars Magne Ingebrigtsen @ 1998-12-03 0:17 ` Shenghuo ZHU 1998-12-03 11:39 ` Lars Magne Ingebrigtsen 1998-12-03 0:27 ` Richard Coleman 1998-12-06 14:11 ` François Pinard 2 siblings, 1 reply; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-03 0:17 UTC (permalink / raw) >>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: LMI> The document is clearly advocacy, though. They acknowledge that LMI> no clients have UTF-8 support, but they then go on to say things LMI> like this: At least, I got some utf-8 (even utf-7) messages. By install unicode.el in Emacs 20.3, I can read those messages in Gnus. -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 0:17 ` Shenghuo ZHU @ 1998-12-03 11:39 ` Lars Magne Ingebrigtsen 1998-12-03 16:49 ` Shenghuo ZHU 0 siblings, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-03 11:39 UTC (permalink / raw) Shenghuo ZHU <zsh@cs.rochester.edu> writes: > At least, I got some utf-8 (even utf-7) messages. Do you know which mail readers are able to send out utf-8 and utf-7? (I'm just curious.) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 11:39 ` Lars Magne Ingebrigtsen @ 1998-12-03 16:49 ` Shenghuo ZHU 0 siblings, 0 replies; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-03 16:49 UTC (permalink / raw) >>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: LMI> Do you know which mail readers are able to send out utf-8 and LMI> utf-7? (I'm just curious.) I don't know. (Those messages are expired.) -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 0:05 ` Lars Magne Ingebrigtsen 1998-12-03 0:17 ` Shenghuo ZHU @ 1998-12-03 0:27 ` Richard Coleman 1998-12-06 14:11 ` François Pinard 2 siblings, 0 replies; 70+ messages in thread From: Richard Coleman @ 1998-12-03 0:27 UTC (permalink / raw) > Richard Coleman <coleman@math.gatech.edu> writes: > > > The report is available at <http://www.imc.org/mail-i18n.html> > > The document is clearly advocacy, though. They acknowledge that no > clients have UTF-8 support, but they then go on to say things like > this: > > Recommendation: All mail-creating programs created or revised after > January 1, 1999, must be able to create mail using the UTF-8 > charset. Another way to say this is that any program created or > revised after January 1, 1999, that cannot create mail using the UTF-8 > charset should be considered deficient and lacking in standard > internationalization capabilities. Of course, all mail-creating > programs should try to meet this requirement as early as possible. The IMC recommendation to use UTF-8 is probably a good one. But their deadline of 1/1/99 is at least 5 years too early. The report suggests reading through the first few chapters of the Unicode Report. That might be a good idea. -- Richard Coleman coleman@math.gatech.edu ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 0:05 ` Lars Magne Ingebrigtsen 1998-12-03 0:17 ` Shenghuo ZHU 1998-12-03 0:27 ` Richard Coleman @ 1998-12-06 14:11 ` François Pinard 2 siblings, 0 replies; 70+ messages in thread From: François Pinard @ 1998-12-06 14:11 UTC (permalink / raw) Cc: ^[$(BH>ED^[(B ^[$(B7u0l^[(B Handa Kenichi [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2156 bytes --] Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > (I found the terminology in the document interesting, though -- they > refer to UFT-8 as a "charset". Hee hee hee hee! Ok, they explain > that it's really a CES (character encoding scheme), but it's a charset > anyway. (Not a character set; that's different. A charset. :-) I had a similar problem in `recode'. Users did convince me that since the UTF-8 encoding scheme is exclusively used with the UCS (Universal Character Set), it is kind of conceptual overkill to consider a double layer, and just simpler to take UTF-8 as a charset. This *is* abusive, of course, but I now think it is handy to accept it that way. Also, beware that all UCS related things (Unicode, ISO 10646, UCS-N and UTF-N) are a religious issue for many people. It relies to Han unification (for example, attributing a single code to similar Chinese and Japanese glyphs), to which many Japanese *strongly* object. So, any blind UTF-8! UTF-8! UTF-8! attitudes are prone to be very irritating to some people, and we should be careful about our own attitudes. Of course, UTF-8 has its own elegances and various technical merits, which surely appeal me a lot, but we should never loose sight and perspective that charsets (or encodings) are there to serve people, and not the other way around. We surely may discuss at length for Mule or against Mule, which currently ignores UCS (yet this is in the process of changing). The FSF choice favouring Mule was indeed taking a position within a religious fight about Han unification, and we know that the FSF likes politics :-). For the poor little me, Mule is not technically appealing (to put it very mildly!). However, there are two great qualities I recognise in Mule: the first is the incredible amount of knowledge and experience which has been melt within it (especially about input methods), the second is to bring a discording voice in our Americanized views, remembering us that we should not bulldoze people. -- François Pinard mailto:pinard@iro.umontreal.ca Join the free Translation Project! http://www.iro.umontreal.ca/~pinard ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-02 23:34 ` Info on Internationalization Richard Coleman 1998-12-03 0:05 ` Lars Magne Ingebrigtsen @ 1998-12-03 0:06 ` Shenghuo ZHU 1998-12-03 0:12 ` Hrvoje Niksic 1998-12-03 11:38 ` Lars Magne Ingebrigtsen 1 sibling, 2 replies; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-03 0:06 UTC (permalink / raw) >>>>> "RC" == Richard Coleman <coleman@math.gatech.edu> writes: RC> report is available at <http://www.imc.org/mail-i18n.html> I just found some recommendations in the page. Can Gnus do these? IMC> Sending UTF-8 IMC> All mail-creating programs created or revised after January 1, 1999, IMC> must be able to create mail using the UTF-8 charset. Another way to IMC> say this is that any program created or revised after January 1, 1999, IMC> that cannot create mail using the UTF-8 charset should be considered IMC> deficient and lacking in standard internationalization IMC> capabilities. Of course, all mail-creating programs should try to meet IMC> this requirement as early as possible. A deadline. I know a package for Emacs 20.x support UTF-8, which is decoding/encoding by an external program. Does XEmacs support UTF-8? IMC> Choosing charsets on creation IMC> All mail-creating programs that are controlled by humans should IMC> allow the sender to choose the charset used to create a message. IMC> These programs should also give advice to the user about the IMC> different charsets, such as about the likelihood that the IMC> recipient will be able to display a particular charset. Gnus does not allow user choose. IMC> Specifying languages IMC> All body parts that are created with a Content-type header that IMC> include human-readable text should also include a IMC> Content-language header. This practice makes it more likely that IMC> programs that process messages where different languages would IMC> process differently will process them correctly. Note that the IMC> MIME media type does not define whether or not the content is IMC> human-readable, and the Content-language header should be used IMC> with all types of human-readable content, not just plain text. Content-language, a header gnus should use. IMC> Multi-language text IMC> All plain text body parts that use UTF-8 and have more than one IMC> language should use Unicode Language Tags in addition to a IMC> Content-language header. However, Unicode Language Tags should IMC> only be used with plain text body parts that have more than one IMC> language; they should not be used with body parts that have a IMC> single language, nor should they be used with structured text IMC> body parts such as those coded with HTML. Although automagical additions of mime parts are cool, gnus should allow user choose UTF-8, if support it. IMC> Displaying UTF-8 IMC> All mail-displaying programs created or revised after January 1, IMC> 1999, must be able to display mail that uses the UTF-8 charset. IMC> Another way to say this is that any program created or revised IMC> after January 1, 1999, that cannot display mail using the UTF-8 IMC> charset should be considered deficient and lacking in standard IMC> internationalization capabilities. Of course, all mail-displaying IMC> programs should try to meet this requirement as early as IMC> possible. -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 0:06 ` Shenghuo ZHU @ 1998-12-03 0:12 ` Hrvoje Niksic 1998-12-03 11:38 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-03 0:12 UTC (permalink / raw) Shenghuo ZHU <zsh@cs.rochester.edu> writes: > A deadline. I know a package for Emacs 20.x support UTF-8, which is > decoding/encoding by an external program. Does XEmacs support UTF-8? I don't think so. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Personifiers Unite! You have nothing to lose but Mr. Dignity! ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 0:06 ` Shenghuo ZHU 1998-12-03 0:12 ` Hrvoje Niksic @ 1998-12-03 11:38 ` Lars Magne Ingebrigtsen 1998-12-03 13:18 ` Hrvoje Niksic 1998-12-03 16:38 ` Shenghuo ZHU 1 sibling, 2 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-03 11:38 UTC (permalink / raw) Shenghuo ZHU <zsh@cs.rochester.edu> writes: > I know a package for Emacs 20.x support UTF-8, which is > decoding/encoding by an external program. How is this done? What does the external program translate utf-8 into? > Content-language, a header gnus should use. Well -- do we really want to prompt the user for what language they are using? The information has its uses (for instance, emacspeak would know which language to speak in), but it's a rather marginally useful header, and inflicting this pain on a gazillion users is wrongheaded, in my opinion. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 11:38 ` Lars Magne Ingebrigtsen @ 1998-12-03 13:18 ` Hrvoje Niksic 1998-12-03 16:39 ` Shenghuo ZHU 1998-12-03 16:38 ` Shenghuo ZHU 1 sibling, 1 reply; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-03 13:18 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Shenghuo ZHU <zsh@cs.rochester.edu> writes: > > > I know a package for Emacs 20.x support UTF-8, which is > > decoding/encoding by an external program. > > How is this done? What does the external program translate utf-8 > into? Where can I find unicode.el? -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "Don't fight it son, confess quickly. If you hold out too long, you could jeopardize your credit rating." -- IR officer in _Brazil_ ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 13:18 ` Hrvoje Niksic @ 1998-12-03 16:39 ` Shenghuo ZHU 0 siblings, 0 replies; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-03 16:39 UTC (permalink / raw) >>>>> "HH" == Hrvoje Niksic <hniksic@srce.hr> writes: HH> Where can I find unicode.el? http://www.cs.ust.hk/~otfried/Mule/ -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 11:38 ` Lars Magne Ingebrigtsen 1998-12-03 13:18 ` Hrvoje Niksic @ 1998-12-03 16:38 ` Shenghuo ZHU 1998-12-04 1:15 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-03 16:38 UTC (permalink / raw) >>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: LMI> Shenghuo ZHU <zsh@cs.rochester.edu> writes: >> I know a package for Emacs 20.x support UTF-8, which is >> decoding/encoding by an external program. LMI> How is this done? What does the external program translate utf-8 LMI> into? External program read and write text in emacs-mule coding system. But XEmacs does not support emacs-mule. I am thinking about native elisp implementation. However, the convert table is a bit large. >> Content-language, a header gnus should use. LMI> Well -- do we really want to prompt the user for what language LMI> they are using? The information has its uses (for instance, LMI> emacspeak would know which language to speak in), but it's a LMI> rather marginally useful header, and inflicting this pain on a LMI> gazillion users is wrongheaded, in my opinion. How about using gnus-default-language or checking the charset the message uses? -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-03 16:38 ` Shenghuo ZHU @ 1998-12-04 1:15 ` Lars Magne Ingebrigtsen 1998-12-04 7:10 ` Shenghuo ZHU 0 siblings, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-04 1:15 UTC (permalink / raw) Shenghuo ZHU <zsh@cs.rochester.edu> writes: > External program read and write text in emacs-mule coding system. But > XEmacs does not support emacs-mule. What is the emacs-mule coding system, anyway? Is it just an, er, binary dump of the internal Emacs MULE representation or something? > I am thinking about native elisp implementation. However, the > convert table is a bit large. Hm. Well, if there is some program that translates utf-8 to MULE, then why doesn't Emacs include that code in Emacs proper? I am on the xemacs-mule@xemacs.org mailing list, which isn't very active, but has made many things about the XEmacs implementation clearer to me. Is there a mailing list used by the Emacs MULE people? > How about using gnus-default-language or checking the charset the > message uses? Well -- I'm a pretty typical European mail user, I think. I get mail in my native language and in English. What language I respond in depends mainly on what language people address me in. The character set I use for 99.3% of all my messages is iso-8859-1, no matter what language I respond in. (Although the English messages often are in ASCII, but so are some of the more terse Norwegian ones.) So, for me, I'd have to default to language "en", and correct that manually to "no" whenever I write Norwegian text. I see no real tangible benifits to this. As with the January 1st 1999 "deadline" for utf-8 support, I think the Content-Language thing is premature. Voice-speech mail readers (!) are still rare. The Content-Language header can wait until the computer is smart enough to figure out (through artificial stupidity) which language I'm typing, and by that time, the receiver can do the same, which makes the whole thing moot. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Info on Internationalization 1998-12-04 1:15 ` Lars Magne Ingebrigtsen @ 1998-12-04 7:10 ` Shenghuo ZHU 0 siblings, 0 replies; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-04 7:10 UTC (permalink / raw) >>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes: LMI> What is the emacs-mule coding system, anyway? Is it just an, er, LMI> binary dump of the internal Emacs MULE representation or LMI> something? When Emacs auto-saves a file, emacs-mule is coding-system-for-write. In XEmacs, escape-quoted is used. BTW, I found a message encoded in UTF-8 is sent by Microsoft Outlook Express 4.71.1712.3. I am not sure whether Outlook Express did it or other agent converted it. -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 18:59 ` Shenghuo ZHU 1998-12-02 19:43 ` Lars Magne Ingebrigtsen @ 1998-12-02 21:19 ` Vladimir Volovich 1998-12-02 21:37 ` Shenghuo ZHU 1 sibling, 1 reply; 70+ messages in thread From: Vladimir Volovich @ 1998-12-02 21:19 UTC (permalink / raw) "ZSH" == Shenghuo ZHU writes: ZSH> You are right. This is not multipart mail and not automatically ZSH> generated by gnus. But how did you manage to send it with pgnus, though? :-) I get the following error: Signaling: (error "Can't encode a part with several charsets. Insert a .") signal(error ("Can't encode a part with several charsets. Insert a .")) error("Can't encode a part with several charsets. Insert a .") mml-insert-mime-headers((part (type . "text/plain") (contents . #("Hi,\n\n\x8e5\x8e4\x8f6 and \x99d4\xa244\xa47b on the same line\n\n Best regards, -- Vladimir.\n" 0 5 ... 5 34 ... 34 63 ...))) "text/plain" (latin-iso8859-1 chinese-gb2312) 8bit) mml-generate-mime-1((part (type . "text/plain") (contents . #("Hi,\n\n\x8e5\x8e4\x8f6 and \x99d4\xa244\xa47b on the same line\n\n Best regards, -- Vladimir.\n" 0 5 ... 5 34 ... 34 63 ...)))) mml-generate-mime() message-encode-message-body() message-send-mail(nil) message-send-via-mail(nil) message-send(nil) message-send-and-exit(nil) * call-interactively(message-send-and-exit) Best regards, -- Vladimir. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 21:19 ` Automatic part insertion: åäö and 吃哪塞 on the same line Vladimir Volovich @ 1998-12-02 21:37 ` Shenghuo ZHU 1998-12-02 22:18 ` Vladimir Volovich 0 siblings, 1 reply; 70+ messages in thread From: Shenghuo ZHU @ 1998-12-02 21:37 UTC (permalink / raw) >>>>> "VVV" == Vladimir Volovich <vvv@vvv.vsu.ru> writes: VVV> "ZSH" == Shenghuo ZHU writes: ZSH> You are right. This is not multipart mail and not automatically ZSH> generated by gnus. VVV> But how did you manage to send it with pgnus, though? :-) I get the VVV> following error: I said it is "not automatically generated by gnus". -- Shenghuo ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 21:37 ` Shenghuo ZHU @ 1998-12-02 22:18 ` Vladimir Volovich 1998-12-02 23:29 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 70+ messages in thread From: Vladimir Volovich @ 1998-12-02 22:18 UTC (permalink / raw) "ZSH" == Shenghuo ZHU writes: ZSH> I said it is "not automatically generated by gnus". Ah, sorry. Then i consider it as a bug that gnus does not use mm-mime-mule-charset-alist to find a single charset for the MIME part. And: even with pgnus 0.61 (with automagical additions of mime parts), i was unable to send a message with the line which is in subject. i was only able to send a message when 8859-2 and chinese characters were on different lines. but again: gnus should use mm-mime-mule-charset-alist first of all, and try to find parts only if that test fails. if someone does not want to use iso-2022-int-1 for some combination of mule charsets, then simply define your own setting of mm-mime-mule-charset-alist. Best regards, -- Vladimir. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 22:18 ` Vladimir Volovich @ 1998-12-02 23:29 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 23:29 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 224 bytes --] Vladimir Volovich <vvv@vvv.vsu.ru> writes: > And: even with pgnus 0.61 (with automagical additions of mime parts), > i was unable to send a message with the line which is in subject. Hm. Automatic part insertion: åäö and [-- Attachment #2: Type: text/plain, Size: 207 bytes --] 吃哪塞 on the same line Er... Yes, it divided up the message buggily. Fix in Pterodactyl Gnus v0.62. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 12:39 ` Vladimir Volovich 1998-12-02 17:38 ` Shenghuo ZHU @ 1998-12-02 17:50 ` Hrvoje Niksic 1998-12-02 18:19 ` Lars Magne Ingebrigtsen 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 3 siblings, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-02 17:50 UTC (permalink / raw) Vladimir Volovich <vvv@vvv.vsu.ru> writes: > "KS" == Kurt Swanson writes: > > KS> Automatic part insertion: > > Well, very nice. :-) I take my words back about automatical parts > insertions, _provided_that_ there is an RFC which specifies that some > part should be displayed as a continuation of the line of previous > part (as gnus did when displaying your message). Is it really > documented? Well. RFC's don't normally specify message rendering. However, it *is* documented that the newline preceding the closing boundary is syntactically a part of the boundary. Quoth rfc2046: The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part. This implies that this: --boundary text --boundary-- means `text' without newline, while --boundary text --boundary-- means `text ', all with the newline. So what Gnus does is quite right. This also explains why many MIME composers insert seemingly redundant newlines before the closing boundaries. But then again, noone can guarantee anything about how others will display it. Netscape, for one, displays a horizontal ruler between the multiparts, and I can't find a good objection to that. > If so, then all is fine. Also, gnus should prefer to not create > `automagical' mime parts if it _can_ find a single charset for the > whole part. Agreed. Gnus should try not to use magic if it is at all possible. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- I'm a Lisp variable -- bind me! ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 12:39 ` Vladimir Volovich 1998-12-02 17:38 ` Shenghuo ZHU 1998-12-02 17:50 ` Hrvoje Niksic @ 1998-12-02 18:19 ` Lars Magne Ingebrigtsen 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 3 siblings, 0 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 18:19 UTC (permalink / raw) ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 12:39 ` Vladimir Volovich ` (2 preceding siblings ...) 1998-12-02 18:19 ` Lars Magne Ingebrigtsen @ 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1998-12-02 19:41 ` Vladimir Volovich 1998-12-02 21:33 ` Hrvoje Niksic 3 siblings, 2 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 19:12 UTC (permalink / raw) (Sorry about the previous, empty message.) Vladimir Volovich <vvv@vvv.vsu.ru> writes: > Well, very nice. :-) I take my words back about automatical parts > insertions, _provided_that_ there is an RFC which specifies that some > part should be displayed as a continuation of the line of previous > part (as gnus did when displaying your message). Quoth RFC2046: NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. > Also, gnus should prefer to not create `automagical' mime parts if > it _can_ find a single charset for the whole part. For example, a > message with mixed russian+japanese seems to fit into japanese mime > encoding. So, even if i'm sending this from a cyrillic environment > in Emacs, gnus should prefer to encode the part with the mixed text > using single charset, if available. Thus, when Emacs will support > unicode, gnus will send messages with mixed chinese+scandinavian > text without breaking into parts. I don't really know about this one. If I'm composing a message using Scandianvian and Sami characters (which would be iso-8859-1 and iso-8859-9 if I'm responsing to someone using iso-8859-9,) I want to respons using iso-8859-9 and iso-8859-1, not Unicode, no matter whether Emacs supports it or not. What's important is what the recipient supports, and one can't assume that the recipient supports these megacharsets. MIME is widely implemented, if (ahum) slightly shakily here and there. Unicode is not. So it's better to Mimetilate a message than to Unicodelate the messege. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 19:12 ` Lars Magne Ingebrigtsen @ 1998-12-02 19:41 ` Vladimir Volovich 1998-12-02 21:34 ` Hrvoje Niksic 1998-12-02 22:29 ` Lars Magne Ingebrigtsen 1998-12-02 21:33 ` Hrvoje Niksic 1 sibling, 2 replies; 70+ messages in thread From: Vladimir Volovich @ 1998-12-02 19:41 UTC (permalink / raw) "LMI" == Lars Magne Ingebrigtsen writes: LMI> Quoth RFC2046: thanks. gnus now supports empty lines in mime almost fine, but it seems to be a bit more `aggressive' in: * ignoring empty lines in MIME parts when displaying. e.g the message which started this thread contained in the last part: > --==-=-= > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > > > > Couldn't this be quickly scanned to have #part's automatically added? > I.e. one starts out with the group default coding and then goes i.e., as i understand, gnus should have leaved two empty lines before the last paragraph when displaying the message, but it showed only one empty line. * putting some extra empty lines in MIME when composing messages. E.g. if i create a text/plain us-ascii part, gnus puts two or three empty lines after part boundary, instead of just one. LMI> I don't really know about this one. If I'm composing a message LMI> using Scandianvian and Sami characters (which would be LMI> iso-8859-1 and iso-8859-9 if I'm responsing to someone using LMI> iso-8859-9,) I want to respons using iso-8859-9 and iso-8859-1, LMI> not Unicode, no matter whether Emacs supports it or not. What's LMI> important is what the recipient supports, and one can't assume LMI> that the recipient supports these megacharsets. LMI> MIME is widely implemented, if (ahum) slightly shakily here and LMI> there. Unicode is not. So it's better to Mimetilate a message LMI> than to Unicodelate the messege. Well, maybe, gnus should decide how to behave in these situations based on the mm-mime-mule-charset-alist? i.e., you can just remove unicode line from that list (if it were there), but someone else would want to leave it there? So, gnus should _first_ look in the mm-mime-mule-charset-alist, and try to encode the whole part with a single charset, and _if_ it could not find a single charset, only then it should try to insert automagical parts? Best regards, -- Vladimir. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 19:41 ` Vladimir Volovich @ 1998-12-02 21:34 ` Hrvoje Niksic 1998-12-02 22:29 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-02 21:34 UTC (permalink / raw) Vladimir Volovich <vvv@vvv.vsu.ru> writes: > > --==-=-= > > Content-Type: text/plain; charset=iso-8859-1 > > Content-Transfer-Encoding: 8bit > > > > > > > > Couldn't this be quickly scanned to have #part's automatically added? > > I.e. one starts out with the group default coding and then goes > > i.e., as i understand, gnus should have leaved two empty lines > before the last paragraph when displaying the message, but it showed > only one empty line. I agree. This looks like a bug. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A radioactive cat has eighteen half-lives. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 19:41 ` Vladimir Volovich 1998-12-02 21:34 ` Hrvoje Niksic @ 1998-12-02 22:29 ` Lars Magne Ingebrigtsen 1998-12-04 8:31 ` Vladimir Volovich 1 sibling, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-12-02 22:29 UTC (permalink / raw) Vladimir Volovich <vvv@vvv.vsu.ru> writes: > i.e., as i understand, gnus should have leaved two empty lines before > the last paragraph when displaying the message, but it showed only one > empty line. Yes, and that's correct, because the MIME looked like: on the same line --==-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Couldn't this be quickly scanned to have #part's automatically added? So the first newline belonged on the end of the line before the separator, and then the next one belonged to the final part. > Well, maybe, gnus should decide how to behave in these situations > based on the mm-mime-mule-charset-alist? i.e., you can just remove > unicode line from that list (if it were there), but someone else would > want to leave it there? So, gnus should _first_ look in the > mm-mime-mule-charset-alist, and try to encode the whole part with a > single charset, and _if_ it could not find a single charset, only then > it should try to insert automagical parts? I don't know. What to do by default depends on how widely implemented these other megacharsets are. I have no idea. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 22:29 ` Lars Magne Ingebrigtsen @ 1998-12-04 8:31 ` Vladimir Volovich 0 siblings, 0 replies; 70+ messages in thread From: Vladimir Volovich @ 1998-12-04 8:31 UTC (permalink / raw) "LMI" == Lars Magne Ingebrigtsen writes: LMI> So the first newline belonged on the end of the line before the LMI> separator, and then the next one belonged to the final part. Yup. sorry. Best regards, -- Vladimir. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1998-12-02 19:41 ` Vladimir Volovich @ 1998-12-02 21:33 ` Hrvoje Niksic 1 sibling, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-12-02 21:33 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Vladimir Volovich <vvv@vvv.vsu.ru> writes: > > > Well, very nice. :-) I take my words back about automatical parts > > insertions, _provided_that_ there is an RFC which specifies that some > > part should be displayed as a continuation of the line of previous > > part (as gnus did when displaying your message). > > Quoth RFC2046: > > NOTE: The CRLF preceding the boundary delimiter line is conceptually > attached to the boundary so that it is possible to have a part that > does not end with a CRLF (line break). Body parts that must be > considered to end with line breaks, therefore, must have two CRLFs > preceding the boundary delimiter line, the first of which is part of > the preceding body part, and the second of which is part of the > encapsulation boundary. Note, however, that this says nothing about actually *displaying* multiparts. Netscape's horizontal ruler is not prohibited by this. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- The Lord protects children and fools... But don't push it. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line [not found] <6f67buzzff.fsf@dna.lth.se> 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen 1998-12-02 12:39 ` Vladimir Volovich @ 1998-12-02 16:26 ` Michael Harnois 1998-12-02 17:02 ` Michael Harnois 2 siblings, 1 reply; 70+ messages in thread From: Michael Harnois @ 1998-12-02 16:26 UTC (permalink / raw) Did I miss a patch somewhere? When I try to open Kurt's message, I get Signaling: (wrong-type-argument char-or-string-p nil) mm-inline-text((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil)) mm-display-inline((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil)) mm-display-part((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil) t) byte-code("..." [ignored string-match type throw nil mm-automatic-display-p mm-inlinable-part-p 4 handle "inline" not-attachment t display split-string "/" "text" text gnus-article-mime-handle-alist id gnus-unbuttonized-mime-type-p gnus-article-insert-newline gnus-insert-mime-button move -2 gnus-newsgroup-default-charset gnus-newsgroup-iso-8859-1-forced mm-charset-iso-8859-1-forced rfc2047-default-charset mm-display-part mm-insert-inline mm-get-part] 5) gnus-mime-display-single((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil)) gnus-mime-display-part((#<buffer " *mm*"> ("text/plain" (charset . "iso-8859-1")) 8bit nil nil nil nil)) mapcar(gnus-mime-display-part ((#<buffer " *mm*"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<2>"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<3>"> ("text/plain" ...) 8bit nil nil nil nil))) gnus-mime-display-mixed(((#<buffer " *mm*"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<2>"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<3>"> ("text/plain" ...) 8bit nil nil nil nil))) gnus-mime-display-part(("multipart/mixed" (#<buffer " *mm*"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<2>"> ("text/plain" ...) 8bit nil nil nil nil) (#<buffer " *mm*<3>"> ("text/plain" ...) 8bit nil nil nil nil))) gnus-display-mime() gnus-article-prepare-display() gnus-article-prepare(3464 nil) gnus-summary-display-article(3464 nil) gnus-summary-select-article(nil nil pseudo) gnus-summary-scroll-up(1) call-interactively(gnus-summary-scroll-up) -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org Censorship is the strongest drive in human nature; sex is a weak second. -- Phil Kerby ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Automatic part insertion: åäö and 吃哪塞 on the same line 1998-12-02 16:26 ` Michael Harnois @ 1998-12-02 17:02 ` Michael Harnois 0 siblings, 0 replies; 70+ messages in thread From: Michael Harnois @ 1998-12-02 17:02 UTC (permalink / raw) Brain fart. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois@willinet.net aa0bt@aa0bt.ampr.org Censorship is the strongest drive in human nature; sex is a weak second. -- Phil Kerby ^ permalink raw reply [flat|nested] 70+ messages in thread
* Scriptin' MIME @ 1998-11-14 15:30 Lars Magne Ingebrigtsen 1998-11-14 18:07 ` Bruce Stephens 1998-11-14 18:29 ` Andi Kleen 0 siblings, 2 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-11-14 15:30 UTC (permalink / raw) One thing that occurred to me while I was waking up just now was that it might be neat to have a TeXinfo-like MIME interface. Like: @alternative @part{text/plain} This is plain text. @part{text/enriched} @charset{iso-8859-1} This ïs <b>enriched</b>. @part{image/gif} @external{~/rms.gif} @end{alternative} And so on. Commands for all the things one wants. A MIME composition language. Of course, one could add a gazillion MIME composition commands so that people doesn't have to write stuff like that unless they really want to. The most common command would be @externalpart{image/gif}{~/rms.gif} (Er. Or something.) which isn't really more intrusive than the current buttoney approach. Now, I really like TeXinfo, but I realise that some weird people might not, so I don't know whether this really is a good idea or not. And besides, I haven't really woken up properly yet. -- (domestic pets only, the antidote for overdose, milk.) larsi@ifi.uio.no * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 15:30 Scriptin' MIME Lars Magne Ingebrigtsen @ 1998-11-14 18:07 ` Bruce Stephens 1998-11-14 18:27 ` Lars Magne Ingebrigtsen 1998-11-14 19:55 ` Hrvoje Niksic 1998-11-14 18:29 ` Andi Kleen 1 sibling, 2 replies; 70+ messages in thread From: Bruce Stephens @ 1998-11-14 18:07 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: > One thing that occurred to me while I was waking up just now was that > it might be neat to have a TeXinfo-like MIME interface. Like: > > @alternative > @part{text/plain} > This is plain text. > @part{text/enriched} > @charset{iso-8859-1} > This ïs <b>enriched</b>. > @part{image/gif} > @external{~/rms.gif} > @end{alternative} > > And so on. Commands for all the things one wants. A MIME composition > language. Which is basically what elm does. Or did. I haven't used it for a while. MH/nmh also provide something like this. Perhaps it would be good to use the same syntax, or something? Having a scriptable interface is convenient for some applications. For example, at work we send change requests and patches around to each other, packaging them in MIME. For reading it, we use a MUA, but it's handy to use a script to send them, since the script knows where to find the change requests and how to produce the patches. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 18:07 ` Bruce Stephens @ 1998-11-14 18:27 ` Lars Magne Ingebrigtsen 1998-11-14 18:38 ` Bruce Stephens 1998-11-14 20:48 ` Richard Coleman 1998-11-14 19:55 ` Hrvoje Niksic 1 sibling, 2 replies; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-11-14 18:27 UTC (permalink / raw) Bruce Stephens <bruce@cenderis.demon.co.uk> writes: > Which is basically what elm does. Or did. I haven't used it for a > while. MH/nmh also provide something like this. Perhaps it would be > good to use the same syntax, or something? Could someone who has used elm or MH give a description of their MIME composition interfaces? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 18:27 ` Lars Magne Ingebrigtsen @ 1998-11-14 18:38 ` Bruce Stephens 1998-11-14 20:48 ` Richard Coleman 1 sibling, 0 replies; 70+ messages in thread From: Bruce Stephens @ 1998-11-14 18:38 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Could someone who has used elm or MH give a description of their MIME > composition interfaces? When I used it (which was years ago), elm's was pretty minimal. When you composed a message, you could insert magic lines: [import rms.png image/x-png] Something like that, anyway. I forget the exact syntax. It was pretty basic anyway, and not at all what we expect from Gnus. Someone's already sent an example of MH's syntax. exmh (a Tcl/Tk interface onto mh) does its own MIME stuff, but it's also pretty basic: adding new sections is easy, but editing is next to impossible. MH's interface is also available, however. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 18:27 ` Lars Magne Ingebrigtsen 1998-11-14 18:38 ` Bruce Stephens @ 1998-11-14 20:48 ` Richard Coleman 1 sibling, 0 replies; 70+ messages in thread From: Richard Coleman @ 1998-11-14 20:48 UTC (permalink / raw) > > Which is basically what elm does. Or did. I haven't used it for a > > while. MH/nmh also provide something like this. Perhaps it would be > > good to use the same syntax, or something? > > Could someone who has used elm or MH give a description of their MIME > composition interfaces? I'm the author of nmh. The translation of MIME composition drafts is done with a command called mhbuild. Here is the man page for it, which explains the syntax. But I wouldn't necessarily recommend that you do it this way. The MH code base is pretty old. I expect I would do many things differently, if I was writing this from scratch. But it does allow the creating of fairly complicated MIME messages. Richard Coleman (author, nmh) coleman@math.gatech.edu NAME mhbuild - translate MIME composition draft SYNOPSIS mhbuild file [-list] [-nolist] [-realsize] [-norealsize] [-headers] [-noheaders] [-ebcdicsafe] [-noebcdicsafe] [-rfc934mode] [-norfc934mode] [-verbose] [-noverbose] [-check] [-nocheck] [-version] [-help] DESCRIPTION The mhbuild command will translate a MIME compostion draft into a valid MIME message. mhbuild creates multi-media messages as specified in RFC-2045 thru RFC-2049. Currently mhbuild only supports encodings in message bodies, and does not support the encoding of message headers as specified in RFC-2047. If you specify the name of the composition file as "-", then mhbuild will accept the composition draft on the standard input. If the translation of this input is suc- cessful, mhbuild will output the new MIME message to the standard output. This argument must be the last argument on the command line. Otherwise if the file argument to mhbuild is the name of a valid composition file, and the translation is successful, mhbuild will replace the orginal file with the new MIME message. It will rename the original file to start with the "," character and end with the string ".orig", e.g., if you are editing the file "draft", it will be renamed to ",draft.orig". This allows you to easily recover the mhbuild input file. Listing the Contents The `-list' switch tells mhbuild to list the table of con- tents associated with the MIME message that is created. The `-headers' switch indicates that a one-line banner should be displayed above the listing. The `-realsize' switch tells mhbuild to evaluate the "native" (decoded) format of each content prior to listing. This provides an accurate count at the expense of a small delay. If the `-verbose' switch is present, then the listing will show any "extra" information that is present in the message, such as comments in the Content-Type header. Translating the Composition File mhbuild is essentially a filter to aid in the composition of MIME messages. mhbuild will convert an mhbuild "compo- sition file" into a valid MIME message. A mhbuild "composition file" is just a file containing plain text that is interspersed with various mhbuild directives. When this file is processed by mhbuild, the various direc- tives will be expanded to the appropriate content, and will be encoded according to the MIME standards. The resulting MIME message can then be sent by electronic mail. The formal syntax for a mhbuild composition file is defined at the end of this document, but the ideas behind this format are not complex. Basically, the body contains one or more contents. A content consists of either a directive, indicated with a "#" as the first character of a line; or, plaintext (one or more lines of text). The continuation character, "\", may be used to enter a single directive on more than one line, e.g., #image/png \ /home/foobar/junk/picture.png There are four kinds of directives: "type" directives, which name the type and subtype of the content; "external- type" directives, which also name the type and subtype of the content; the "message" directive (#forw), which is used to forward one or more messages; and, the "begin" directive (#begin), which is used to create a multipart content. The "type" directive is used to directly specify the type and subtype of a content. You may only specify discrete types in this manner (can't specify the types multipart or message with this directive). You may optionally specify the name of a file containing the contents in "native" (decoded) format. If this filename starts with the "|" character, then it represents a command to execute whose output is captured accordingly. For example, #audio/basic |raw2audio -F < /usr/lib/sound/giggle.au If a filename is not given, mhbuild will look for informa- tion in the user's profile to determine how the different contents should be composed. This is accomplished by con- sulting a composition string, and executing it under /bin/sh, with the standard output set to the content. If the `-verbose' switch is given, mhbuild will echo any com- mands that are used to create contents in this way. The composition string may contain the following escapes: %a Insert parameters from directive %f Insert filename containing content %F %f, and stdout is not re-directed %s Insert content subtype %% Insert character % First, mhbuild will look for an entry of the form: mhbuild-compose-<type>/<subtype> to determine the command to use to compose the content. If this isn't found, mhbuild will look for an entry of the form: mhbuild-compose-<type> to determine the composition command. If this isn't found, mhbuild will complain. An example entry might be: mhbuild-compose-audio/basic: record | raw2audio -F Because commands like these will vary, depending on the display environment used for login, composition strings for different contents should probably be put in the file specified by the $MHBUILD environment variable, instead of directly in your user profile. The "external-type" directives are used to provide a MIME reference to a content, rather than enclosing the contents itself (for instance, by specifying an ftp site). Hence, instead of providing a filename as with the type direc- tives, external-parameters are supplied. These look like regular parameters, so they must be separated accordingly. For example, #@application/octet-stream; \ type=tar; \ conversions=compress \ [this is the nmh distribution] \ name="nmh.tar.gz"; \ directory="/pub/nmh"; \ site="ftp.math.gatech.edu"; \ access-type=anon-ftp; \ mode="image" You must give a description string to separate the content parameters from the external-parameters (although this string may be empty). This description string is speci- fied by enclosing it within "[]". These parameters are of the form: access-type= usually anon-ftp or mail-server name= filename permission= read-only or read-write site= hostname directory= directoryname (optional) mode= usually ascii or image (optional) size= number of octets server= mailbox subject= subject to send body= command to send for retrieval The "message" directive (#forw) is used to specify a mes- sage or group of messages to include. You may optionally specify the name of the folder and which messages are to be forwarded. If a folder is not given, it defaults to the current folder. Similarly, if a message is not given, it defaults to the current message. Hence, the message directive is similar to the forw (1) command, except that the former uses the MIME rules for encapsulation rather than those specified in RFC-934. For example, #forw +inbox 42 43 99 If you include a single message, it will be included directly as a content of type "message/rfc822". If you include more than one message, then mhbuild will add a content of type "multipart/digest" and include each mes- sage as a subpart of this content. If you are using this directive to include more than one message, you may use the `-rfc934mode' switch. This switch will indicate that mhbuild should attempt to uti- lize the MIME encapsulation rules in such a way that the "multipart/digest" that is created is (mostly) compatible with the encapsulation specified in RFC-934. If given, then RFC-934 compliant user-agents should be able to burst the message on reception -- providing that the messages being encapsulated do not contain encapsulated messages themselves. The drawback of this approach is that the encapsulations are generated by placing an extra newline at the end of the body of each message. The "begin" directive is used to create a multipart con- tent. When using the "begin" directive, you must specify at least one content between the begin and end pairs. #begin This will be a multipart with only one part. #end If you use multiple directives in a composition draft, mhbuild will automatically encapsulate them inside a mul- tipart content. Therefore the "begin" directive is only necessary if you wish to use nested multiparts, or create a multipart message containing only one part. For all of these directives, the user may include a brief description of the content between the "[" character and the "]" character. This description will be copied into the "Content-Desciption" header when the directive is pro- cessed. #forw [important mail from Bob] +bob 1 2 3 4 5 By default, mhbuild will generate a unique "Content-ID:" for each directive; however, the user may override this by defining the ID using the "<" and ">" characters. In addition to the various directives, plaintext can be present. Plaintext is gathered, until a directive is found or the draft is exhausted, and this is made to form a text content. If the plaintext must contain a "#" at the beginning of a line, simply double it, e.g., ##when sent, this line will start with only one # If you want to end the plaintext prior to a directive, e.g., to have two plaintext contents adjacent, simply insert a line containing a single "#" character, e.g., this is the first content # and this is the second Finally, if the plaintext starts with a line of the form: Content-Description: text then this will be used to describe the plaintext content. You MUST follow this line with a blank line before start- ing your text. By default, plaintext is captured as a text/plain content. You can override this by starting the plaintext with "#<" followed by a content-type specification. For example, e.g., #<text/enriched this content will be tagged as text/enriched # and this content will be tagged as text/plain # #<application/x-patch [this is a patch] and this content will be tagged as application/x-patch Note that if you use the "#<" plaintext-form, then the content-description must be on the same line which identi- fies the content type of the plaintext. When composing a text content, you may indicate the rele- vant character set by adding the "charset" parameter to the directive. #<text/plain; charset=iso-8859-5 If a text content contains any 8bit characters (characters with the high bit set) and the character set is not speci- fied as above, then mhbuild will assume the character set is of the type given by the environment variable MM_CHARSET. If this environment variable is not set, then the character set will be labeled as "x-unknown". If a text content contains only 7bit characters and the character set is not specified as above, then the charac- ter set will be labeled as "us-ascii" Putting this all together, here is an example of a more complicated message draft. The following draft will expand into a multipart/mixed message containing five parts: To: nobody@nowhere.org cc: Subject: Look and listen to me! -------- The first part will be text/plain #<text/enriched The second part will be text/enriched # This third part will be text/plain #audio/basic [silly giggle] \ |raw2audio -F < /usr/lib/sounds/giggle.au #image/gif [photo of foobar] \ /home/foobar/lib/picture.gif Integrity Check If mhbuild is given the `-check' switch, then it will also associate an integrity check with each "leaf" content. This will add a Content-MD5 header field to the content, along with the md5 sum of the unencoded contents. This may be used by the receiver of the message to verify that the contents of the message were not changed in transport. Transfer Encodings After mhbuild constructs the new MIME message by parsing directives, including files, etc., it scans the contents of the message to determine which transfer encoding to use. It will check for 8bit data, long lines, spaces at the end of lines, and clashes with multipart boundaries. It will then choose a transfer encoding appropriate for each content type. If an integrity check is being associated with each con- tent by using the `-check' switch, then mhbuild will encode each content with a transfer encoding, even it the content contains only 7bit data. This is to increase the likelihood that the content is not changed while in trans- port. The switch `-ebcdicsafe' will cause mhbuild to slightly change the way in which it performs the "quoted-printable" transfer encoding. Along with encoding 8bit characters, it will now also encode certain common punctuation charac- ters as well. This slightly reduces the readability of the message, but allows the message to pass more reliably through mail gateways which involve the EBCDIC character encoding. Invoking mhbuild Typically, mhbuild is invoked by the whatnow program. This command will expect the body of the draft to be for- matted as an mhbuild composition file. Once you have com- posed this input file using a command such as comp, repl, or forw, you invoke mhbuild at the "What now" prompt with What now? mime prior to sending the draft. This will cause whatnow to execute mhbuild to translate the composition file into MIME format. It is also possible to have the whatnow program invoke mhbuild automatically when a message is sent. To do this, you must add the line automimeproc: 1 to your .mh_profile file. Finally, you should consider adding this line to your pro- file: lproc: show This way, if you decide to list after invoking mime, the command What now? list will work as you expect. User Environment Because the environment in which mhbuild operates may vary for a user, mhbuild will look for the environment variable $MHBUILD. If present, this specifies the name of an addi- tional user profile which should be read. Hence, when a user logs in on a particular machine, this environment variable should be set to refer to a file containing defi- nitions useful for that machine. Finally, mhbuild will attempt to consult a global mhbuild user profile, e.g., /home/rcoleman/nmh-bin/etc/mhn.defaults if it exists. Syntax of Composition Files The following is the formal syntax of a mhbuild "composi- tion file". body ::= 1*(content | EOL) content ::= directive | plaintext directive ::= "#" type "/" subtype 0*(";" attribute "=" value) [ "(" comment ")" ] [ "<" id ">" ] [ "[" description "]" ] [ filename ] EOL | "#@" type "/" subtype 0*(";" attribute "=" value) [ "(" comment ")" ] [ "<" id ">" ] [ "[" description "]" ] external-parameters EOL | "#forw" [ "<" id ">" ] [ "[" description "]" ] [ "+"folder ] [ 0*msg ] EOL | "#begin" [ "<" id ">" ] [ "[" description "]" ] [ "alternative" | "parallel" | something-else ] EOL 1*body "#end" EOL plaintext ::= [ "Content-Description:" description EOL EOL ] 1*line [ "#" EOL ] | "#<" type "/" subtype 0*(";" attribute "=" value) [ "(" comment ")" ] [ "[" description "]" ] EOL 1*line [ "#" EOL ] line ::= "##" text EOL -- interpreted as "#"text EOL | text EOL FILES $HOME/.mh_profile The user profile $MHBUILD Additional profile entries /home/rcoleman/nmh-bin/etc/mhn.defaulSystem default MIME profile entries PROFILE COMPONENTS Path: To determine the user's nmh directory Current-Folder: To find the default current folder mhbuild-compose-<typeTemplate for composing contents SEE ALSO mhlist(1), mhshow(1), mhstore(1) RFC-934: Proposed Standard for Message Encapsulation, RFC-2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC-2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, RFC-2047: Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text, RFC-2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures, RFC-2049: Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples. DEFAULTS `-headers' `-realsize' `-norfc934mode' `-nocheck' `-noebcdicsafe' `-noverbose' CONTEXT If a folder is given, it will become the current folder. The last message selected will become the current message. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 18:07 ` Bruce Stephens 1998-11-14 18:27 ` Lars Magne Ingebrigtsen @ 1998-11-14 19:55 ` Hrvoje Niksic 1998-11-14 20:45 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 70+ messages in thread From: Hrvoje Niksic @ 1998-11-14 19:55 UTC (permalink / raw) IMHO the "scripting" ideas are totally horrible, unless they involve non-text properties. I would absolutely hate to have to beware of message interpreting random text in my message as s&m "attach me" commands. The SGML idea is even worse, because it would mean having to type every `<' and `>' as `<' and `>'. Or am I missing something? -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Mix 2 table spoons sugar with 1 spoon salt. Put it in a bottle and stick a fuse into it. Say "Shit!" when it doesn't detonate. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 19:55 ` Hrvoje Niksic @ 1998-11-14 20:45 ` Lars Magne Ingebrigtsen 1998-11-14 20:45 ` Hrvoje Niksic 0 siblings, 1 reply; 70+ messages in thread From: Lars Magne Ingebrigtsen @ 1998-11-14 20:45 UTC (permalink / raw) Hrvoje Niksic <hniksic@srce.hr> writes: > IMHO the "scripting" ideas are totally horrible, unless they involve > non-text properties. Non-text props save badly. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 20:45 ` Lars Magne Ingebrigtsen @ 1998-11-14 20:45 ` Hrvoje Niksic 0 siblings, 0 replies; 70+ messages in thread From: Hrvoje Niksic @ 1998-11-14 20:45 UTC (permalink / raw) Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Hrvoje Niksic <hniksic@srce.hr> writes: > > > IMHO the "scripting" ideas are totally horrible, unless they involve > > non-text properties. > > Non-text props save badly. I know, but there are ways around that. format-alist is one way. -- Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A sadist is a masochist who follows the Golden Rule. ^ permalink raw reply [flat|nested] 70+ messages in thread
* Re: Scriptin' MIME 1998-11-14 15:30 Scriptin' MIME Lars Magne Ingebrigtsen 1998-11-14 18:07 ` Bruce Stephens @ 1998-11-14 18:29 ` Andi Kleen 1 sibling, 0 replies; 70+ messages in thread From: Andi Kleen @ 1998-11-14 18:29 UTC (permalink / raw) Cc: ding In article <m37lwy5m2e.fsf@sparky.gnus.org>, Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: > Now, I really like TeXinfo, but I realise that some weird people might > not, so I don't know whether this really is a good idea or not. MH has had something like this for years with mhbuild I liked it. Of course it didn't look like texinfo @) Example: #<text/enriched this content will be tagged as text/enriched # and this content will be tagged as text/plain # #<application/x-patch [this is a patch] and this content will be tagged as application/x-patch #audio/basic [silly giggle] \ |raw2audio -F < /usr/lib/sounds/giggle.au #image/gif [photo of foobar] \ /home/foobar/lib/picture.gif #@application/octet-stream; \ type=tar; \ conversions=compress [] \ access-type=anon-ftp; \ name="gnus.tar.gz"; \ directory="/pub/emacs/gnus"; \ site="ftp.gnus.org" -Andi ^ permalink raw reply [flat|nested] 70+ messages in thread
end of thread, other threads:[~1999-02-19 17:04 UTC | newest] Thread overview: 70+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <6f67buzzff.fsf@dna.lth.se> 1998-12-02 9:41 ` Automatic part insertion: åäö and 吃哪塞 on the same line Lars Magne Ingebrigtsen 1998-12-02 10:00 ` Russ Allbery 1998-12-02 12:49 ` Kurt Swanson 1998-12-02 17:19 ` Automatic part insertion: åäö and ÔÄû " François Pinard 1998-12-02 17:30 ` Hrvoje Niksic 1998-12-02 17:55 ` Richard Coleman 1998-12-03 8:53 ` Automatic part insertion: åao and ÔAû " Jari Aalto+list.ding 1998-12-02 18:02 ` Automatic part insertion: åäö and 吃哪塞 " Lars Magne Ingebrigtsen 1998-12-02 19:32 ` Lars Magne Ingebrigtsen 1998-12-02 10:27 ` Matt Armstrong 1998-12-02 18:03 ` Lars Magne Ingebrigtsen 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1998-12-02 20:39 ` Simon Josefsson [not found] ` <6fyaopd2dz.fsf@dna.lth.se> 1998-12-03 18:39 ` Simon Josefsson 1998-12-02 16:59 ` Hrvoje Niksic 1998-12-02 22:19 ` Karl Kleinpaste 1998-12-02 22:40 ` Hrvoje Niksic 1998-12-02 23:07 ` Lars Magne Ingebrigtsen 1999-02-13 2:17 ` Neil Crellin 1999-02-13 6:00 ` Dmitry Yaitskov 1999-02-13 12:59 ` Kai.Grossjohann 1999-02-19 13:58 ` Lars Magne Ingebrigtsen 1999-02-19 17:04 ` Neil Crellin 1998-12-03 0:10 ` Kai.Grossjohann 1998-12-03 6:38 ` Graham Murray 1998-12-03 10:46 ` Kai.Grossjohann 1998-12-03 11:50 ` Lars Magne Ingebrigtsen 1998-12-02 12:39 ` Vladimir Volovich 1998-12-02 17:38 ` Shenghuo ZHU 1998-12-02 18:34 ` Vladimir Volovich 1998-12-02 18:59 ` Shenghuo ZHU 1998-12-02 19:43 ` Lars Magne Ingebrigtsen 1998-12-02 23:34 ` Info on Internationalization Richard Coleman 1998-12-03 0:05 ` Lars Magne Ingebrigtsen 1998-12-03 0:17 ` Shenghuo ZHU 1998-12-03 11:39 ` Lars Magne Ingebrigtsen 1998-12-03 16:49 ` Shenghuo ZHU 1998-12-03 0:27 ` Richard Coleman 1998-12-06 14:11 ` François Pinard 1998-12-03 0:06 ` Shenghuo ZHU 1998-12-03 0:12 ` Hrvoje Niksic 1998-12-03 11:38 ` Lars Magne Ingebrigtsen 1998-12-03 13:18 ` Hrvoje Niksic 1998-12-03 16:39 ` Shenghuo ZHU 1998-12-03 16:38 ` Shenghuo ZHU 1998-12-04 1:15 ` Lars Magne Ingebrigtsen 1998-12-04 7:10 ` Shenghuo ZHU 1998-12-02 21:19 ` Automatic part insertion: åäö and 吃哪塞 on the same line Vladimir Volovich 1998-12-02 21:37 ` Shenghuo ZHU 1998-12-02 22:18 ` Vladimir Volovich 1998-12-02 23:29 ` Lars Magne Ingebrigtsen 1998-12-02 17:50 ` Hrvoje Niksic 1998-12-02 18:19 ` Lars Magne Ingebrigtsen 1998-12-02 19:12 ` Lars Magne Ingebrigtsen 1998-12-02 19:41 ` Vladimir Volovich 1998-12-02 21:34 ` Hrvoje Niksic 1998-12-02 22:29 ` Lars Magne Ingebrigtsen 1998-12-04 8:31 ` Vladimir Volovich 1998-12-02 21:33 ` Hrvoje Niksic 1998-12-02 16:26 ` Michael Harnois 1998-12-02 17:02 ` Michael Harnois 1998-11-14 15:30 Scriptin' MIME Lars Magne Ingebrigtsen 1998-11-14 18:07 ` Bruce Stephens 1998-11-14 18:27 ` Lars Magne Ingebrigtsen 1998-11-14 18:38 ` Bruce Stephens 1998-11-14 20:48 ` Richard Coleman 1998-11-14 19:55 ` Hrvoje Niksic 1998-11-14 20:45 ` Lars Magne Ingebrigtsen 1998-11-14 20:45 ` Hrvoje Niksic 1998-11-14 18:29 ` Andi Kleen
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).