Re: MML: The Summation

["Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov>]

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 "<part>" 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