Re: [PATCH] doc: Allow rst2man.py as an alternative to rst2man

[notmuch-archives.git] / 39 / 1d834542b73872eca66a64c93633d2e9cf151d

Return-Path: <jani@nikula.org>\r
X-Original-To: notmuch@notmuchmail.org\r
Delivered-To: notmuch@notmuchmail.org\r
Received: from localhost (localhost [127.0.0.1])\r
        by olra.theworths.org (Postfix) with ESMTP id A75F7431FAF\r
        for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 14:25:56 -0800 (PST)\r
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
X-Spam-Flag: NO\r
X-Spam-Score: -0.7\r
X-Spam-Level: \r
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
        tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
Received: from olra.theworths.org ([127.0.0.1])\r
        by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
        with ESMTP id PYASk-r6KkjV for <notmuch@notmuchmail.org>;\r
        Wed, 18 Jan 2012 14:25:56 -0800 (PST)\r
Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com\r
        [209.85.215.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
        (No client certificate requested)\r
        by olra.theworths.org (Postfix) with ESMTPS id D9E6C431FAE\r
        for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 14:25:55 -0800 (PST)\r
Received: by eaal1 with SMTP id l1so483281eaa.26\r
        for <notmuch@notmuchmail.org>; Wed, 18 Jan 2012 14:25:53 -0800 (PST)\r
Received: by 10.213.114.74 with SMTP id d10mr1081173ebq.128.1326925553085;\r
        Wed, 18 Jan 2012 14:25:53 -0800 (PST)\r
Received: from localhost (dsl-hkibrasgw4-fe50f800-253.dhcp.inet.fi.\r
        [84.248.80.253])\r
        by mx.google.com with ESMTPS id s16sm105188335eef.2.2012.01.18.14.25.48\r
        (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 14:25:51 -0800 (PST)\r
From: Jani Nikula <jani@nikula.org>\r
To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org\r
Subject: Re: [PATCH 1/3] mime node: Record depth-first part numbers\r
In-Reply-To: <1326918507-28033-2-git-send-email-amdragon@mit.edu>\r
References: <1326918507-28033-1-git-send-email-amdragon@mit.edu>\r
        <1326918507-28033-2-git-send-email-amdragon@mit.edu>\r
User-Agent: Notmuch/0.11+76~g1de742d (http://notmuchmail.org) Emacs/23.3.1\r
        (i686-pc-linux-gnu)\r
Date: Thu, 19 Jan 2012 00:25:45 +0200\r
Message-ID: <87zkdkbqc6.fsf@nikula.org>\r
MIME-Version: 1.0\r
Content-Type: text/plain; charset=us-ascii\r
Cc: dkg@fifthhorseman.net\r
X-BeenThere: notmuch@notmuchmail.org\r
X-Mailman-Version: 2.1.13\r
Precedence: list\r
List-Id: "Use and development of the notmuch mail system."\r
        <notmuch.notmuchmail.org>\r
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
        <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
List-Post: <mailto:notmuch@notmuchmail.org>\r
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
        <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
X-List-Received-Date: Wed, 18 Jan 2012 22:25:56 -0000\r
\r
On Wed, 18 Jan 2012 15:28:25 -0500, Austin Clements <amdragon@MIT.EDU> wrote:\r
> This makes the part numbers readily accessible to formatters.\r
> Hierarchical part numbering would be a more natural and efficient fit\r
> for MIME and may be the way to go in the future, but depth-first\r
> numbering maintains compatibility with what we currently do.\r
\r
Hi, please find a few things to consider below. If you disagree after\r
considering, it's quite all right, as they're largely style matters. :)\r
\r
BR,\r
Jani.\r
\r
\r
> ---\r
>  mime-node.c      |   33 ++++++++++++++++++++++++++++++++-\r
>  notmuch-client.h |   11 +++++++++++\r
>  2 files changed, 43 insertions(+), 1 deletions(-)\r
> \r
> diff --git a/mime-node.c b/mime-node.c\r
> index d26bb44..30b542f 100644\r
> --- a/mime-node.c\r
> +++ b/mime-node.c\r
> @@ -104,6 +104,10 @@ mime_node_open (const void *ctx, notmuch_message_t *message,\r
>      root->nchildren = 1;\r
>      root->ctx = mctx;\r
>  \r
> +    root->part_num = 0;\r
> +    root->next_child = 0;\r
> +    root->next_part_num = 1;\r
> +\r
>      *root_out = root;\r
>      return NOTMUCH_STATUS_SUCCESS;\r
>  \r
> @@ -133,6 +137,8 @@ _mime_node_create (const mime_node_t *parent, GMimeObject *part)\r
>       talloc_free (node);\r
>       return NULL;\r
>      }\r
> +    node->parent = parent;\r
> +    node->part_num = node->next_part_num = -1;\r
>  \r
>      /* Deal with the different types of parts */\r
>      if (GMIME_IS_PART (part)) {\r
> @@ -217,6 +223,7 @@ mime_node_t *\r
>  mime_node_child (const mime_node_t *parent, int child)\r
>  {\r
>      GMimeObject *sub;\r
> +    mime_node_t *node;\r
>  \r
>      if (!parent || child < 0 || child >= parent->nchildren)\r
>       return NULL;\r
> @@ -234,7 +241,31 @@ mime_node_child (const mime_node_t *parent, int child)\r
>       INTERNAL_ERROR ("Unexpected GMimeObject type: %s",\r
>                       g_type_name (G_OBJECT_TYPE (parent->part)));\r
>      }\r
> -    return _mime_node_create (parent, sub);\r
> +    node = _mime_node_create (parent, sub);\r
> +\r
> +    if (child == parent->next_child && parent->next_part_num != -1) {\r
> +     /* We're traversing in depth-first order.  Record the child's\r
> +      * depth-first numbering. */\r
> +     node->part_num = parent->next_part_num;\r
> +     node->next_part_num = node->part_num + 1;\r
> +\r
> +     /* Drop the const qualifier because these are internal fields\r
> +      * whose mutability doesn't affect the interface. */\r
\r
FWIW, I'm not a big fan of casting away const. Either it is const, or it\r
isn't. Not very many places would be affected if you dropped the const\r
qualifier from the related interface(s) altogether, and things would\r
look cleaner here. But I suppose this is a matter of taste.\r
\r
> +     ((mime_node_t*)parent)->next_child++;\r
> +     ((mime_node_t*)parent)->next_part_num = -1;\r
> +\r
> +     if (node->nchildren == 0) {\r
> +         /* We've reached a leaf, so find the parent that has more\r
> +          * children and set it up to number its next child. */\r
> +         const mime_node_t *it = node;\r
> +         while (it && it->next_child == it->nchildren)\r
> +             it = it->parent;\r
> +         if (it)\r
> +             ((mime_node_t*)it)->next_part_num = node->part_num + 1;\r
> +     }\r
> +    }\r
\r
Following the constness around made me wonder why the above if block\r
isn't within _mime_node_create(). It does have a feel of initialization\r
related to creation in it. (You'd have to pass more info to it though.)\r
\r
> +\r
> +    return node;\r
>  }\r
>  \r
>  static mime_node_t *\r
> diff --git a/notmuch-client.h b/notmuch-client.h\r
> index 62ede28..b3dcb6b 100644\r
> --- a/notmuch-client.h\r
> +++ b/notmuch-client.h\r
> @@ -281,6 +281,13 @@ typedef struct mime_node {\r
>      /* The number of children of this part. */\r
>      int nchildren;\r
>  \r
> +    /* The parent of this node or NULL if this is the root node. */\r
> +    const struct mime_node *parent;\r
> +\r
> +    /* The depth-first part number of this child if the MIME tree is\r
> +     * being traversed in depth-first order, or -1 otherwise. */\r
> +    int part_num;\r
> +\r
>      /* True if decryption of this part was attempted. */\r
>      notmuch_bool_t decrypt_attempted;\r
>      /* True if decryption of this part's child succeeded.  In this\r
> @@ -302,6 +309,10 @@ typedef struct mime_node {\r
>      /* Internal: For successfully decrypted multipart parts, the\r
>       * decrypted part to substitute for the second child. */\r
>      GMimeObject *decrypted_child;\r
> +\r
> +    /* Internal: The next child for depth-first traversal and the part\r
> +     * number to assign it (or -1 if unknown). */\r
> +    int next_child, next_part_num;\r
\r
A matter of taste again, but I wouldn't use "int foo, bar" in struct\r
declarations.\r
\r
>  } mime_node_t;\r
>  \r
>  /* Construct a new MIME node pointing to the root message part of\r
> -- \r
> 1.7.7.3\r
> \r