Re: BEGIN_SRC..END_SRC

[Yann Hodique <yann.hodique@gmail.com>]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

> Yann Hodique writes:
>> 
>> As I said in a previous mail, it doesn't change anything for GMail, and
>> that is also (unfortunately) conformant.

> I disagree.  It may be unfortunate, but it is not conformant.  To
> quote the RFCs:

[...]

> So it isn't optional behavior.  It's required.  It's simply the case
> that the authors of RFC 2046 could imagine stuff like Microsoft HTML,
> in which case you probably want to treat text/html as binary if you
> don't have a decent HTML rendering engine to use.  However, "should"
> in the section 4.1.4 is not blanket permission to treat all unknown
> text/* as application/octet-stream, as Gmail apparently does.

Well, let's not go to nit-picking about issues we can't solve anyway :)
The behavior is clearly broken, and I'm also not confident anybody will
fix it (they might even pretend that's intentional for whatever twisted
reason, or that the phrasing doesn't have to respect an RFC that was
written at a later point in time). I personally wouldn't fight for
a "should".

>> Only [Gnus] we can fix. So in any case, I don't believe we can
>> ever afford not to emit the text/plain alternative for dumb (yet
>> potentially even conformant) MUAs.

> Maybe.

> But given that we know that Gmail deliberately goes out of its way to
> suck in our community (eg, encouraging top-posting, which has its
> place but it ain't here[1]), I don't really think we should consider
> problems with Gmail an argument against using standard constructs.  If
> Thunderbird or nmh or mutt has issues or whatever-the-GNOMEish-MUA-is
> does, that's another matter.

Let's focus on the matter at hand :)
The fact is people use GMail to access the mailing list, and I don't see
a point in annoying them gratuitously. By gratuitously I mean choosing
a standard construct they (and probably others) don't recognize over
another standard construct they (and probably others) do recognize.
That's an argument *for* using standard constructs, just not *any*
standard construct.

>> Given that, since Emacs is probably the only "MUA" that will ever
>> implement a handler for any elisp-related MIME type, whether it's
>> text/emacs-lisp or application/emacs-lisp is probably not that much of
>> an issue (but again, we should use the former)

> No, it's the *only* issue here.  If we use text/emacs-lisp, people who
> use conformant MUAs have a choice of font-locked display or plain
> text.  If we use application/emacs-lisp, people who use conformant
> MUAs have a choice of font-locked display or saving it to a file.

That's not what I mean. What I'm saying is:

1. "application/emacs-lisp" will work mostly (only?) in Gnus

2. "text/emacs-lisp" will work on conformant MUAs, but is broken in
   common ones. It might also be font-locked in some MUAs, eventually

3. "text/plain + application/emacs-lisp" will work (potentially
   sub-optimally) on conformant MUAs and in common ones. It is also
   font-locked in Gnus

4. "text/plain + text/emacs-lisp" will work on conformant MUAs and in
   common ones. It might also be font-locked in some MUAs, eventually

You're saying 2. is better that 1., which I totally agree with.
What I'm saying is that 4. is even better because it's just as standard,
and better supported overall.

And as a side note, I'm saying that the MUAs that might do something
fancy with an elisp MIME type are probably all running in Emacs, so that
realistically 3. and 4. are not that different. Meaning that 3. is
probably kind of acceptable in the short term (as long as Gnus is not
fixed) even though it's dodgy.

Also note that none of application/emacs-lisp or text/emacs-lisp are
registered MIME types. That's *also* something that should be fixed,
and presumably before Gnus starts getting fixed.

Yann.

-- 
Heaven must be the sound of running water.

  -- Fremen Saying