1 Return-Path: <jani@nikula.org>
\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 AA75E431FBC
\r
6 for <notmuch@notmuchmail.org>; Sun, 28 Oct 2012 15:41:08 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id uQ2PnKimuHTc for <notmuch@notmuchmail.org>;
\r
16 Sun, 28 Oct 2012 15:41:07 -0700 (PDT)
\r
17 Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com
\r
18 [209.85.217.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
\r
19 (No client certificate requested)
\r
20 by olra.theworths.org (Postfix) with ESMTPS id 4D06B431FAF
\r
21 for <notmuch@notmuchmail.org>; Sun, 28 Oct 2012 15:41:07 -0700 (PDT)
\r
22 Received: by mail-lb0-f181.google.com with SMTP id gg6so3133586lbb.26
\r
23 for <notmuch@notmuchmail.org>; Sun, 28 Oct 2012 15:41:05 -0700 (PDT)
\r
24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
\r
25 d=google.com; s=20120113;
\r
26 h=from:to:cc:subject:in-reply-to:references:user-agent:date
\r
27 :message-id:mime-version:content-type:x-gm-message-state;
\r
28 bh=SNf8sHse4mzzADH8TpsSrQUwe8wy1vvwfxuXueMeiJ4=;
\r
29 b=X+dsYGH/+KJPRyBKKLwKU+w0db8bQkUuKT/Pr8S2PSrcaMBKmoyRIW/zeDSaDzHTVA
\r
30 3MQV9K0Eiu5LpDix6nQiF4ajjX74utLhS6yuSMBODD/h9ITS9DW6thMHeAEVaBww3Mcw
\r
31 Y7I/c/s1ta394GExT46zgM8qhzg6m7ZsMIsJ3zO8w83y9Ojvbc40gegezIWjPvO/Qmq2
\r
32 UvmL1RWHpbrIsh3QVyeTXcCC3I+2k30OGKCC7NhZD60fR8Vdas/BBF7u+l8vwbsWqklh
\r
33 293Ing1zdPZZbCugQ05njrGWl4YYr2OMWlRGzdaOySTb3fg+gZixb0KA/wS3TM6MuNJm
\r
35 Received: by 10.112.44.65 with SMTP id c1mr9770248lbm.62.1351464065866;
\r
36 Sun, 28 Oct 2012 15:41:05 -0700 (PDT)
\r
37 Received: from localhost (dsl-hkibrasgw4-fe51df00-27.dhcp.inet.fi.
\r
39 by mx.google.com with ESMTPS id m9sm2556735lbz.16.2012.10.28.15.41.04
\r
40 (version=SSLv3 cipher=OTHER); Sun, 28 Oct 2012 15:41:04 -0700 (PDT)
\r
41 From: Jani Nikula <jani@nikula.org>
\r
42 To: Austin Clements <amdragon@MIT.EDU>
\r
43 Subject: Re: [PATCH v5 8/9] man: document the date:since..until range queries
\r
44 In-Reply-To: <20121024210841.GU14861@mit.edu>
\r
45 References: <cover.1350854171.git.jani@nikula.org>
\r
46 <cff9c1dd87b8bc11326dca0b3589c81656500f5e.1350854171.git.jani@nikula.org>
\r
47 <20121024210841.GU14861@mit.edu>
\r
48 User-Agent: Notmuch/0.14+46~g272a1f1 (http://notmuchmail.org) Emacs/23.4.1
\r
50 Date: Mon, 29 Oct 2012 00:41:02 +0200
\r
51 Message-ID: <87d302kyo1.fsf@nikula.org>
\r
53 Content-Type: text/plain; charset=us-ascii
\r
55 ALoCoQkCDLQoGFuRr0R+eMz0kHwkI1VWPE+EuuFg4V/wm95EwllXLbU1x0UzF8XTQBHX9JL0PMvQ
\r
56 Cc: notmuch@notmuchmail.org
\r
57 X-BeenThere: notmuch@notmuchmail.org
\r
58 X-Mailman-Version: 2.1.13
\r
60 List-Id: "Use and development of the notmuch mail system."
\r
61 <notmuch.notmuchmail.org>
\r
62 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
63 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
64 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
65 List-Post: <mailto:notmuch@notmuchmail.org>
\r
66 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
67 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
68 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
69 X-List-Received-Date: Sun, 28 Oct 2012 22:41:08 -0000
\r
72 Many thanks, I'll incorporate most of your suggestions as-is.
\r
78 On Thu, 25 Oct 2012, Austin Clements <amdragon@MIT.EDU> wrote:
\r
79 > Quoth Jani Nikula on Oct 22 at 12:22 am:
\r
81 >> man/man7/notmuch-search-terms.7 | 147 +++++++++++++++++++++++++++++++++++----
\r
82 >> 1 file changed, 135 insertions(+), 12 deletions(-)
\r
84 >> diff --git a/man/man7/notmuch-search-terms.7 b/man/man7/notmuch-search-terms.7
\r
85 >> index 17a109e..fbd3ee7 100644
\r
86 >> --- a/man/man7/notmuch-search-terms.7
\r
87 >> +++ b/man/man7/notmuch-search-terms.7
\r
88 >> @@ -54,6 +54,8 @@ terms to match against specific portions of an email, (where
\r
90 >> folder:<directory-path>
\r
92 >> + date:<since>..<until>
\r
96 >> prefix is used to match the name or address of the sender of an email
\r
97 >> @@ -104,6 +106,26 @@ contained within particular directories within the mail store. Only
\r
98 >> the directory components below the top-level mail database path are
\r
99 >> available to be searched.
\r
103 >> +prefix can be used to restrict the results to only messages within a
\r
104 >> +particular time range (based on the Date: header) with a range syntax
\r
107 >> + date:<since>..<until>
\r
109 >> +See \fBDATE AND TIME SEARCH\fR below for details on the range
\r
110 >> +expression, and supported syntax for <since> and <until> date and time
\r
113 >> +The time range can also be specified using timestamps with a syntax
\r
116 >> + <initial-timestamp>..<final-timestamp>
\r
118 >> +Each timestamp is a number representing the number of seconds since
\r
119 >> +1970\-01\-01 00:00:00 UTC.
\r
121 >> In addition to individual terms, multiple terms can be
\r
122 >> combined with Boolean operators (
\r
123 >> .BR and ", " or ", " not
\r
124 >> @@ -117,20 +139,121 @@ operators, but will have to be protected from interpretation by the
\r
125 >> shell, (such as by putting quotation marks around any parenthesized
\r
128 >> -Finally, results can be restricted to only messages within a
\r
129 >> -particular time range, (based on the Date: header) with a syntax of:
\r
130 >> +.SH DATE AND TIME SEARCH
\r
132 >> - <initial-timestamp>..<final-timestamp>
\r
133 >> +This is a non-exhaustive description of the date and time search with
\r
134 >> +some pseudo notation. Most of the constructs can be mixed freely, and
\r
135 >> +in any order, but the same absolute date or time can't be expressed
\r
138 > I'm not sure what the end of this sentence means, though I assume it's
\r
139 > related to the restrictions on repeated absolute components. It would
\r
140 > also be nice to give a broader view of the syntax here. Maybe,
\r
142 > notmuch understands a variety of standard and natural ways of
\r
143 > expressing dates and times, both in absolute terms ("2012-10-24") and
\r
144 > in relative terms ("yesterday"). Any number of relative terms can be
\r
145 > combined ("1 hour 25 minutes") and an absolute date/time can be
\r
146 > combined with relative terms to further adjust it. A non-exhaustive
\r
147 > description of the syntax supported for absolute and relative terms is
\r
151 >> -Each timestamp is a number representing the number of seconds since
\r
152 >> -1970\-01\-01 00:00:00 UTC. This is not the most convenient means of
\r
153 >> -expressing date ranges, but until notmuch is fixed to accept a more
\r
154 >> -convenient form, one can use the date program to construct
\r
155 >> -timestamps. For example, with the bash shell the following syntax would
\r
156 >> -specify a date range to return messages from 2009\-10\-01 until the
\r
159 >> - $(date +%s \-d 2009\-10\-01)..$(date +%s)
\r
162 >> +.B The range expression
\r
164 >> +date:<since>..<until>
\r
166 >> +The above expression restricts the results to only messages from
\r
167 >> +<since> to <until>, based on the Date: header.
\r
169 >> +If <since> or <until> describes time at an accuracy of days or less,
\r
170 >> +the date/time is rounded, towards past for <since> and towards future
\r
171 >> +for <until>, to be inclusive. For example, date:january..february
\r
173 > The accuracy doesn't seem to have have anything to do with days; if I
\r
174 > say "date:1hour..1hour" I get a span of an hour. Describing it as
\r
175 > rounding also seems like it could be confusing to someone who hasn't
\r
176 > thought a lot about this (though, as someone who has though a lot
\r
177 > about this, I could be wrong). What about something like,
\r
179 > <since> and <until> can describe imprecise times, such as "yesterday".
\r
180 > In this case, <since> is taken as the earliest time it could describe
\r
181 > (the beginning of yesterday) and <until> is taken as the latest time
\r
182 > it could describe (the end of yesterday). Similarly,
\r
183 > date:january..february matches from the beginning of January to the
\r
186 >> +matches from the beginning of January until the end of
\r
187 >> +February. Similarly, date:yesterday..yesterday matches from the
\r
188 >> +beginning of yesterday until the end of yesterday.
\r
190 >> +Open-ended ranges are supported (since Xapian 1.2.1), i.e. it's
\r
191 >> +possible to specify date:..<until> or date:<since>.. to not limit the
\r
192 >> +start or end time, respectively. Unfortunately, pre-1.2.1 Xapian does
\r
194 > No need for the "Unfortunately".
\r
196 >> +not report an error on open ended ranges, but it does not work as
\r
197 >> +expected either.
\r
199 >> +Xapian does not support spaces in range expressions. You can replace
\r
201 > The man pages essentially don't reference Xapian and the fact that we
\r
202 > use Xapian is transparent to the uninterested user. Maybe just
\r
203 > "Currently, we do not support spaces ..."? Or "Due to technical
\r
204 > limitations, we do not currently support spaces ..." if you want to
\r
205 > convey that we feel the user's pain but it's actually hard to fix.
\r
207 >> +the spaces with '_', or (in most cases) '-', or (in some cases) leave
\r
208 >> +the spaces out altogether.
\r
210 > Maybe add "Examples in this man page use spaces for clarity."? It's
\r
211 > unfortunate that this rather critical piece of information is buried
\r
212 > in the middle of a subsection of the man page. I wonder if it should
\r
213 > at least go before the previous paragraph? We are going to get so
\r
214 > many people asking why their date searches don't work...
\r
217 >> +Entering date:expr without ".." (for example date:yesterday) won't
\r
218 >> +work, as it's not interpreted as a range expression at all. You can
\r
219 >> +achieve the expected result by duplicating the expr both sides of ".."
\r
220 >> +(for example date:yesterday..yesterday).
\r
225 >> +.B Relative date and time
\r
226 >> +[N|number] (years|months|weeks|days|hours|hrs|minutes|mins|seconds|secs) [...]
\r
228 >> +All refer to past, can be repeated and will be accumulated.
\r
230 >> +Units can be abbreviated to any length, with the otherwise ambiguous
\r
231 >> +single m being m for minutes and M for months.
\r
233 >> +Number multiplier can also be written out one, two, ..., ten, dozen,
\r
235 > This is the only use of "multiplier". I think it would be fine to
\r
236 > just say "the number".
\r
238 >> +hundred. As special cases last means one ("last week") and this means
\r
239 >> +zero ("this month").
\r
241 > Maybe, "Additionally, the unit may be preceded by "last" or "this"
\r
242 > (e.g., "last week" or "this month")."?
\r
245 >> +When combined with absolute date and time, the relative date and time
\r
246 >> +specification will be relative from the specified absolute date and
\r
249 >> +Examples: 5M2d, two weeks
\r
254 >> +.B Supported time formats
\r
256 > Supported absolute time formats?
\r
258 >> +H[H]:MM[:SS] [(am|a.m.|pm|p.m.)]
\r
260 >> +H[H] (am|a.m.|pm|p.m.)
\r
270 >> +Examples: 17:05, 5pm
\r
275 >> +.B Supported date formats
\r
277 > Supported absolute date formats?
\r
285 >> +M[M]/D[D][/[YY]YY]
\r
289 >> +D[D].M[M][.[YY]YY]
\r
291 >> +D[D][(st|nd|rd|th)] Mon[thname] [YYYY]
\r
293 >> +Mon[thname] D[D][(st|nd|rd|th)] [YYYY]
\r
297 >> +Month names can be abbreviated at three or more characters.
\r
299 >> +Weekday names can be abbreviated at three or more characters.
\r
301 >> +Examples: 2012-07-31, 31-07-2012, 7/31/2012, August 3
\r
311 >> +Some time zone codes, e.g. UTC, EET.
\r
projects / notmuch-archives.git / blob