From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/18794 Path: main.gmane.org!not-for-mail From: "Edward J. Sabol" Newsgroups: gmane.emacs.gnus.general Subject: Re: MML: The Summation Date: Tue, 17 Nov 1998 15:43:08 -0500 Sender: owner-ding@hpc.uh.edu Message-ID: <199811172043.PAA27154@alderaan.gsfc.nasa.gov> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035157259 8171 80.91.224.250 (20 Oct 2002 23:40:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:40:59 +0000 (UTC) Return-Path: Original-Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id PAA19181 for ; Tue, 17 Nov 1998 15:46:15 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by karazm.math.uh.edu (8.9.1/8.9.1) with ESMTP id OAB21751; Tue, 17 Nov 1998 14:45:16 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 17 Nov 1998 14:44:40 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id OAA17051 for ; Tue, 17 Nov 1998 14:44:17 -0600 (CST) Original-Received: from alderaan.gsfc.nasa.gov (alderaan.gsfc.nasa.gov [128.183.16.213]) by sclp3.sclp.com (8.8.5/8.8.5) with SMTP id PAA19110 for ; Tue, 17 Nov 1998 15:43:14 -0500 (EST) Original-Received: by alderaan.gsfc.nasa.gov (950413.SGI.8.6.12/951211.SGI.AUTO) id PAA27154; Tue, 17 Nov 1998 15:43:08 -0500 Original-To: Gnus Mailing List In-reply-to: (message from Lars Magne Ingebrigtsen on 17 Nov 1998 12:31:42 +0100) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:18794 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:18794 Excerpts from [ding]: (17-Nov-98) MML: The Summation by Lars Magne Ingebrigtsen > Cons: > 1) You can't expect people to learn a markup language. > 2) MML is ugly. > 3) Inband marking of elements is bound to fail. Look at the breakage > done by sendmail's "From " separator. I definitely agree with both (1) and (2) here, but I think (3) is the probably worst "con" of the bunch. It's the one that made me say "ewwwww!" aloud when I first read the postings about MML. > Pros: > 1) I like languages, not applications. Oh, pshaw. Gnus is an application. (Please, no semantic arguments. I understand what you're saying.) > 3) Doing MIME is dull, boring and tedious. By having a simple markup > language that gives us the power of MIME without the bogosity, > anyone can write scripts that do MML, which can then just be > pushed to Message for Mimification. Nobody said that a sciptable interface to message MIME-ing was a bad idea. In fact, I think it's a great idea, and I think MML fulfills this nicely. I'm just saying it makes a lousy user interface for on-the-fly message-mode composition. > 4) Doing it in a non-textual way (text props, overlays, markers, > invisible text) sucks because it doesn't allow the users > to edit the stuff properly. What if you are composing a complex > MIME thing in one buffer, and then you decide to copy the text > to a different buffer? I definitely agree that the user should be able to edit the buffer properly and cut, copy, and paste MIME things between message buffers. But surely this could be implemented? It would probably be difficult to implement, but impossible? I find that hard to believe. You might have to overload a few functions probably or add some hooks or both. I suppose that might seem pretty inelegant. However, your expertise with text properties, overlays, markers, and invisible text is much greater than mine, so I'll take your word on it. > That's basically it. I like the idea of just saying > > <#part> > And then writing some Chinese text, and then saying > > <#part> > And write some Japanese text, and then saying > > <#part type=image/jpeg filename="~/rms.jpg"> I think that with the user interface that I'm dreaming of the user wouldn't have to enter "" in his text in order to switch from Chinese text to Japanese text. The very fact that the Chinese text is using a Chinese font and the Japanese text is in a Japanese font gives enough information for the MIME user-interface to know that they are two different parts and to have the appropriate MIME information inserted either after the user hits `C-c C-c' to send the message or on the fly when the user changes fonts using some invisible text or other marker. But then there's the question of multipart/alternative and nested multiparts and how to compose those. That wouldn't be quite so easy, but I don't think it needs to be and I'm sure something could be figured out. Like possibly highlighting some number of adjacent parts with transient-mark-mode on and then hitting some key combo to signify that the parts are alternative or nested. > Of course, one doesn't necessarily have to have just one interface. > For instance, the trivial "include this attachment with this mail" can > be handled using a different mechanism -- for instance, a header line > `X-Attachment: type=image/jpeg filename="~/rms.jpg"' can be used in > these trivial cases. To be honest, I don't think I like this "trivial" interface all that much either, nor is it particularly needed since `C-c C-a filename RET' can just as easily enter the MML stuff. Just my two cents worth, Ed