unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Mark Walters <markwalters1009@gmail.com>
To: "W. Trevor King" <wking@tremily.us>, David Bremner <david@tethera.net>
Cc: notmuch@notmuchmail.org
Subject: Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons
Date: Sun, 09 Feb 2014 10:10:08 +0000	[thread overview]
Message-ID: <878utkd2bj.fsf@qmul.ac.uk> (raw)
In-Reply-To: <20140208165931.GB17142@odin.tremily.us>


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@tremily.us> wrote:
> On Sat, Feb 08, 2014 at 08:55:02AM -0400, David Bremner wrote:
>> "W. Trevor King" <wking@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

  reply	other threads:[~2014-02-09 10:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-02 20:46 [RFC] Content-Description when naming MIME parts in Emacs mode W. Trevor King
2014-02-02 23:33 ` David Bremner
2014-02-03  8:04 ` Mark Walters
2014-02-03 10:45   ` [PATCH 0/2] W. Trevor King
2014-02-03 10:45     ` [PATCH 1/2] notmuch-show: Add content-description output pair W. Trevor King
2014-02-03 10:45     ` [PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons W. Trevor King
2014-02-03 20:15       ` Mark Walters
2014-02-03 20:34         ` W. Trevor King
2014-02-04  1:32           ` W. Trevor King
2014-02-08 12:55             ` David Bremner
2014-02-08 16:59               ` W. Trevor King
2014-02-09 10:10                 ` Mark Walters [this message]
2014-02-09 12:53                   ` David Bremner
2014-02-08 17:33           ` W. Trevor King
2014-02-09 10:17             ` Mark Walters
2014-02-03 20:44       ` Tomi Ollila
2014-02-04  0:14         ` W. Trevor King
2014-02-04 10:31           ` Tomi Ollila
2014-02-03 14:24     ` [PATCH 0/2] David Bremner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878utkd2bj.fsf@qmul.ac.uk \
    --to=markwalters1009@gmail.com \
    --cc=david@tethera.net \
    --cc=notmuch@notmuchmail.org \
    --cc=wking@tremily.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).