Re: BEGIN_SRC..END_SRC

[Eric Schulte]

Yann Hodique <address@hidden> writes:

>>>>>> "Eric" == Eric Schulte <address@hidden> writes:
>
>> Lars Magne Ingebrigtsen <address@hidden> writes:
>>> "Stephen J. Turnbull" <address@hidden> writes:
>>> 
>>>> > We don't want to bother with MIME for short snippets.
>>>> 
>>>> Then what do you think your MUA is there for?
>>> 
>>> The support for embedding small snippets via MIME is dicey in some mail
>>> readers, last time I looked.  They present(ed) the first textual part as
>>> the only visible text, and presented the rest as attachments.
>
>> To contribute to the bikeshedding [1], I've composed an example email in
>> gnus with inline Org-mode-syntax code, inline mime-annotated code, and
>> attached (disposition=inline) code.  The results as displayed by gnus,
>> gmail and gmx are shown [2].  I don't know if gnus should limit itself
>> based on the limitations of non-standards-compliant commercial software,
>> but at the least it would seem that while the mime approach /should/ be
>> the most portable it will in fact not be portable to many (maybe most)
>> other MUAs.
>
> Note that it's the reason why my initial proposal was based on inline
> multipart alternative. Providing a MIME fallback that any MUA should
> recognize (such as text/plain) should increase vastly the chances of
> proper formatting. At least GMail behaves "correctly" when the
> text/plain alternative is provided.
>

Yes, and gmx displays text/plain alternatives as well (although it also
includes the text as an attachment).  Unfortunately when the text/plain
alternative is provided Gnus does *not* fontify the text/x-sh preferred
alternative but instead renders the plain text -- which sort of defaults
the purpose of the whole exercise.

Also, this approach requires either some explicit function call or some
new markup to mime-encode code examples as part of message composition.

Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/