From: Jani Nikula Date: Sun, 28 Oct 2012 22:41:02 +0000 (+0200) Subject: Re: [PATCH v5 8/9] man: document the date:since..until range queries X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=c09b1a65854eee9c233c10c753ceb61569f7ab29;p=notmuch-archives.git Re: [PATCH v5 8/9] man: document the date:since..until range queries --- diff --git a/08/6d892f496698ced6b6d8b10ed8ffe9097470de b/08/6d892f496698ced6b6d8b10ed8ffe9097470de new file mode 100644 index 000000000..723ccdce5 --- /dev/null +++ b/08/6d892f496698ced6b6d8b10ed8ffe9097470de @@ -0,0 +1,315 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id AA75E431FBC + for ; Sun, 28 Oct 2012 15:41:08 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id uQ2PnKimuHTc for ; + Sun, 28 Oct 2012 15:41:07 -0700 (PDT) +Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com + [209.85.217.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 4D06B431FAF + for ; Sun, 28 Oct 2012 15:41:07 -0700 (PDT) +Received: by mail-lb0-f181.google.com with SMTP id gg6so3133586lbb.26 + for ; Sun, 28 Oct 2012 15:41:05 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=google.com; s=20120113; + h=from:to:cc:subject:in-reply-to:references:user-agent:date + :message-id:mime-version:content-type:x-gm-message-state; + bh=SNf8sHse4mzzADH8TpsSrQUwe8wy1vvwfxuXueMeiJ4=; + b=X+dsYGH/+KJPRyBKKLwKU+w0db8bQkUuKT/Pr8S2PSrcaMBKmoyRIW/zeDSaDzHTVA + 3MQV9K0Eiu5LpDix6nQiF4ajjX74utLhS6yuSMBODD/h9ITS9DW6thMHeAEVaBww3Mcw + Y7I/c/s1ta394GExT46zgM8qhzg6m7ZsMIsJ3zO8w83y9Ojvbc40gegezIWjPvO/Qmq2 + UvmL1RWHpbrIsh3QVyeTXcCC3I+2k30OGKCC7NhZD60fR8Vdas/BBF7u+l8vwbsWqklh + 293Ing1zdPZZbCugQ05njrGWl4YYr2OMWlRGzdaOySTb3fg+gZixb0KA/wS3TM6MuNJm + LPAg== +Received: by 10.112.44.65 with SMTP id c1mr9770248lbm.62.1351464065866; + Sun, 28 Oct 2012 15:41:05 -0700 (PDT) +Received: from localhost (dsl-hkibrasgw4-fe51df00-27.dhcp.inet.fi. + [80.223.81.27]) + by mx.google.com with ESMTPS id m9sm2556735lbz.16.2012.10.28.15.41.04 + (version=SSLv3 cipher=OTHER); Sun, 28 Oct 2012 15:41:04 -0700 (PDT) +From: Jani Nikula +To: Austin Clements +Subject: Re: [PATCH v5 8/9] man: document the date:since..until range queries +In-Reply-To: <20121024210841.GU14861@mit.edu> +References: + + <20121024210841.GU14861@mit.edu> +User-Agent: Notmuch/0.14+46~g272a1f1 (http://notmuchmail.org) Emacs/23.4.1 + (i686-pc-linux-gnu) +Date: Mon, 29 Oct 2012 00:41:02 +0200 +Message-ID: <87d302kyo1.fsf@nikula.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Gm-Message-State: + ALoCoQkCDLQoGFuRr0R+eMz0kHwkI1VWPE+EuuFg4V/wm95EwllXLbU1x0UzF8XTQBHX9JL0PMvQ +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 28 Oct 2012 22:41:08 -0000 + + +Many thanks, I'll incorporate most of your suggestions as-is. + +BR, +Jani. + + +On Thu, 25 Oct 2012, Austin Clements wrote: +> Quoth Jani Nikula on Oct 22 at 12:22 am: +>> --- +>> man/man7/notmuch-search-terms.7 | 147 +++++++++++++++++++++++++++++++++++---- +>> 1 file changed, 135 insertions(+), 12 deletions(-) +>> +>> diff --git a/man/man7/notmuch-search-terms.7 b/man/man7/notmuch-search-terms.7 +>> index 17a109e..fbd3ee7 100644 +>> --- a/man/man7/notmuch-search-terms.7 +>> +++ b/man/man7/notmuch-search-terms.7 +>> @@ -54,6 +54,8 @@ terms to match against specific portions of an email, (where +>> +>> folder: +>> +>> + date:.. +>> + +>> The +>> .B from: +>> prefix is used to match the name or address of the sender of an email +>> @@ -104,6 +106,26 @@ contained within particular directories within the mail store. Only +>> the directory components below the top-level mail database path are +>> available to be searched. +>> +>> +The +>> +.B date: +>> +prefix can be used to restrict the results to only messages within a +>> +particular time range (based on the Date: header) with a range syntax +>> +of: +>> + +>> + date:.. +>> + +>> +See \fBDATE AND TIME SEARCH\fR below for details on the range +>> +expression, and supported syntax for and date and time +>> +expressions. +>> + +>> +The time range can also be specified using timestamps with a syntax +>> +of: +>> + +>> + .. +>> + +>> +Each timestamp is a number representing the number of seconds since +>> +1970\-01\-01 00:00:00 UTC. +>> + +>> In addition to individual terms, multiple terms can be +>> combined with Boolean operators ( +>> .BR and ", " or ", " not +>> @@ -117,20 +139,121 @@ operators, but will have to be protected from interpretation by the +>> shell, (such as by putting quotation marks around any parenthesized +>> expression). +>> +>> -Finally, results can be restricted to only messages within a +>> -particular time range, (based on the Date: header) with a syntax of: +>> +.SH DATE AND TIME SEARCH +>> +>> - .. +>> +This is a non-exhaustive description of the date and time search with +>> +some pseudo notation. Most of the constructs can be mixed freely, and +>> +in any order, but the same absolute date or time can't be expressed +>> +twice. +> +> I'm not sure what the end of this sentence means, though I assume it's +> related to the restrictions on repeated absolute components. It would +> also be nice to give a broader view of the syntax here. Maybe, +> +> notmuch understands a variety of standard and natural ways of +> expressing dates and times, both in absolute terms ("2012-10-24") and +> in relative terms ("yesterday"). Any number of relative terms can be +> combined ("1 hour 25 minutes") and an absolute date/time can be +> combined with relative terms to further adjust it. A non-exhaustive +> description of the syntax supported for absolute and relative terms is +> given below. +> +>> +>> -Each timestamp is a number representing the number of seconds since +>> -1970\-01\-01 00:00:00 UTC. This is not the most convenient means of +>> -expressing date ranges, but until notmuch is fixed to accept a more +>> -convenient form, one can use the date program to construct +>> -timestamps. For example, with the bash shell the following syntax would +>> -specify a date range to return messages from 2009\-10\-01 until the +>> -current time: +>> - +>> - $(date +%s \-d 2009\-10\-01)..$(date +%s) +>> +.RS 4 +>> +.TP 4 +>> +.B The range expression +>> + +>> +date:.. +>> + +>> +The above expression restricts the results to only messages from +>> + to , based on the Date: header. +>> + +>> +If or describes time at an accuracy of days or less, +>> +the date/time is rounded, towards past for and towards future +>> +for , to be inclusive. For example, date:january..february +> +> The accuracy doesn't seem to have have anything to do with days; if I +> say "date:1hour..1hour" I get a span of an hour. Describing it as +> rounding also seems like it could be confusing to someone who hasn't +> thought a lot about this (though, as someone who has though a lot +> about this, I could be wrong). What about something like, +> +> and can describe imprecise times, such as "yesterday". +> In this case, is taken as the earliest time it could describe +> (the beginning of yesterday) and is taken as the latest time +> it could describe (the end of yesterday). Similarly, +> date:january..february matches from the beginning of January to the +> end of February. +> +>> +matches from the beginning of January until the end of +>> +February. Similarly, date:yesterday..yesterday matches from the +>> +beginning of yesterday until the end of yesterday. +>> + +>> +Open-ended ranges are supported (since Xapian 1.2.1), i.e. it's +>> +possible to specify date:.. or date:.. to not limit the +>> +start or end time, respectively. Unfortunately, pre-1.2.1 Xapian does +> +> No need for the "Unfortunately". +> +>> +not report an error on open ended ranges, but it does not work as +>> +expected either. +>> + +>> +Xapian does not support spaces in range expressions. You can replace +> +> The man pages essentially don't reference Xapian and the fact that we +> use Xapian is transparent to the uninterested user. Maybe just +> "Currently, we do not support spaces ..."? Or "Due to technical +> limitations, we do not currently support spaces ..." if you want to +> convey that we feel the user's pain but it's actually hard to fix. +> +>> +the spaces with '_', or (in most cases) '-', or (in some cases) leave +>> +the spaces out altogether. +> +> Maybe add "Examples in this man page use spaces for clarity."? It's +> unfortunate that this rather critical piece of information is buried +> in the middle of a subsection of the man page. I wonder if it should +> at least go before the previous paragraph? We are going to get so +> many people asking why their date searches don't work... +> +>> + +>> +Entering date:expr without ".." (for example date:yesterday) won't +>> +work, as it's not interpreted as a range expression at all. You can +>> +achieve the expected result by duplicating the expr both sides of ".." +>> +(for example date:yesterday..yesterday). +>> +.RE +>> + +>> +.RS 4 +>> +.TP 4 +>> +.B Relative date and time +>> +[N|number] (years|months|weeks|days|hours|hrs|minutes|mins|seconds|secs) [...] +>> + +>> +All refer to past, can be repeated and will be accumulated. +>> + +>> +Units can be abbreviated to any length, with the otherwise ambiguous +>> +single m being m for minutes and M for months. +>> + +>> +Number multiplier can also be written out one, two, ..., ten, dozen, +> +> This is the only use of "multiplier". I think it would be fine to +> just say "the number". +> +>> +hundred. As special cases last means one ("last week") and this means +>> +zero ("this month"). +> +> Maybe, "Additionally, the unit may be preceded by "last" or "this" +> (e.g., "last week" or "this month")."? +> +>> + +>> +When combined with absolute date and time, the relative date and time +>> +specification will be relative from the specified absolute date and +>> +time. +>> + +>> +Examples: 5M2d, two weeks +>> +.RE +>> + +>> +.RS 4 +>> +.TP 4 +>> +.B Supported time formats +> +> Supported absolute time formats? +> +>> +H[H]:MM[:SS] [(am|a.m.|pm|p.m.)] +>> + +>> +H[H] (am|a.m.|pm|p.m.) +>> + +>> +HHMMSS +>> + +>> +now +>> + +>> +noon +>> + +>> +midnight +>> + +>> +Examples: 17:05, 5pm +>> +.RE +>> + +>> +.RS 4 +>> +.TP 4 +>> +.B Supported date formats +> +> Supported absolute date formats? +> +>> +YYYY-MM[-DD] +>> + +>> +DD-MM[-[YY]YY] +>> + +>> +MM-YYYY +>> + +>> +M[M]/D[D][/[YY]YY] +>> + +>> +M[M]/YYYY +>> + +>> +D[D].M[M][.[YY]YY] +>> + +>> +D[D][(st|nd|rd|th)] Mon[thname] [YYYY] +>> + +>> +Mon[thname] D[D][(st|nd|rd|th)] [YYYY] +>> + +>> +Wee[kday] +>> + +>> +Month names can be abbreviated at three or more characters. +>> + +>> +Weekday names can be abbreviated at three or more characters. +>> + +>> +Examples: 2012-07-31, 31-07-2012, 7/31/2012, August 3 +>> +.RE +>> + +>> +.RS 4 +>> +.TP 4 +>> +.B Time zones +>> +(+|-)HH:MM +>> + +>> +(+|-)HH[MM] +>> + +>> +Some time zone codes, e.g. UTC, EET. +>> +.RE +>> +>> .SH SEE ALSO +>>