date:20120925

Re: bug related to ical

2012-09-25 Thread Tomi Ollila

On Wed, Sep 26 2012, Aaron Ecay wrote:

> The problem is in the ‘notmuch-show-insert-part-text/calendar’
> function.  The call to ‘icalendar--convert-ical-to-diary’ does not
> create a buffer visiting the temp file, so the call to ‘set-buffer’
> fails.  The following patch fixes the problem.
>
> The ical->diary conversion also doesn’t seem to work – the calendar
> attachment shows up as an empty part – but I guess that’s a separate
> issue (and not addressed by the patch).
>
> I guess that part insertion handlers should be called inside a
> ‘condition-case’, so that an error inside of one can be recovered from,
> and doesn’t entirely derail the insertion of the messages in the buffer.
> (I actually made this patch because I was so annoyed that Olivier’s
> buggy test attachment made it impossible for me to read Tomi’s reply.)

My reply was:

--8<8<8<8<8<8<8<8<8<--
   Hi

   I am "top-posting" as the content is not from Olivier's mail
   id:"87d31artti@inf-8657.int-evry.fr" but from my email
   id:"m2ipb2tjl8@guru.guru-group.fi"...

   For some reason notmuch emacs client references to my email instead
   of Olivier's when pressing 'V', any of the stash commands, reply or
   so on. Maybe that has something to do accessing the ical content
   (i.e. emacs client access the ical part from wrong message).

   Do others experience the same behaviour ?

   Tomi
--8<8<8<8<8<8<8<8<8<--

When I hand-applied Aaron's patch and re-evaluated 
(defun notmuch-show-insert-part-text/calendar ...) and reopened
this thread those things I mentioned above started to work OK :)

Aaron: could you provide the patch in format suitable for git-am
so it could be easily applied (and hopefully quickly, provided
that we get reviewers to look at it immediately :)

Tomi

>
> - cut here -
>
> diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
> index ce5ea6f..4c89d7e 100644
> --- i/emacs/notmuch-show.el
> +++ w/emacs/notmuch-show.el
> @@ -746,7 +746,7 @@ message at DEPTH in the current thread."
> (icalendar--convert-ical-to-diary
>  (icalendar--read-element nil nil)
>  file t)
> -   (set-buffer (get-file-buffer file))
> +   (set-buffer (find-file-noselect file))
> (setq result (buffer-substring (point-min) (point-max)))
> (set-buffer-modified-p nil)
> (kill-buffer (current-buffer))
>
> - cut here -
>
> -- 
> Aaron Ecay
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

2012-09-25 Thread Aaron Ecay

The problem is in the ‘notmuch-show-insert-part-text/calendar’
function.  The call to ‘icalendar--convert-ical-to-diary’ does not
create a buffer visiting the temp file, so the call to ‘set-buffer’
fails.  The following patch fixes the problem.

The ical->diary conversion also doesn’t seem to work – the calendar
attachment shows up as an empty part – but I guess that’s a separate
issue (and not addressed by the patch).

I guess that part insertion handlers should be called inside a
‘condition-case’, so that an error inside of one can be recovered from,
and doesn’t entirely derail the insertion of the messages in the buffer.
(I actually made this patch because I was so annoyed that Olivier’s
buggy test attachment made it impossible for me to read Tomi’s reply.)

- cut here -

diff --git i/emacs/notmuch-show.el w/emacs/notmuch-show.el
index ce5ea6f..4c89d7e 100644
--- i/emacs/notmuch-show.el
+++ w/emacs/notmuch-show.el
@@ -746,7 +746,7 @@ message at DEPTH in the current thread."
  (icalendar--convert-ical-to-diary
   (icalendar--read-element nil nil)
   file t)
- (set-buffer (get-file-buffer file))
+ (set-buffer (find-file-noselect file))
  (setq result (buffer-substring (point-min) (point-max)))
  (set-buffer-modified-p nil)
  (kill-buffer (current-buffer))

- cut here -

-- 
Aaron Ecay
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

2012-09-25 Thread Tomi Ollila

Hi

I am "top-posting" as the content is not from Olivier's mail
id:"87d31artti@inf-8657.int-evry.fr" but from my email
id:"m2ipb2tjl8@guru.guru-group.fi"...

For some reason notmuch emacs client references to my email instead
of Olivier's when pressing 'V', any of the stash commands, reply or
so on. Maybe that has something to do accessing the ical content
(i.e. emacs client access the ical part from wrong message).

Do others experience the same behaviour ?

Tomi



> On Tue, Sep 25 2012, Olivier Berger  wrote:
>
>> Hi.
>>
>> I didn't seem to find any followup.
>>
>> I'm experiencing a similar problem... Anyone with hints on how to solve
>> this ?
>
> Can either of you provide an email file that triggers this problem
> for others to test ?
>
> Tomi
>
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> Robert Horn  writes:
>>
>>> I've noticed a problem related to handling of ical attachments.  I'm
>>> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
>>> troubleshooting.
>>>
>>> The problem arises with emails from Concur that include an ical
>>> attachment being viewed with the notmuch message viewer.  The problems
>>> are:
>>>  1. When opening the email there is sometimes the following mesage and
>>>  error in Emacs message buffer:
>>>   Converting icalendar...done
>>>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>>>
>>>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>>>  Others work, like "m", and "q".
>>>
>>>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>>>  created but they are zero length.
>>>
>>> This is related to the ical attachment.  When I editted one of the emails to
>>> remove the attachment, the problem went away.  I suspect it is related
>>> to the attachments being base64 encoded.  The header of the mime
>>> attachment shows:
>>>
>>> Content-Type: application/octet-stream;
>>> name="ConcurCalendarEntry.ics"
>>> Content-Transfer-Encoding: base64
>>> Content-Disposition: attachment;
>>> filename="ConcurCalendarEntry.ics"
>>>
>>> The encoding is correct.  The attachment decodes and looks right.  With
>>> some details obscured the attachment contains:
>>>
>>> BEGIN:VCALENDAR
>>> VERSION:2.0
>>> METHOD:PUBLISH
>>> BEGIN:VEVENT
>>> DTSTART:properly-formatted
>>> DTEND:properly-formatted
>>> DTSTAMP:properly-formatted
>>> LOCATION:
>>> SUMMARY:Concur Travel Itinerary
>>> DESCRIPTION:Lots of stuff
>>>  with about 80 lines of description. All indented properly.
>>> UID:properly-formatted
>>> PRIORITY:3
>>> TRANSP:TRANSPARENT
>>> END:VEVENT
>>> END:VCALENDAR
>>>
>>> I can live without the ics files, so fixing this is not a priority for
>>> me.  If there is someone interested in figuring this out, I've saved an
>>> email and can answer questions.  I got lost trying to follow the lisp
>>> code paths for attachments, so I'm not sure whether it's the text or the
>>> base64 that is being handed off to icalendar.
>>>
>>> R Horn
>>> rjh...@alum.mit.edu
>>
>> -- 
>> Olivier BERGER 
>> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
>> Ingenieur Recherche - Dept INF
>> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>>
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

