f5/47370724096169a2309e1a348f655d1057ba6d

   1 Return-Path: <amdragon@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 62EEC431FD0\r
   6         for <notmuch@notmuchmail.org>; Thu,  9 Jun 2011 22:42:10 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id TGGakJmGzNWL for <notmuch@notmuchmail.org>;\r
  17         Thu,  9 Jun 2011 22:42:09 -0700 (PDT)\r
  18 Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com\r
  19         [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id E960E431FB6\r
  22         for <notmuch@notmuchmail.org>; Thu,  9 Jun 2011 22:42:08 -0700 (PDT)\r
  23 Received: by qyg14 with SMTP id 14so1395721qyg.5\r
  24         for <notmuch@notmuchmail.org>; Thu, 09 Jun 2011 22:42:08 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
  28         bh=C6l5c3ifQWMib5l5vdc1YnbB55dfUfyMeCVqwyeXF0M=;\r
  29         b=PNNDFMlSCnvy17nsKmuffjso6HxG4l1ub9RUz0qSZBpHjd8BPeXnxKrE8ne/BdsmrV\r
  30         A9Qx57kdR+FIBts5lGb738p/27hjFwtcp0YRLEPq/bT5jj/9DhQeK9GJv0GKPUmPGe0+\r
  31         cnSQ0LTz/sVFD1Nb3gi3hH033ipQ+e+IoLVcs=\r
  32 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  33         h=mime-version:sender:in-reply-to:references:date\r
  34         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
  35         b=TQFTspxWCCoTH+TIW8JLg0hlHpHkvjR/iumKNZ0YmczHIoUIyX7juHAvCgsev3aswS\r
  36         HMCpcqwge+3DzJlInpn72zDvE0LvTXEd740LQT2reMyVRU64Vum2eC/cJT/8MV05uErB\r
  37         JVfyyMnk/ib3XckzlIKgCuDqs7nzYa71bkuWY=\r
  38 MIME-Version: 1.0\r
  39 Received: by 10.229.176.170 with SMTP id be42mr1155393qcb.258.1307684528016;\r
  40         Thu, 09 Jun 2011 22:42:08 -0700 (PDT)\r
  41 Sender: amdragon@gmail.com\r
  42 Received: by 10.229.211.148 with HTTP; Thu, 9 Jun 2011 22:42:07 -0700 (PDT)\r
  43 In-Reply-To: <87tyc7hvtz.fsf@gilead.invalid>\r
  44 References: <874o4g563y.fsf@gilead.invalid>\r
  45         <87tyc7hvtz.fsf@gilead.invalid>\r
  46 Date: Fri, 10 Jun 2011 01:42:07 -0400\r
  47 X-Google-Sender-Auth: vNGU91dAHs4tzu96GTxThlKblAg\r
  48 Message-ID: <BANLkTinKCLg1epsGvfxtyy-_G2Hm=gjUMQ@mail.gmail.com>\r
  49 Subject: Re: [PATCH] emacs: User-defined sections in notmuch-hello\r
  50 From: Austin Clements <amdragon@mit.edu>\r
  51 To: Daniel Schoepe <daniel.schoepe@googlemail.com>\r
  52 Content-Type: text/plain; charset=ISO-8859-1\r
  53 Cc: notmuch@notmuchmail.org\r
  54 X-BeenThere: notmuch@notmuchmail.org\r
  55 X-Mailman-Version: 2.1.13\r
  56 Precedence: list\r
  57 List-Id: "Use and development of the notmuch mail system."\r
  58         <notmuch.notmuchmail.org>\r
  59 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  60         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  61 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  62 List-Post: <mailto:notmuch@notmuchmail.org>\r
  63 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  64 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  66 X-List-Received-Date: Fri, 10 Jun 2011 05:42:12 -0000\r
  67 \r
  68 This looks really interesting.\r
  69 \r
  70 I haven't examined the code very closely, but I have some high level comments.\r
  71 \r
  72 It seems that the code is simultaneously trying to do something very\r
  73 general, but also hard-coding a lot of behaviors, and I think the\r
  74 code's complexity suffers for it.  What would this look like if the\r
  75 *entire* hello screen were replaced by a configurable list of\r
  76 sections?  What I'm imagining could be as simple as a list of\r
  77 section-generating functions plus a collection of standard functions\r
  78 for generating standard sections (probably known to customize to make\r
  79 it easy for non-elispers to control).\r
  80 \r
  81 For more-configurable sections, there could be a mechanism for passing\r
  82 arguments, but this quickly enters the land of hair-raising defcustoms\r
  83 and confusing flexibility.  I think it would be much simpler and more\r
  84 user-friendly to require the functions in this list to take no\r
  85 arguments (at least, none that are user-configurable).  Flexible\r
  86 sections could be implemented then as a low-level function that takes\r
  87 arguments and one or more no-argument high-level functions that call\r
  88 the low-level section generator either with fixed arguments, or with\r
  89 the values of other customize variables.  This would keep things\r
  90 simple and fairly flexible for non-elispers, without sacrificing\r
  91 complete flexibility if you're willing to write a few lines of elisp.\r
  92 \r
  93 Maybe you also want to configure the title of each section.  But, IMO,\r
  94 this is also confusing flexibility.  In fact, with the no-argument\r
  95 section generators, it would make a lot of sense to simply put the\r
  96 section name in the function's plist.\r
  97 \r
  98 This wouldn't fit well with the current logic to compute the\r
  99 cross-section widest tag, but personally I've always found that\r
 100 behavior extremely confusing (not to mention buggy) and wouldn't miss\r
 101 it at all.\r
 102 \r
 103 The use of the term "title" for pretty-printed tags is confusing.  To\r
 104 me, "title" means the section title.  For example, I couldn't figure\r
 105 out what "Return widest title string in SECTION." meant until I read\r
 106 the code (*flashback* "a section only has one title, what the heck is\r
 107 the widest one?")\r
 108 \r
 109 This patch should probably be split into a few patches, as it seems to\r
 110 also introduce new functionality for some of the sections (and does\r
 111 little things like moving notmuch-remove-if-not).\r
 112 \r
 113 On Fri, Jun 3, 2011 at 9:46 AM, Daniel Schoepe\r
 114 <daniel.schoepe@googlemail.com> wrote:\r
 115 > On Fri, 27 May 2011 20:52:01 +0200, Daniel Schoepe <daniel.schoepe@googlemail.com> wrote:\r
 116 >> I'll also work on some tests for this functionality, (if no one\r
 117 >> has big, structural complaints about the code).\r
 118 >\r
 119 > I rebased my patch against the current master and wrote some tests.\r