emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BEGIN_SRC..END_SRC


From: Eric Schulte
Subject: Re: BEGIN_SRC..END_SRC
Date: Wed, 09 May 2012 12:30:38 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Yann Hodique <address@hidden> writes:

>>>>>> "Eric" == Eric Schulte <address@hidden> writes:
>
>> Yann Hodique <address@hidden> writes:
>>> 
>>> 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.
>
> Really ? that sounds like a gnus bug then. I mean, if the text/plain
> alternative is positioned correctly (meaning *first*), and there's no
> fancy customization of `mm-discouraged-alternatives', the text/x-sh
> one should indeed be preferred.  At least it worked as expected with
> the application/emacs-lisp pieces.
>

OK, I had mixed up the first/second priority.  If I swap the order and I
switch from text/x-emacs-lisp to text/x-sh I can get gnus to fontify the
results, although there is also a "[2. text/x-sh]" button included in my
buffer.  Regardless, some additional work will be required.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]