On splitting threads - Was: Re: Combining threads

2012-09-25 Thread Olivier Berger

Hi.

Carl Worth  writes:

> On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson  
> wrote:
>> Sometimes I get email from people with broken email clients that seem to
>> break threading.  I remember that sup had a method of combining two threads
>> into one.  Does notmuch have a similar feature?  Is it even possible to
>> force it to glue two threads together and treat them as one?
>

>> The bigger problem is that as soon as we have an operation to join
>> threads, people are going to need an operation to split threads. (And
>> some people want this already for cases where people reply when they
>> should have composed a new message.)
>>

Also in the context of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699, I should say I'd
welcome a thread split feature for such cases too.

FWIW, hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Provide an option to make thread summaries keep initial subject

2012-09-25 Thread Olivier Berger

Hi.

Whenever a participant changes the subject in the middle of a thread,
the summary reported by notmuch search will change.

However, the result is that some mails tend to "disappear" from search
results, when (bad) participants reply instead of composing a new mail,
and change a subject (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699 for more details
on that problem, and a discussion). Of course, they're still there, but
their subject being masked, one may then grep or C-s for a particular
subject and miss them.

I think it would be interesting to allow notmuch to potentially keep the
original subject and not the most recent one for the thread summaries.

What do you think ?

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

bug related to ical

2012-09-25 Thread Olivier Berger

Hi.

Here's a mail which exhibits the problem, for instance.

Best regards,

Tomi Ollila  writes:

> On Tue, Sep 25 2012, Olivier Berger  wrote:
>
>> Hi.
>>
>> I didn't seem to find any followup.
>>
>> I'm experiencing a similar problem... Anyone with hints on how to solve
>> this ?
>
> Can either of you provide an email file that triggers this problem
> for others to test ?
>
> Tomi
>


-- next part --
An embedded message was scrubbed...
From: olivier.ber...@it-sudparis.eu
Subject: Fw: Forward this e-mail to the presenters of the Event "OSLC Community 
Webcast: Eclipse Lyo Perl Modules for OSLC (A mini-cast 3-pack)"
Date: Mon, 24 Sep 2012 09:33:37 -0400
Size: 9056
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120925/8629ea5f/attachment.mht>
-- next part --


-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Provide an option to make thread summaries keep initial subject

2012-09-25 Thread Austin Clements

Quoth Olivier Berger on Sep 25 at  6:03 pm:
> Hi.
> 
> Whenever a participant changes the subject in the middle of a thread,
> the summary reported by notmuch search will change.
> 
> However, the result is that some mails tend to "disappear" from search
> results, when (bad) participants reply instead of composing a new mail,
> and change a subject (see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699 for more details
> on that problem, and a discussion). Of course, they're still there, but
> their subject being masked, one may then grep or C-s for a particular
> subject and miss them.
> 
> I think it would be interesting to allow notmuch to potentially keep the
> original subject and not the most recent one for the thread summaries.
> 
> What do you think ?

I think this would be fantastic.  I've proposed unconditionally
showing the earliest subject before and it seems that people who
correspond mostly with those who have good threading etiquette would
prefer this change, but those who correspond with more people who use
'reply' like an address book prefer the current behavior.

Another option, which I'd like to experiment with but haven't found
the time, is to show *all* distinct subjects for matched messages in a
thread (modulo "Re:", etc) in the summary buffer, probably on multiple
lines.  Since most threads only have a single unique subject, they
would appear just as they do now, but it would be clear when someone
(or something, like git) changed the subject mid-thread.  This
approach would be far more robust while retaining good usability, but
it would require more code than just changing our subject-picking
heuristic.

bug related to ical

2012-09-25 Thread Tomi Ollila

On Tue, Sep 25 2012, Olivier Berger  wrote:

> Hi.
>
> I didn't seem to find any followup.
>
> I'm experiencing a similar problem... Anyone with hints on how to solve
> this ?

Can either of you provide an email file that triggers this problem
for others to test ?

Tomi

>
> Thanks in advance.
>
> Best regards,
>
> Robert Horn  writes:
>
>> I've noticed a problem related to handling of ical attachments.  I'm
>> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
>> troubleshooting.
>>
>> The problem arises with emails from Concur that include an ical
>> attachment being viewed with the notmuch message viewer.  The problems
>> are:
>>  1. When opening the email there is sometimes the following mesage and
>>  error in Emacs message buffer:
>>   Converting icalendar...done
>>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>>
>>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>>  Others work, like "m", and "q".
>>
>>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>>  created but they are zero length.
>>
>> This is related to the ical attachment.  When I editted one of the emails to
>> remove the attachment, the problem went away.  I suspect it is related
>> to the attachments being base64 encoded.  The header of the mime
>> attachment shows:
>>
>> Content-Type: application/octet-stream;
>>  name="ConcurCalendarEntry.ics"
>> Content-Transfer-Encoding: base64
>> Content-Disposition: attachment;
>>  filename="ConcurCalendarEntry.ics"
>>
>> The encoding is correct.  The attachment decodes and looks right.  With
>> some details obscured the attachment contains:
>>
>> BEGIN:VCALENDAR
>> VERSION:2.0
>> METHOD:PUBLISH
>> BEGIN:VEVENT
>> DTSTART:properly-formatted
>> DTEND:properly-formatted
>> DTSTAMP:properly-formatted
>> LOCATION:
>> SUMMARY:Concur Travel Itinerary
>> DESCRIPTION:Lots of stuff
>>  with about 80 lines of description. All indented properly.
>> UID:properly-formatted
>> PRIORITY:3
>> TRANSP:TRANSPARENT
>> END:VEVENT
>> END:VCALENDAR
>>
>> I can live without the ics files, so fixing this is not a priority for
>> me.  If there is someone interested in figuring this out, I've saved an
>> email and can answer questions.  I got lost trying to follow the lisp
>> code paths for attachments, so I'm not sure whether it's the text or the
>> base64 that is being handed off to icalendar.
>>
>> R Horn
>> rjhorn at alum.mit.edu
>
> -- 
> Olivier BERGER 
> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v3 6/9] lib: add date range query support

2012-09-25 Thread Michal Sojka

