[PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons

[Mark Walters]

Initially I agreed with Bremner that we should be as faithful as
possible in our json/sexp output. However, looking at other headers like
cc: it seems that this can be present but empty (at least I sent myself
a message with that property), but that notmuch-show omits it.

Looking at the code for that pathway we use
g_mime_message_get_recipients followed by
internet_address_list_to_string and we only output a cc: pair if this is
non-null (which means we had an address)

In light of that I think changing the cli to only output
content-description if non-null seems consistent.

Best wishes

Mark





On Sat, 08 Feb 2014, "W. Trevor King" <wking at tremily.us> wrote:
> On Sat, Feb 08, 2014 at 08:55:02AM -0400, David Bremner wrote:
>> "W. Trevor King" <wking at tremily.us> writes:
>> > Rather than patching this in Emacs, maybe we should collapse the
>> > “not set” and “set to empty string” cases in notmuch-show.c?  I
>> > can't think of any reasons why someone would want to distinguish
>> > those two cases, and it's easier all around if we standardize the
>> > representation as far upstream as possible.
>> 
>> Do the RFCs have anything to say about headers with empty content?
>> If not I'd be inclined to leave the CLI output as raw as possible,
>> just because people are always finding new ways to apply tools.
>
> RFC 2183 does not describe Content-Description, it just uses it in
> some examples [1].  In all the examples where Content-Description is
> present, the value is not empty.  RFC 2045 defines
> Content-Description, but it doesn't give all that much information
> [2]:
>
>   The ability to associate some descriptive information with a given
>   body is often desirable.  For example, it may be useful to mark an
>   "image" body as "a picture of the Space Shuttle Endeavor."  Such
>   text may be placed in the Content-Description header field.  This
>   header field is always optional.
>
>     description := "Content-Description" ":" *text
>
>   The description is presumed to be given in the US-ASCII character
>   set, although the mechanism specified in RFC 2047 may be used for
>   non-US-ASCII Content-Description values.
>
> I couldn't find more generic references to the meaning of empty header
> values, but I find it hard to imagine anyone assigning semantic value
> to an explicitly-empty description (vs. no Content-Description at
> all).
>
> Cheers,
> Trevor
>
> [1]: http://tools.ietf.org/html/rfc2183#section-3
> [2]: http://tools.ietf.org/html/rfc2045#section-8
>
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy