Re: [PATCH v5 2/9] parse-time-string: add a date/time parser to notmuch
authorTomi Ollila <tomi.ollila@iki.fi>
Sat, 27 Oct 2012 20:38:00 +0000 (23:38 +0300)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:50:07 +0000 (09:50 -0800)
c6/f28ffea63134adb2ee62e5d228210ba5ee9174 [new file with mode: 0644]

diff --git a/c6/f28ffea63134adb2ee62e5d228210ba5ee9174 b/c6/f28ffea63134adb2ee62e5d228210ba5ee9174
new file mode 100644 (file)
index 0000000..61463c6
--- /dev/null
@@ -0,0 +1,106 @@
+Return-Path: <tomi.ollila@iki.fi>\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 DE6B4431FAF\r
+       for <notmuch@notmuchmail.org>; Sat, 27 Oct 2012 13:38:02 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+       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 K1EhJFdUrBFx for <notmuch@notmuchmail.org>;\r
+       Sat, 27 Oct 2012 13:38:01 -0700 (PDT)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+       by olra.theworths.org (Postfix) with ESMTP id C3732431FBF\r
+       for <notmuch@notmuchmail.org>; Sat, 27 Oct 2012 13:38:01 -0700 (PDT)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+       by guru.guru-group.fi (Postfix) with ESMTP id D49CF100045;\r
+       Sat, 27 Oct 2012 23:38:00 +0300 (EEST)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Austin Clements <amdragon@MIT.EDU>, Jani Nikula <jani@nikula.org>\r
+Subject: Re: [PATCH v5 2/9] parse-time-string: add a date/time parser to\r
+       notmuch\r
+In-Reply-To: <20121025185816.GX14861@mit.edu>\r
+References: <cover.1350854171.git.jani@nikula.org>\r
+       <a90d3b687895a26f765539d6c0420038a74ee42f.1350854171.git.jani@nikula.org>\r
+       <20121022081444.GM14861@mit.edu> <20121025185816.GX14861@mit.edu>\r
+User-Agent: Notmuch/0.14+59~gf9031cd (http://notmuchmail.org) Emacs/24.2.1\r
+       (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+       $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+       !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Sat, 27 Oct 2012 23:38:00 +0300\r
+Message-ID: <m2hapf647r.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: notmuch@notmuchmail.org\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: Sat, 27 Oct 2012 20:38:03 -0000\r
+\r
+On Thu, Oct 25 2012, Austin Clements wrote:\r
+\r
+> Quoth myself on Oct 22 at  4:14 am:\r
+>> Overall this looks pretty good to me, and I must say, this parser is\r
+>> amazingly flexible and copes well with a remarkably hostile grammar.\r
+>> \r
+>> A lot of little comments below (sorry if any of this ground has\r
+>> already been covered in the previous four versions).\r
+>> \r
+>> I do have one broad comment.  While I'm all for ad hoc parsers for ad\r
+>> hoc grammars like dates, there is one piece of the literature I think\r
+>> this parser suffers for by ignoring: tokenizing.  I think it would\r
+>> simplify a lot of this code if it did a tokenizing pass before the\r
+>> parsing pass.  It doesn't have to be a serious tokenizer with\r
+>> streaming and keywords and token types and junk; just something that\r
+>> first splits the input into substrings, possibly just non-overlapping\r
+>> matches of [[:digit:]]+|[[:alpha:]]+|[-+:/.].  This would simplify the\r
+>> handling of postponed numbers because, with trivial lookahead in the\r
+>> token stream, you wouldn't have to postpone them.  Likewise, it would\r
+>> eliminate last_field.  It would simplify keyword matching because you\r
+>> wouldn't have to worry about matching substrings (I spent a long time\r
+>> staring at that code before I figured out what it would and wouldn't\r
+>> accept).  Most important, I think it would make the parser more\r
+>> predictable for users; for example, the parser currently accepts\r
+>> things like "saturtoday" because it's aggressively single-pass.\r
+>\r
+> I should add that I am not at all opposed to this patch as it is\r
+> currently designed.  We need a date parser.  My comment about\r
+> separating tokenization is just a way that this code could probably be\r
+> simplified if someone were so inclined or if simplifying the code\r
+> would help it pass any hurdles.\r
+\r
+What if the current patch set, i.e. messages\r
+\r
+$ grep Message-Id: ~/patch | sed 's/Message-Id: /id:/; y/<>/""/'\r
+id:"e684cadbb5a01b6079ef344b0d6f97541847914a.1350854171.git.jani@nikula.org"\r
+id:"a90d3b687895a26f765539d6c0420038a74ee42f.1350854171.git.jani@nikula.org"\r
+id:"75a8f129d5e0d824b3e04ddfc1816c45fa0ec70d.1350854171.git.jani@nikula.org"\r
+id:"606a94d565e6b21abfc59d6ba9676a807d669127.1350854171.git.jani@nikula.org"\r
+id:"cbd383bfc4bf844bb0366f13f675d48956137c52.1350854171.git.jani@nikula.org"\r
+id:"f21b8702728457c087478b26700e9448bc16c61d.1350854171.git.jani@nikula.org"\r
+id:"37026480956679b12e82e4975f1837e93ef1c531.1350854171.git.jani@nikula.org"\r
+id:"cff9c1dd87b8bc11326dca0b3589c81656500f5e.1350854171.git.jani@nikula.org"\r
+\r
+(patches 1-8 / 9 -- NEWS patch is stale) would just be pushed: there are\r
+just few trivial things to be tuned and NEWS rebased -- which I think \r
+Jani will gladly do... It is just so much easier for him to continue\r
+and us others to review the new diffs than these whole patches again\r
+and again... At least I volunteer to track that these remaining issues\r
+(tokenizer not included :).\r
+\r
+Tomi\r