On Thu, Sep 13 2012, Michal Nazarewicz wrote:
> On Wed, Sep 12 2012, Jani Nikula wrote:
>> Add a custom value range processor to enable date and time searches of
>> the form date:since..until, where "since" and "until" are expressions
>> understood by the previously added date/time parser, to restrict the
>> results to messages within a particular time range (based on the Date:
>> header).
>>
>> If "since" or "until" describes date/time at an accuracy of days or
>> less, the values are rounded according to the accuracy, towards past
>> for "since" and towards future for "until". For example,
>> date:november..yesterday would match from the beginning of November
>> until the end of yesterday. Expressions such as date:today..today
>> means since the beginning of today until the end of today.
>
> IMO this is totally unintuitive and not how the range should work.
> date:foo..bar should return messages whose date >= foo and < bar.  So
> for instance date:november..yesterday should return messages whose date
> is > 2012/11/01 00:00:00 and < 2012/09/12 00:00:00.  So to get
> yesterdays messages one would do: date:yesterday..today.

For me, date:monday..wednesday means all messages received on monday,
tuseday or wednesday. If I say Wednesday, I'm really interested in
Wednesday and not the day before Wednesday.

I'd also like to allow syntax like date:yesterday with the meaning all
messages sent yesterday. My idea how to implement this was described in
id:"87bovryqp0.fsf at steelpick.2x.cz". Unfortunately, I have no time to
implement it myself.

-Michal

[PATCH] test: Improve tests for the date/time parser module

2012-09-25 Thread Michal Sojka

This patch reworks date/time parser library test program to make it
easier to to write the actual tests. It also modifies the notmuch test
script and adds several new tests to it.

The INPUT file for the test contains both the dates to be parsed as well
as the "expected" results. The test program outputs the results in the
same format and replaces expected results with real results. Currently,
the "expected" results in the INPUT file correspond to the real results,
so the test passes. Some results are, however, different from what I
would expect - this is mentioned in the comments after '#'.

This patch applies on top of Jani's patchset.
---
It can be seen that there are several errors and unexpected results.
As I've already written, I'm not sure that the approach taken by this
library is the right one. I tend to agree with mina86, that using a
more systematic approach (such as bison) would be beneficial.

This is however not to say to throw this patchset away. Either Jani
will be able to fix all the corner cases. Or we can work together to
develop a better solution - add support for ranges to the bison
parser.

-Michal

diff --git a/test/Makefile.local b/test/Makefile.local
index 9ae130a..b9105c7 100644
--- a/test/Makefile.local
+++ b/test/Makefile.local
@@ -20,7 +20,7 @@ $(dir)/symbol-test: $(dir)/symbol-test.o
$(call quiet,CXX) $^ -o $@ -Llib -lnotmuch $(XAPIAN_LDFLAGS)

 $(dir)/parse-time: $(dir)/parse-time.o parse-time-string/parse-time-string.o
-   $(call quiet,CC) $^ -o $@
+   $(call quiet,CC) $^ -o $@ -lrt

 .PHONY: test check

diff --git a/test/parse-time-string b/test/parse-time-string
index 34b80d7..265437c 100755
--- a/test/parse-time-string
+++ b/test/parse-time-string
@@ -14,13 +14,48 @@ _parse_time ()
 ${TEST_DIRECTORY}/parse-time --format=%s "$*"
 }

-test_begin_subtest "date(1) default format without TZ code"
-test_expect_equal "$(_parse_time Fri Aug 3 23:06:06 2012)" "$(_date Fri Aug 3 
23:06:06 2012)"
+test_begin_subtest "Date parser tests"
+cat < INPUT
+now  -> Tue Jan 11 11:11:00 + 2011
+2010-1-1 -> parse_time_string() error: 5
+Jan 2-> Sat Jan 02 11:11:00 + 2010   # Why 2010?
+Mon  -> Mon Jan 10 11:11:00 + 2011
+last Friday  -> parse_time_string() error: 4
+2 hours ago  -> parse_time_string() error: 1
+last month   -> Sat Dec 11 11:11:00 + 2010
+month ago-> parse_time_string() error: 1
+8am  -> Tue Jan 11 08:00:00 + 2011
+9:15 -> Tue Jan 11 09:15:00 + 2011
+12:34-> Tue Jan 11 12:34:00 + 2011
+monday   -> Mon Jan 10 11:11:00 + 2011
+yesterday-> Mon Jan 10 11:11:00 + 2011
+tomorrow -> parse_time_string() error: 1
+ -> Tue Jan 11 11:11:00 + 2011 # Shouldn't empty string return 
an error???

-test_begin_subtest "date(1) --rfc-2822 format"
-test_expect_equal "$(_parse_time Fri, 03 Aug 2012 23:07:46 +0100)" "$(_date 
Fri, 03 Aug 2012 23:07:46 +0100)"
+Aug 3 23:06:06 2012 -> Fri Aug 03 23:06:06 + 2012 # date(1) 
default format without TZ code
+Fri, 03 Aug 2012 23:07:46 +0100 -> Fri Aug 03 22:07:46 + 2012 # rfc-2822
+2012-08-03 23:09:37+03:00   -> Fri Aug 03 20:09:37 + 2012 # rfc-3339 
seconds

-test_begin_subtest "date(1) --rfc=3339=seconds format"
-test_expect_equal "$(_parse_time 2012-08-03 23:09:37+03:00)" "$(_date 
2012-08-03 23:09:37+03:00)"
+10s   -> Tue Jan 11 11:10:50 + 2011
+19701223s -> Wed Dec 23 11:10:59 + 1970 # Surprising - number is 
parsed as date and 's' as '1 second'
+19701223  -> Wed Dec 23 11:11:00 + 1970
+
+19701223 +0100 -> Wed Dec 23 11:11:00 + 1970 # Timezone is ignored without 
an error
+
+today ^-> Wed Jan 12 00:00:00 + 2011 # This should be 11 23:59:59
+today v-> Tue Jan 11 00:00:00 + 2011
+
+thisweek ^-> Sun Jan 16 00:00:00 + 2011  # This should be Sunday 23:59:59
+thisweek v-> Sun Jan 09 00:00:00 + 2011  # This should be Monday 00:00:00
+
+two months ago-> parse_time_string() error: 1 # Comments in the code suggest 
that this is supported
+two months -> Thu Nov 11 11:11:00 + 2010
+
+1348569850 -> parse_time_string() error: 4 # Seconds since epoch not yet 
supported? Backward compatibility in notmuch???
+10 -> parse_time_string() error: 4 # Seconds since epoch?
+EOF
+
+${TEST_DIRECTORY}/parse-time --now="Tue Jan 11 11:11:00 + 2011" < INPUT > 
OUTPUT
+test_expect_equal_file INPUT OUTPUT

 test_done
diff --git a/test/parse-time.c b/test/parse-time.c
index b4de76b..0415f49 100644
--- a/test/parse-time.c
+++ b/test/parse-time.c
@@ -18,59 +18,47 @@
  * Author: Jani Nikula 
  */

+
+#define _XOPEN_SOURCE 500   /* for strptime() and snprintf() */
 #include 
 #include 
 #include 
 #include 
+#include 

 #include "parse-time-string.h"

-/*
- * concat argv[start]...argv[end - 1], separating them by a single
- * space, to a malloced string
- */
-static char *
-concat_args (int start, int end, char *argv[])
-{
-int i;
-size_t len = 1;
-char

[PATCH v3 2/9] parse-time-string: add a date/time parser to notmuch

2012-09-25 Thread Michal Sojka

Hello Jani,

On Wed, Sep 12 2012, Jani Nikula wrote:
> Add a date/time parser to notmuch, to be used for adding date range
> query support for notmuch lib later on. Add the parser to a directory
> of its own to make it independent of the rest of the notmuch code
> base.

First of all, thank you very much for pushing this towards mainline.
This is definitely one of the features I miss in notmuch most.

Some comments below.

>
> Signed-off-by: Jani Nikula 
> ---
>  Makefile  |2 +-
>  parse-time-string/Makefile|5 +
>  parse-time-string/Makefile.local  |   12 +
>  parse-time-string/README  |9 +
>  parse-time-string/parse-time-string.c | 1484 
> +
>  parse-time-string/parse-time-string.h |   95 +++
>  6 files changed, 1606 insertions(+), 1 deletion(-)
>  create mode 100644 parse-time-string/Makefile
>  create mode 100644 parse-time-string/Makefile.local
>  create mode 100644 parse-time-string/README
>  create mode 100644 parse-time-string/parse-time-string.c
>  create mode 100644 parse-time-string/parse-time-string.h
>
> diff --git a/Makefile b/Makefile
> index e5e2e3a..bb9c316 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3,7 +3,7 @@
>  all:
>
>  # List all subdirectories here. Each contains its own Makefile.local
> -subdirs = compat completion emacs lib man util test
> +subdirs = compat completion emacs lib man parse-time-string util test
>
>  # We make all targets depend on the Makefiles themselves.
>  global_deps = Makefile Makefile.config Makefile.local \
> diff --git a/parse-time-string/Makefile b/parse-time-string/Makefile
> new file mode 100644
> index 000..fa25832
> --- /dev/null
> +++ b/parse-time-string/Makefile
> @@ -0,0 +1,5 @@
> +all:
> + $(MAKE) -C .. all
> +
> +.DEFAULT:
> + $(MAKE) -C .. $@
> diff --git a/parse-time-string/Makefile.local 
> b/parse-time-string/Makefile.local
> new file mode 100644
> index 000..53534f3
> --- /dev/null
> +++ b/parse-time-string/Makefile.local
> @@ -0,0 +1,12 @@
> +dir := parse-time-string
> +extra_cflags += -I$(srcdir)/$(dir)
> +
> +libparse-time-string_c_srcs := $(dir)/parse-time-string.c
> +
> +libparse-time-string_modules := $(libparse-time-string_c_srcs:.c=.o)
> +
> +$(dir)/libparse-time-string.a: $(libparse-time-string_modules)
> + $(call quiet,AR) rcs $@ $^
> +
> +SRCS := $(SRCS) $(libparse-time-string_c_srcs)
> +CLEAN := $(CLEAN) $(libparse-time-string_modules) 
> $(dir)/libparse-time-string.a
> diff --git a/parse-time-string/README b/parse-time-string/README
> new file mode 100644
> index 000..300ff1f
> --- /dev/null
> +++ b/parse-time-string/README
> @@ -0,0 +1,9 @@
> +PARSE TIME STRING
> +=
> +
> +parse_time_string() is a date/time parser originally written for
> +notmuch by Jani Nikula . However, there is nothing
> +notmuch specific in it, and it should be kept reusable for other
> +projects, and ready to be packaged on its own as needed. Please do not
> +add dependencies on or references to anything notmuch specific. The
> +parser should only depend on the C library.
> diff --git a/parse-time-string/parse-time-string.c 
> b/parse-time-string/parse-time-string.c
> new file mode 100644
> index 000..15cf686
> --- /dev/null
> +++ b/parse-time-string/parse-time-string.c
> @@ -0,0 +1,1484 @@
> +/*
> + * parse time string - user friendly date and time parser
> + * Copyright ? 2012 Jani Nikula
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation, either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + *
> + * Author: Jani Nikula 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "parse-time-string.h"
> +
> +/*
> + * IMPLEMENTATION DETAILS
> + *
> + * At a high level, the parsing is done in two phases: 1) actual
> + * parsing of the input string and storing the parsed data into
> + * 'struct state', and 2) processing of the data in 'struct state'
> + * according to current time (or provided reference time) and
> + * rounding. This is evident in the main entry point function
> + * parse_time_string().
> + *
> + * 1) The parsing phase - parse_input()
> + *
> + * Parsing is greedy and happens from left to right. The parsing is as
> + * unambiguous as possible; only unambiguous date/time formats are
> + * ac

bug related to ical

2012-09-25 Thread Olivier Berger

Hi.

I didn't seem to find any followup.

I'm experiencing a similar problem... Anyone with hints on how to solve
this ?

Thanks in advance.

Best regards,

Robert Horn  writes:

> I've noticed a problem related to handling of ical attachments.  I'm
> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
> troubleshooting.
>
> The problem arises with emails from Concur that include an ical
> attachment being viewed with the notmuch message viewer.  The problems
> are:
>  1. When opening the email there is sometimes the following mesage and
>  error in Emacs message buffer:
>   Converting icalendar...done
>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>
>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>  Others work, like "m", and "q".
>
>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>  created but they are zero length.
>
> This is related to the ical attachment.  When I editted one of the emails to
> remove the attachment, the problem went away.  I suspect it is related
> to the attachments being base64 encoded.  The header of the mime
> attachment shows:
>
> Content-Type: application/octet-stream;
>   name="ConcurCalendarEntry.ics"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>   filename="ConcurCalendarEntry.ics"
>
> The encoding is correct.  The attachment decodes and looks right.  With
> some details obscured the attachment contains:
>
> BEGIN:VCALENDAR
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VEVENT
> DTSTART:properly-formatted
> DTEND:properly-formatted
> DTSTAMP:properly-formatted
> LOCATION:
> SUMMARY:Concur Travel Itinerary
> DESCRIPTION:Lots of stuff
>  with about 80 lines of description. All indented properly.
> UID:properly-formatted
> PRIORITY:3
> TRANSP:TRANSPARENT
> END:VEVENT
> END:VCALENDAR
>
> I can live without the ics files, so fixing this is not a priority for
> me.  If there is someone interested in figuring this out, I've saved an
> email and can answer questions.  I got lost trying to follow the lisp
> code paths for attachments, so I'm not sure whether it's the text or the
> base64 that is being handed off to icalendar.
>
> R Horn
> rjhorn at alum.mit.edu

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: Provide an option to make thread summaries keep initial subject

2012-09-25 Thread Austin Clements

Quoth Olivier Berger on Sep 25 at  6:03 pm:
> Hi.
> 
> Whenever a participant changes the subject in the middle of a thread,
> the summary reported by notmuch search will change.
> 
> However, the result is that some mails tend to "disappear" from search
> results, when (bad) participants reply instead of composing a new mail,
> and change a subject (see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699 for more details
> on that problem, and a discussion). Of course, they're still there, but
> their subject being masked, one may then grep or C-s for a particular
> subject and miss them.
> 
> I think it would be interesting to allow notmuch to potentially keep the
> original subject and not the most recent one for the thread summaries.
> 
> What do you think ?

I think this would be fantastic.  I've proposed unconditionally
showing the earliest subject before and it seems that people who
correspond mostly with those who have good threading etiquette would
prefer this change, but those who correspond with more people who use
'reply' like an address book prefer the current behavior.

Another option, which I'd like to experiment with but haven't found
the time, is to show *all* distinct subjects for matched messages in a
thread (modulo "Re:", etc) in the summary buffer, probably on multiple
lines.  Since most threads only have a single unique subject, they
would appear just as they do now, but it would be clear when someone
(or something, like git) changed the subject mid-thread.  This
approach would be far more robust while retaining good usability, but
it would require more code than just changing our subject-picking
heuristic.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 4/6] Fix the COERCE_STATUS macro

2012-09-25 Thread Tomi Ollila

On Mon, Sep 24 2012, Austin Clements  wrote:

> Quoth Justus Winter on Sep 24 at  5:21 pm:
>> Fix the COERCE_STATUS macro to handle _internal_error being declared
>> as void function.
>> 
>> Note that the function _internal_error does not return. Evaluating to
>> NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler.
>> 
>> Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de>
>> ---
>>  lib/notmuch-private.h |   10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
>> index bfb4111..7a409f5 100644
>> --- a/lib/notmuch-private.h
>> +++ b/lib/notmuch-private.h
>> @@ -136,13 +136,17 @@ typedef enum _notmuch_private_status {
>>   * to or greater than NOTMUCH_STATUS_LAST_STATUS. (The idea here is
>>   * that the caller has previously handled any expected
>>   * notmuch_private_status_t values.)
>> + *
>> + * Note that the function _internal_error does not return. Evaluating
>> + * to NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler.
>>   */
>>  #define COERCE_STATUS(private_status, format, ...)  \
>>  ((private_status >= (notmuch_private_status_t) 
>> NOTMUCH_STATUS_LAST_STATUS)\
>>   ?  
>> \
>> - (notmuch_status_t) _internal_error (format " (%s).\n", \
>> - ##__VA_ARGS__, 
>> \
>> - __location__)  
>> \
>> + _internal_error (format " (%s).\n",\
>> +  ##__VA_ARGS__,
>> \
>> +  __location__),
>> \
>> + (notmuch_status_t) NOTMUCH_PRIVATE_STATUS_SUCCESS  
>> \
>
> Just a nit: why not simply NOTMUCH_STATUS_SUCCESS?
>
> Otherwise, this series LGTM.  No need to roll another version just for
> this comment.

I agree. LGTM.

>
>>   :  
>> \
>>   (notmuch_status_t) private_status)

nbook: a notmuch based address book written in python

2012-09-25 Thread Patrick Totzke

Hey Suvayu, welcome to notmuch!

I hope you are aware that there are already a few search based abook tools
around for notmuch (listed in the wiki, albeit hidden in the emacs docs):
http://notmuchmail.org/emacstips/#index14h2
I personally use nottoomuch-addresses.sh, which apparently does some advanced
caching voodoo for speed.

But to your tool; practice test:
I wasn't able to use wildcards or simply prefixes of names. This is essential
if you want to use it for tabcompleting contacts in a MUA.
The time lookups take seems to depend on how many matches there are:

---
time nbook Suvayu
1 unique email addresses found for `Suvayu'
fatkasuvayu+linux at gmail.com Suvayu Ali

nbook Suvayu  0.04s user 0.01s system 95% cpu 0.050 total
---
time nbook Justus
...

nbook Justus  0.21s user 0.07s system 11% cpu 2.484 total
---
And If I look for my own name, this takes over a minute,
eventually dying. This could be an issue with libnotmuch though.
Possibly, your algorithm takes very long and then reads from an initially
opened Database object again, which was invalidated by concurrent writes of 
other processes..

---
[~] time nbook Patrick 

Error opening /home/pazz/mail/gmail/[Google Mail].All 
Mail/cur/1330682270_0.12958.megatron,U=8766,FMD5=66ff6a8bc18a8a3ac4b311daa93d358a:2,S:
 Too many open files
Traceback (most recent call last):
  File "/home/pazz/bin/nbook", line 167, in 
  File "/home/pazz/bin/nbook", line 71, in __init__
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", line 
233, in get_header
notmuch.errors.NullPointerError
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in 
apport_excepthook
ImportError: No module named fileutils

Original exception was:
Traceback (most recent call last):
  File "/home/pazz/bin/nbook", line 167, in 
  File "/home/pazz/bin/nbook", line 71, in __init__
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", line 
233, in get_header
notmuch.errors.NullPointerError
nbook Patrick  3.20s user 5.47s system 12% cpu 1:11.65 total


Anyway, have fun hacking notmuch! If you are looking for a related project to 
bring in your python skills
I could think of one or two :D
Best,
/p

Re: bug related to ical

2012-09-25 Thread Olivier Berger

Hi.

Here's a mail which exhibits the problem, for instance.

Best regards,

Tomi Ollila  writes:

> On Tue, Sep 25 2012, Olivier Berger  wrote:
>
>> Hi.
>>
>> I didn't seem to find any followup.
>>
>> I'm experiencing a similar problem... Anyone with hints on how to solve
>> this ?
>
> Can either of you provide an email file that triggers this problem
> for others to test ?
>
> Tomi
>


--- Begin Message ---


Please find a calendar entry for the webcast attached.


(See attached file: iCalEvent.ics)

iCalEvent.ics
Description: Binary data
--- End Message ---


-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

On splitting threads - Was: Re: Combining threads

2012-09-25 Thread Olivier Berger

Hi.

Carl Worth  writes:

> On Fri, 12 Nov 2010 08:57:21 -0800, Scott Henson  
> wrote:
>> Sometimes I get email from people with broken email clients that seem to
>> break threading.  I remember that sup had a method of combining two threads
>> into one.  Does notmuch have a similar feature?  Is it even possible to
>> force it to glue two threads together and treat them as one?
>

>> The bigger problem is that as soon as we have an operation to join
>> threads, people are going to need an operation to split threads. (And
>> some people want this already for cases where people reply when they
>> should have composed a new message.)
>>

Also in the context of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699, I should say I'd
welcome a thread split feature for such cases too.

FWIW, hope this helps.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Provide an option to make thread summaries keep initial subject

2012-09-25 Thread Olivier Berger

Hi.

Whenever a participant changes the subject in the middle of a thread,
the summary reported by notmuch search will change.

However, the result is that some mails tend to "disappear" from search
results, when (bad) participants reply instead of composing a new mail,
and change a subject (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688699 for more details
on that problem, and a discussion). Of course, they're still there, but
their subject being masked, one may then grep or C-s for a particular
subject and miss them.

I think it would be interesting to allow notmuch to potentially keep the
original subject and not the most recent one for the thread summaries.

What do you think ?

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 6/9] lib: add date range query support

2012-09-25 Thread Michal Sojka

On Thu, Sep 13 2012, Michal Nazarewicz wrote:
> On Wed, Sep 12 2012, Jani Nikula wrote:
>> Add a custom value range processor to enable date and time searches of
>> the form date:since..until, where "since" and "until" are expressions
>> understood by the previously added date/time parser, to restrict the
>> results to messages within a particular time range (based on the Date:
>> header).
>>
>> If "since" or "until" describes date/time at an accuracy of days or
>> less, the values are rounded according to the accuracy, towards past
>> for "since" and towards future for "until". For example,
>> date:november..yesterday would match from the beginning of November
>> until the end of yesterday. Expressions such as date:today..today
>> means since the beginning of today until the end of today.
>
> IMO this is totally unintuitive and not how the range should work.
> date:foo..bar should return messages whose date >= foo and < bar.  So
> for instance date:november..yesterday should return messages whose date
> is > 2012/11/01 00:00:00 and < 2012/09/12 00:00:00.  So to get
> yesterdays messages one would do: date:yesterday..today.

For me, date:monday..wednesday means all messages received on monday,
tuseday or wednesday. If I say Wednesday, I'm really interested in
Wednesday and not the day before Wednesday.

I'd also like to allow syntax like date:yesterday with the meaning all
messages sent yesterday. My idea how to implement this was described in
id:"87bovryqp0@steelpick.2x.cz". Unfortunately, I have no time to
implement it myself.

-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] test: Improve tests for the date/time parser module

2012-09-25 Thread Michal Sojka

This patch reworks date/time parser library test program to make it
easier to to write the actual tests. It also modifies the notmuch test
script and adds several new tests to it.

The INPUT file for the test contains both the dates to be parsed as well
as the "expected" results. The test program outputs the results in the
same format and replaces expected results with real results. Currently,
the "expected" results in the INPUT file correspond to the real results,
so the test passes. Some results are, however, different from what I
would expect - this is mentioned in the comments after '#'.

This patch applies on top of Jani's patchset.
---
It can be seen that there are several errors and unexpected results.
As I've already written, I'm not sure that the approach taken by this
library is the right one. I tend to agree with mina86, that using a
more systematic approach (such as bison) would be beneficial.

This is however not to say to throw this patchset away. Either Jani
will be able to fix all the corner cases. Or we can work together to
develop a better solution - add support for ranges to the bison
parser.

-Michal

diff --git a/test/Makefile.local b/test/Makefile.local
index 9ae130a..b9105c7 100644
--- a/test/Makefile.local
+++ b/test/Makefile.local
@@ -20,7 +20,7 @@ $(dir)/symbol-test: $(dir)/symbol-test.o
$(call quiet,CXX) $^ -o $@ -Llib -lnotmuch $(XAPIAN_LDFLAGS)
 
 $(dir)/parse-time: $(dir)/parse-time.o parse-time-string/parse-time-string.o
-   $(call quiet,CC) $^ -o $@
+   $(call quiet,CC) $^ -o $@ -lrt
 
 .PHONY: test check
 
diff --git a/test/parse-time-string b/test/parse-time-string
index 34b80d7..265437c 100755
--- a/test/parse-time-string
+++ b/test/parse-time-string
@@ -14,13 +14,48 @@ _parse_time ()
 ${TEST_DIRECTORY}/parse-time --format=%s "$*"
 }
 
-test_begin_subtest "date(1) default format without TZ code"
-test_expect_equal "$(_parse_time Fri Aug 3 23:06:06 2012)" "$(_date Fri Aug 3 
23:06:06 2012)"
+test_begin_subtest "Date parser tests"
+cat < INPUT
+now  -> Tue Jan 11 11:11:00 + 2011
+2010-1-1 -> parse_time_string() error: 5
+Jan 2-> Sat Jan 02 11:11:00 + 2010   # Why 2010?
+Mon  -> Mon Jan 10 11:11:00 + 2011
+last Friday  -> parse_time_string() error: 4
+2 hours ago  -> parse_time_string() error: 1
+last month   -> Sat Dec 11 11:11:00 + 2010
+month ago-> parse_time_string() error: 1
+8am  -> Tue Jan 11 08:00:00 + 2011
+9:15 -> Tue Jan 11 09:15:00 + 2011
+12:34-> Tue Jan 11 12:34:00 + 2011
+monday   -> Mon Jan 10 11:11:00 + 2011
+yesterday-> Mon Jan 10 11:11:00 + 2011
+tomorrow -> parse_time_string() error: 1
+ -> Tue Jan 11 11:11:00 + 2011 # Shouldn't empty string return 
an error???
 
-test_begin_subtest "date(1) --rfc-2822 format"
-test_expect_equal "$(_parse_time Fri, 03 Aug 2012 23:07:46 +0100)" "$(_date 
Fri, 03 Aug 2012 23:07:46 +0100)"
+Aug 3 23:06:06 2012 -> Fri Aug 03 23:06:06 + 2012 # date(1) 
default format without TZ code
+Fri, 03 Aug 2012 23:07:46 +0100 -> Fri Aug 03 22:07:46 + 2012 # rfc-2822
+2012-08-03 23:09:37+03:00   -> Fri Aug 03 20:09:37 + 2012 # rfc-3339 
seconds
 
-test_begin_subtest "date(1) --rfc=3339=seconds format"
-test_expect_equal "$(_parse_time 2012-08-03 23:09:37+03:00)" "$(_date 
2012-08-03 23:09:37+03:00)"
+10s   -> Tue Jan 11 11:10:50 + 2011
+19701223s -> Wed Dec 23 11:10:59 + 1970 # Surprising - number is 
parsed as date and 's' as '1 second'
+19701223  -> Wed Dec 23 11:11:00 + 1970
+
+19701223 +0100 -> Wed Dec 23 11:11:00 + 1970 # Timezone is ignored without 
an error
+
+today ^-> Wed Jan 12 00:00:00 + 2011 # This should be 11 23:59:59
+today v-> Tue Jan 11 00:00:00 + 2011
+
+thisweek ^-> Sun Jan 16 00:00:00 + 2011  # This should be Sunday 23:59:59
+thisweek v-> Sun Jan 09 00:00:00 + 2011  # This should be Monday 00:00:00
+
+two months ago-> parse_time_string() error: 1 # Comments in the code suggest 
that this is supported
+two months -> Thu Nov 11 11:11:00 + 2010
+
+1348569850 -> parse_time_string() error: 4 # Seconds since epoch not yet 
supported? Backward compatibility in notmuch???
+10 -> parse_time_string() error: 4 # Seconds since epoch?
+EOF
+
+${TEST_DIRECTORY}/parse-time --now="Tue Jan 11 11:11:00 + 2011" < INPUT > 
OUTPUT
+test_expect_equal_file INPUT OUTPUT
 
 test_done
diff --git a/test/parse-time.c b/test/parse-time.c
index b4de76b..0415f49 100644
--- a/test/parse-time.c
+++ b/test/parse-time.c
@@ -18,59 +18,47 @@
  * Author: Jani Nikula 
  */
 
+
+#define _XOPEN_SOURCE 500   /* for strptime() and snprintf() */
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "parse-time-string.h"
 
-/*
- * concat argv[start]...argv[end - 1], separating them by a single
- * space, to a malloced string
- */
-static char *
-concat_args (int start, int end, char *argv[])
-{
-int i;
-size_t len = 1;

Re: bug related to ical

2012-09-25 Thread Tomi Ollila

On Tue, Sep 25 2012, Olivier Berger  wrote:

> Hi.
>
> I didn't seem to find any followup.
>
> I'm experiencing a similar problem... Anyone with hints on how to solve
> this ?

Can either of you provide an email file that triggers this problem
for others to test ?

Tomi

>
> Thanks in advance.
>
> Best regards,
>
> Robert Horn  writes:
>
>> I've noticed a problem related to handling of ical attachments.  I'm
>> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
>> troubleshooting.
>>
>> The problem arises with emails from Concur that include an ical
>> attachment being viewed with the notmuch message viewer.  The problems
>> are:
>>  1. When opening the email there is sometimes the following mesage and
>>  error in Emacs message buffer:
>>   Converting icalendar...done
>>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>>
>>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>>  Others work, like "m", and "q".
>>
>>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>>  created but they are zero length.
>>
>> This is related to the ical attachment.  When I editted one of the emails to
>> remove the attachment, the problem went away.  I suspect it is related
>> to the attachments being base64 encoded.  The header of the mime
>> attachment shows:
>>
>> Content-Type: application/octet-stream;
>>  name="ConcurCalendarEntry.ics"
>> Content-Transfer-Encoding: base64
>> Content-Disposition: attachment;
>>  filename="ConcurCalendarEntry.ics"
>>
>> The encoding is correct.  The attachment decodes and looks right.  With
>> some details obscured the attachment contains:
>>
>> BEGIN:VCALENDAR
>> VERSION:2.0
>> METHOD:PUBLISH
>> BEGIN:VEVENT
>> DTSTART:properly-formatted
>> DTEND:properly-formatted
>> DTSTAMP:properly-formatted
>> LOCATION:
>> SUMMARY:Concur Travel Itinerary
>> DESCRIPTION:Lots of stuff
>>  with about 80 lines of description. All indented properly.
>> UID:properly-formatted
>> PRIORITY:3
>> TRANSP:TRANSPARENT
>> END:VEVENT
>> END:VCALENDAR
>>
>> I can live without the ics files, so fixing this is not a priority for
>> me.  If there is someone interested in figuring this out, I've saved an
>> email and can answer questions.  I got lost trying to follow the lisp
>> code paths for attachments, so I'm not sure whether it's the text or the
>> base64 that is being handed off to icalendar.
>>
>> R Horn
>> rjh...@alum.mit.edu
>
> -- 
> Olivier BERGER 
> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
> Ingenieur Recherche - Dept INF
> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

2012-09-25 Thread Olivier Berger

Hi.

I didn't seem to find any followup.

I'm experiencing a similar problem... Anyone with hints on how to solve
this ?

Thanks in advance.

Best regards,

Robert Horn  writes:

> I've noticed a problem related to handling of ical attachments.  I'm
> using Notmuch 0.13 on Emacs 23.3.1.  I've done some basic
> troubleshooting.
>
> The problem arises with emails from Concur that include an ical
> attachment being viewed with the notmuch message viewer.  The problems
> are:
>  1. When opening the email there is sometimes the following mesage and
>  error in Emacs message buffer:
>   Converting icalendar...done
>   notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil
>
>  2. Some (not all) of the view commands fail, e.g. "v", "V", "w".
>  Others work, like "m", and "q".
>
>  3. Examination of the /tmp directory shows notmuch-ical temp files being
>  created but they are zero length.
>
> This is related to the ical attachment.  When I editted one of the emails to
> remove the attachment, the problem went away.  I suspect it is related
> to the attachments being base64 encoded.  The header of the mime
> attachment shows:
>
> Content-Type: application/octet-stream;
>   name="ConcurCalendarEntry.ics"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
>   filename="ConcurCalendarEntry.ics"
>
> The encoding is correct.  The attachment decodes and looks right.  With
> some details obscured the attachment contains:
>
> BEGIN:VCALENDAR
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VEVENT
> DTSTART:properly-formatted
> DTEND:properly-formatted
> DTSTAMP:properly-formatted
> LOCATION:
> SUMMARY:Concur Travel Itinerary
> DESCRIPTION:Lots of stuff
>  with about 80 lines of description. All indented properly.
> UID:properly-formatted
> PRIORITY:3
> TRANSP:TRANSPARENT
> END:VEVENT
> END:VCALENDAR
>
> I can live without the ics files, so fixing this is not a priority for
> me.  If there is someone interested in figuring this out, I've saved an
> email and can answer questions.  I got lost trying to follow the lisp
> code paths for attachments, so I'm not sure whether it's the text or the
> base64 that is being handed off to icalendar.
>
> R Horn
> rjh...@alum.mit.edu

-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: nbook: a notmuch based address book written in python

2012-09-25 Thread Patrick Totzke

Hey Suvayu, welcome to notmuch!

I hope you are aware that there are already a few search based abook tools
around for notmuch (listed in the wiki, albeit hidden in the emacs docs):
http://notmuchmail.org/emacstips/#index14h2
I personally use nottoomuch-addresses.sh, which apparently does some advanced
caching voodoo for speed.

But to your tool; practice test:
I wasn't able to use wildcards or simply prefixes of names. This is essential
if you want to use it for tabcompleting contacts in a MUA.
The time lookups take seems to depend on how many matches there are:

---
time nbook Suvayu
1 unique email addresses found for `Suvayu'
fatkasuvayu+li...@gmail.com Suvayu Ali

nbook Suvayu  0.04s user 0.01s system 95% cpu 0.050 total
---
time nbook Justus
...

nbook Justus  0.21s user 0.07s system 11% cpu 2.484 total
---
And If I look for my own name, this takes over a minute,
eventually dying. This could be an issue with libnotmuch though.
Possibly, your algorithm takes very long and then reads from an initially
opened Database object again, which was invalidated by concurrent writes of 
other processes..

---
[~] time nbook Patrick 

Error opening /home/pazz/mail/gmail/[Google Mail].All 
Mail/cur/1330682270_0.12958.megatron,U=8766,FMD5=66ff6a8bc18a8a3ac4b311daa93d358a:2,S:
 Too many open files
Traceback (most recent call last):
  File "/home/pazz/bin/nbook", line 167, in 
  File "/home/pazz/bin/nbook", line 71, in __init__
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", line 
233, in get_header
notmuch.errors.NullPointerError
Error in sys.excepthook:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 66, in 
apport_excepthook
ImportError: No module named fileutils

Original exception was:
Traceback (most recent call last):
  File "/home/pazz/bin/nbook", line 167, in 
  File "/home/pazz/bin/nbook", line 71, in __init__
  File "/home/pazz/.local/lib/python2.7/site-packages/notmuch/message.py", line 
233, in get_header
notmuch.errors.NullPointerError
nbook Patrick  3.20s user 5.47s system 12% cpu 1:11.65 total


Anyway, have fun hacking notmuch! If you are looking for a related project to 
bring in your python skills
I could think of one or two :D
Best,
/p
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 4/6] Fix the COERCE_STATUS macro

2012-09-25 Thread Tomi Ollila

On Mon, Sep 24 2012, Austin Clements  wrote:

> Quoth Justus Winter on Sep 24 at  5:21 pm:
>> Fix the COERCE_STATUS macro to handle _internal_error being declared
>> as void function.
>> 
>> Note that the function _internal_error does not return. Evaluating to
>> NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler.
>> 
>> Signed-off-by: Justus Winter <4win...@informatik.uni-hamburg.de>
>> ---
>>  lib/notmuch-private.h |   10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>> 
>> diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
>> index bfb4111..7a409f5 100644
>> --- a/lib/notmuch-private.h
>> +++ b/lib/notmuch-private.h
>> @@ -136,13 +136,17 @@ typedef enum _notmuch_private_status {
>>   * to or greater than NOTMUCH_STATUS_LAST_STATUS. (The idea here is
>>   * that the caller has previously handled any expected
>>   * notmuch_private_status_t values.)
>> + *
>> + * Note that the function _internal_error does not return. Evaluating
>> + * to NOTMUCH_STATUS_SUCCESS is done purely to appease the compiler.
>>   */
>>  #define COERCE_STATUS(private_status, format, ...)  \
>>  ((private_status >= (notmuch_private_status_t) 
>> NOTMUCH_STATUS_LAST_STATUS)\
>>   ?  
>> \
>> - (notmuch_status_t) _internal_error (format " (%s).\n", \
>> - ##__VA_ARGS__, 
>> \
>> - __location__)  
>> \
>> + _internal_error (format " (%s).\n",\
>> +  ##__VA_ARGS__,
>> \
>> +  __location__),
>> \
>> + (notmuch_status_t) NOTMUCH_PRIVATE_STATUS_SUCCESS  
>> \
>
> Just a nit: why not simply NOTMUCH_STATUS_SUCCESS?
>
> Otherwise, this series LGTM.  No need to roll another version just for
> this comment.

I agree. LGTM.

>
>>   :  
>> \
>>   (notmuch_status_t) private_status)

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

nbook: a notmuch based address book written in python

2012-09-25 Thread Suvayu Ali

Hi,

(I'm not subscribed to the list, so please cc: me in your replies)

I am a new notmuch user.  I use it with mutt.  I wanted a Gmail like
address book, so I used the python bindings for notmuch to write a small
python program.  This is supposed to behave like abook.  Quality
standards permitting, I would like this to be included in the contrib
directory with notmuch.  I have tested it a little, but there could be
bugs lurking somewhere.  I have created a github repository[1], which
may be treated as upstream for this program.

This is my first serious python program, and the first time I'm
contributing something significant to an open source project.  So please
let me know if I have missed something.  Looking forward to your
feedback.

Cheers,

Footnotes:

[1] 

-- 
Suvayu

Open source is the future. It sets us free.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: bug related to ical

Re: bug related to ical

Re: bug related to ical

On splitting threads - Was: Re: Combining threads

Provide an option to make thread summaries keep initial subject

bug related to ical

Provide an option to make thread summaries keep initial subject

bug related to ical

[PATCH v3 6/9] lib: add date range query support

[PATCH] test: Improve tests for the date/time parser module

[PATCH v3 2/9] parse-time-string: add a date/time parser to notmuch

bug related to ical

Re: Provide an option to make thread summaries keep initial subject

[PATCH 4/6] Fix the COERCE_STATUS macro

nbook: a notmuch based address book written in python

Re: bug related to ical

On splitting threads - Was: Re: Combining threads

Provide an option to make thread summaries keep initial subject

Re: [PATCH v3 6/9] lib: add date range query support

[PATCH] test: Improve tests for the date/time parser module

Re: bug related to ical

Re: bug related to ical

Re: nbook: a notmuch based address book written in python

Re: [PATCH 4/6] Fix the COERCE_STATUS macro

nbook: a notmuch based address book written in python

25 matches

Site Navigation

Mail list logo

Footer information