Re: [RFC PATCH 0/2] natural language date range search

[Tomi Ollila]

On Sat, 25 Feb 2012 21:53:27 +0200, Jani Nikula  wrote:
> On Sat, 25 Feb 2012 17:05:44 +0200, Tomi Ollila  wrote:

[ ... ]

> > 
> > By seeing the thoughts thrown in IRC there seems to be plenty if things
> > to resolve until something like this is going to be available in stock
> > notmuch. In the meanwhile I provide some ideas into the soup; maybe
> > our collective mind can have some use of this.
> > 
> > 
> > Q: Could 'date:timestr' be converted to 'date:timestr..timestr' ?
> 
> AFAICT this would require the custom query parser.

So, maybe someday... :)

> > In this idea - means relative time and  absolute
> > time. The the time string consists of number and letter and assume
> > the above suggestion for date:timestr (<- == date:timestr..timestr)
> > Letters are s seconds  h hours  d days  w weeks  m months (more
> > useful than for minutes) and  y years.
> 
> I'll put it bluntly: show me the code! ;)

I would not have expected nothing less ;)

> I'll comment below how your examples can be expressed with working code
> in this series, just for comparison, and to show what can be done with
> this.

Great! Those features suits to my needs just fine; last day is most often
needed, then parhaps I jump to one week. 5w is good for ~one month. 
More "absolute" times (like last november / since last november) are so
seldomly needed that writing a bit more is not an issue :D

[ ... ]

> 
> BR,
> Jani.

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

[RFC PATCH 1/2] lib: add date/time parser

[Jani Nikula]

On Sun, 26 Feb 2012 08:45:22 +, Mark Walters  
wrote:
> 
> Hi I have not read all of this carefully but it looks very nice to
> me. It is pleasantly nice to read. 

Thank you!

> I have not looked through the create output function yet but have looked
> at most of the rest.

There are a few rough edges in the output part still, but as you've
perhaps noticed it's a completely separate stage from the parsing bit.

> My only concern (as mentioned on irc) is the question of
> internationalisation. I think most of the this can be done by allowing
> other keyword tables and that seems quite clean. Ideally I think the
> user would set which to localisation use in the config file and then the
> cli would pass that to the lib parser.

I think it might be possible to tweak the table and the keyword matching
in a way that makes the ordering in the table unimportant. The strings
themselves could contain information about the abbreviation points and
priority wrt same length matches, and those could be part of the
translation through gettext. And I don't think it would even bloat the
code much.

Assuming gettext would be the internationalization method of choice.

> I think it would be a shame to hold up this very useful functionality
> just because of these internationalisation concerns.

I agree but I'm heavily biased! ;)

> The code is fairly large but it is easy to read and I would imagine
> (excepting the internationalisation question) almost maintenance free.
> 
> On the actual code I have a small number of comments/queries below.

Replies to them inline, and fixes pushed to [1] along with some other
fixes and improvements.

BR,
Jani.


[1] http://gitorious.org/parse-time-string

> 
> Best wishes
> 
> Mark
> 
> On Mon, 20 Feb 2012 00:55:51 +0200, Jani Nikula  wrote:
> > Signed-off-by: Jani Nikula 
> > ---
> >  lib/Makefile.local  |1 +
> >  lib/parse-time-string.c | 1304 
> > +++
> >  lib/parse-time-string.h |   95 
> >  3 files changed, 1400 insertions(+), 0 deletions(-)
> >  create mode 100644 lib/parse-time-string.c
> >  create mode 100644 lib/parse-time-string.h
> > 
> > diff --git a/lib/Makefile.local b/lib/Makefile.local
> > index 54c4dea..803a284 100644
> > --- a/lib/Makefile.local
> > +++ b/lib/Makefile.local
> > @@ -53,6 +53,7 @@ libnotmuch_c_srcs =   \
> > $(dir)/libsha1.c\
> > $(dir)/message-file.c   \
> > $(dir)/messages.c   \
> > +   $(dir)/parse-time-string.c  \
> > $(dir)/sha1.c   \
> > $(dir)/tags.c
> >  
> > diff --git a/lib/parse-time-string.c b/lib/parse-time-string.c
> > new file mode 100644
> > index 000..59713dc
> > --- /dev/null
> > +++ b/lib/parse-time-string.c
> > @@ -0,0 +1,1304 @@
> > +/*
> > + * 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 
> > + */
> > +
> > +#ifndef PARSE_TIME_DEBUG
> > +#define NDEBUG /* for assert() */
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "parse-time-string.h"
> > +
> > +#define ARRAY_SIZE(a) (sizeof (a) / sizeof (a[0]))
> > +
> > +/* field indices in struct state tm, and set fields */
> > +enum field {
> > +/* keep SEC...YEAR in this order */
> > +TM_ABS_SEC,/* seconds */
> > +TM_ABS_MIN,/* minutes */
> > +TM_ABS_HOUR,   /* hours */
> > +TM_ABS_MDAY,   /* day of the month */
> > +TM_ABS_MON,/* month */
> > +TM_ABS_YEAR,   /* year */
> > +
> > +TM_ABS_WDAY,   /* day of the week. special: may be relative */
> > +TM_ABS_ISDST,  /* daylight saving time */
> > +
> > +TM_AMPM,   /* am vs. pm */
> > +TM_TZ, /* timezone in minutes */
> > +
> > +/* keep SEC...YEAR in this order */
> > +TM_REL_SEC,/* seconds relative to now */
> > +TM_REL_MIN,/* minutes ... */
> > +TM_REL_HOUR,   /* hours ... */
> > +TM_REL_DAY,/* days ... */
> > +TM_REL_MON,/* months ... */
> > +TM_REL_YEAR,   /* years ... */
> > +TM_REL_WE

Replacing my name/email with "me" (or similar) in author lists

[Daniel Schoepe]

On Sun, 26 Feb 2012 11:22:10 +, Patrick Totzke  wrote:
> > so it would seem more appropriate that this be done in the backend.
> I agree. I personally think this is a nice feature to have in all
> user interfaces to notmuch and therefore it makes sense to implement it once
> in the lib. Also because ~/.notmuch-config already contains a list of my 
> addresses
> and therefore should have all information needed.

I'm not sure if that's a good idea: A frontend might want to make this
configurable, for example to give the user the opportunity to disable it
(possibly to see to which of his mail adresses he used in that thread,
if they have different real name components). It might also get tricky
to distinguish between someone called "me" participating in the thread
and the user, which might be relevant for highlighting the latter case
differently, while it's rather easy for a frontend to do the
transformation itself.

At least it should not be done in the library, because it'd need to read
the user's addresses from configuration file which the library is not
supposed to access, as far as I understand.

Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120226/45ff9f78/attachment.pgp>

Replacing my name/email with "me" (or similar) in author lists

[Tom Prince]

On Sun, 26 Feb 2012 12:51:49 -0400, David Bremner  wrote:
> I have sometimes wondered about having another library layer making some
> of the current CLI functionality accessible to bindings. I'm not really
> sure of the pro's and con's of such approach. It would certainly be
> overkill for this one feature.

It is probably overkill for any one feature, but it does seem like
something useful to have. So maybe it would be worthwhile to create
for this one feature, even it it is overkill.

  Tom

Re: plans for 0.12

[Jameson Graef Rollins]

On Sat, 25 Feb 2012 10:27:02 -0400, David Bremner  wrote:
> It has also been some chatter that either (the next iteration of)
> 
>id:"1329296619-7463-1-git-send-email-markwalters1...@gmail.com" 
> 
> Should go in, or we should revert amdragon's exclude stuff. 
> 
> I don't have strong feelings either way, except it is somewhat late in
> the day for a large(ish) and complicated series.

If we go the revert route please only revert from the 0.12 release
branch.  I am using and enjoying this feature now, and would not like to
see further development of it stalled.  Thanks so much to those of you
who have been pushing on it.

jamie.


pgppE2XdYKlq7.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

plans for 0.12

[Jameson Graef Rollins]

On Sat, 25 Feb 2012 10:27:02 -0400, David Bremner  wrote:
> It has also been some chatter that either (the next iteration of)
> 
>id:"1329296619-7463-1-git-send-email-markwalters1009 at gmail.com" 
> 
> Should go in, or we should revert amdragon's exclude stuff. 
> 
> I don't have strong feelings either way, except it is somewhat late in
> the day for a large(ish) and complicated series.

If we go the revert route please only revert from the 0.12 release
branch.  I am using and enjoying this feature now, and would not like to
see further development of it stalled.  Thanks so much to those of you
who have been pushing on it.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120226/475ba90f/attachment.pgp>

Double decoded text/html parts (was: [PATCH] test: Add test for searching of uncommonly encoded messages)

[Serge Z]

This works:
w3m -o document_charset=windows-1251 test.html

It says that w3m should suppose windows-1251 encoding if no html-meta
content-type tag given.

Re: Replacing my name/email with "me" (or similar) in author lists

[Tom Prince]

On Sun, 26 Feb 2012 12:51:49 -0400, David Bremner  wrote:
> I have sometimes wondered about having another library layer making some
> of the current CLI functionality accessible to bindings. I'm not really
> sure of the pro's and con's of such approach. It would certainly be
> overkill for this one feature.

It is probably overkill for any one feature, but it does seem like
something useful to have. So maybe it would be worthwhile to create
for this one feature, even it it is overkill.

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

Replacing my name/email with "me" (or similar) in author lists

[David Bremner]

On Sun, 26 Feb 2012 17:41:04 +0100, Daniel Schoepe  
wrote:
> 
> At least it should not be done in the library, because it'd need to read
> the user's addresses from configuration file which the library is not
> supposed to access, as far as I understand.
> 

One can work around this by passing in the relevant configuration data,
but then it isn't clear how much of a win it is in code complexity.

I have sometimes wondered about having another library layer making some
of the current CLI functionality accessible to bindings. I'm not really
sure of the pro's and con's of such approach. It would certainly be
overkill for this one feature.

d

Replacing my name/email with "me" (or similar) in author lists

[Patrick Totzke]

Quoting Daniel (2012-02-25 16:34:15)
>From what I understand, at least the Python bindings deliver primarily author
>names (not addresses),

To clarify, `notmuch.Thread.get_authors` returns a comma separated list of the 
realname parts of all From-headers that occur in messages of this thread.

> so it would seem more appropriate that this be done in the backend.
I agree. I personally think this is a nice feature to have in all
user interfaces to notmuch and therefore it makes sense to implement it once
in the lib. Also because ~/.notmuch-config already contains a list of my 
addresses
and therefore should have all information needed.

Implementing this feature for alot in python is easily doable, by constructing
the authors list from the messages From headers directly, comparing
the address part with all known own addresses.
We will do so if the response here is all too negative or nobody is brave 
enough to
step forward and touch the lib in this respect.

If I'm not mistaken, the lib extracts the authors name from the From-header
of a message, which is indexed. Somewhere around line 248 in thread.cc,
this string is added to a list of names.

Cheers,
/p

Double decoded text/html parts (was: [PATCH] test: Add test for searching of uncommonly encoded messages)

[Michal Sojka]

On Sat, 25 Feb 2012, Serge Z wrote:
> 
> Hi!
> I've struck another problem:
> 
> I've got an html/text email with body encoded with cp1251.
> Its encoding is mentioned in both Content-type: email header and html 
> tag. So when the client tries to display it with external html2text converter,
> The message is decoded twice: first by client, second by html2text (I
> use w3m).

Right. After my analysis of the problem (see below) it seems there is no
trivial solution for this.

> As I understand, notmuch (while indexing this message) decodes it once and
> index it in the right way (though including html tags to index). But what if
> the message contains no "charset" option in Content-Type email header but
> contain  content-type tag with charset noted?

This should not happen. It violates RFC 2046, section 4.1.2.

> Should such message be considered as being composed wrong or it should
> be indexed with diving into html details (content-type)?

I don't think it's wrongly composed and it should be even correctly
indexed (with my patch). The problem is when you view such a message
with an external HTML viewer.

In my mailbox I can find two different types of text/html parts. First,
the parts that contain complete HTML document including all headers and
especially .
Such parts could be passed to external HTML viewer without any decoding
by notmuch.

The second type is text/html part that does not contain any HTML
headers. Passing such a part to an external HTML viewer undecoded would
require it to guess the correct charset from the content.

AFAIK Firefox users can set fallback charset (used for HTML documents
with unknown charset) in the preferences, but I don't know what other
browsers would do. In particular, do you know how w3m behaves when
charset is not specified?

In any way, if we want notmuch to do the right thing, we should analyze
the content of text/html parts and decide whether to decode the part or
not. Perhaps, a simple heuristic could be to search the content of the
part for strings "charset=" and "encoding=" and if any is found, notmuch
wouldn't decode that part. Otherwise it will decode it according to
Content-Type header.

As a curiosity, I found the following in one of my emails. Note that two
different encodings (iso-8859-2 and windows-1250) are specified at the
same time :) That's the reason why I think that fixing the problem won't
be trivial.

Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: 8bit


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>



Cheers,
-Michal

Re: Replacing my name/email with "me" (or similar) in author lists

[David Bremner]

On Sun, 26 Feb 2012 17:41:04 +0100, Daniel Schoepe  wrote:
> 
> At least it should not be done in the library, because it'd need to read
> the user's addresses from configuration file which the library is not
> supposed to access, as far as I understand.
> 

One can work around this by passing in the relevant configuration data,
but then it isn't clear how much of a win it is in code complexity.

I have sometimes wondered about having another library layer making some
of the current CLI functionality accessible to bindings. I'm not really
sure of the pro's and con's of such approach. It would certainly be
overkill for this one feature.

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

[RFC PATCH 1/2] lib: add date/time parser

[Mark Walters]

Hi I have not read all of this carefully but it looks very nice to
me. It is pleasantly nice to read. 

I have not looked through the create output function yet but have looked
at most of the rest.

My only concern (as mentioned on irc) is the question of
internationalisation. I think most of the this can be done by allowing
other keyword tables and that seems quite clean. Ideally I think the
user would set which to localisation use in the config file and then the
cli would pass that to the lib parser.

I think it would be a shame to hold up this very useful functionality
just because of these internationalisation concerns.

The code is fairly large but it is easy to read and I would imagine
(excepting the internationalisation question) almost maintenance free.

On the actual code I have a small number of comments/queries below.

Best wishes

Mark

On Mon, 20 Feb 2012 00:55:51 +0200, Jani Nikula  wrote:
> Signed-off-by: Jani Nikula 
> ---
>  lib/Makefile.local  |1 +
>  lib/parse-time-string.c | 1304 
> +++
>  lib/parse-time-string.h |   95 
>  3 files changed, 1400 insertions(+), 0 deletions(-)
>  create mode 100644 lib/parse-time-string.c
>  create mode 100644 lib/parse-time-string.h
> 
> diff --git a/lib/Makefile.local b/lib/Makefile.local
> index 54c4dea..803a284 100644
> --- a/lib/Makefile.local
> +++ b/lib/Makefile.local
> @@ -53,6 +53,7 @@ libnotmuch_c_srcs = \
>   $(dir)/libsha1.c\
>   $(dir)/message-file.c   \
>   $(dir)/messages.c   \
> + $(dir)/parse-time-string.c  \
>   $(dir)/sha1.c   \
>   $(dir)/tags.c
>  
> diff --git a/lib/parse-time-string.c b/lib/parse-time-string.c
> new file mode 100644
> index 000..59713dc
> --- /dev/null
> +++ b/lib/parse-time-string.c
> @@ -0,0 +1,1304 @@
> +/*
> + * 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 
> + */
> +
> +#ifndef PARSE_TIME_DEBUG
> +#define NDEBUG /* for assert() */
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "parse-time-string.h"
> +
> +#define ARRAY_SIZE(a) (sizeof (a) / sizeof (a[0]))
> +
> +/* field indices in struct state tm, and set fields */
> +enum field {
> +/* keep SEC...YEAR in this order */
> +TM_ABS_SEC,  /* seconds */
> +TM_ABS_MIN,  /* minutes */
> +TM_ABS_HOUR, /* hours */
> +TM_ABS_MDAY, /* day of the month */
> +TM_ABS_MON,  /* month */
> +TM_ABS_YEAR, /* year */
> +
> +TM_ABS_WDAY, /* day of the week. special: may be relative */
> +TM_ABS_ISDST,/* daylight saving time */
> +
> +TM_AMPM, /* am vs. pm */
> +TM_TZ,   /* timezone in minutes */
> +
> +/* keep SEC...YEAR in this order */
> +TM_REL_SEC,  /* seconds relative to now */
> +TM_REL_MIN,  /* minutes ... */
> +TM_REL_HOUR, /* hours ... */
> +TM_REL_DAY,  /* days ... */
> +TM_REL_MON,  /* months ... */
> +TM_REL_YEAR, /* years ... */
> +TM_REL_WEEK, /* weeks ... */
> +
> +TM_NONE, /* not a field */
> +
> +TM_SIZE = TM_NONE,
> +};
> +
> +enum field_set {
> +FIELD_UNSET,
> +FIELD_SET,
> +FIELD_NOW,
> +};
> +
> +static enum field
> +next_field (enum field field)
> +{
> +/* note: depends on the enum ordering */
> +return field < TM_ABS_YEAR ? field + 1 : TM_NONE;
> +}
> +
> +static enum field
> +abs_to_rel_field (enum field field)
> +{
> +assert (field <= TM_ABS_YEAR);
> +
> +/* note: depends on the enum ordering */
> +return field + (TM_REL_SEC - TM_ABS_SEC);
> +}
> +
> +/* get zero value for field */
> +static int
> +field_zero (enum field field)
> +{
> +if (field == TM_ABS_MDAY || field == TM_ABS_MON)
> + return 1;
> +else if (field == TM_ABS_YEAR)
> + return 1970;
> +else
> + return 0;
> +}
> +
> +struct state {
> +int tm[TM_SIZE]; /* parsed date and time */
> +enum field_set set[TM_SIZE]; /* set status of tm */
> +
> +enum field last_field;
> +char

Re: Replacing my name/email with "me" (or similar) in author lists

[Daniel Schoepe]

On Sun, 26 Feb 2012 11:22:10 +, Patrick Totzke 
 wrote:
> > so it would seem more appropriate that this be done in the backend.
> I agree. I personally think this is a nice feature to have in all
> user interfaces to notmuch and therefore it makes sense to implement it once
> in the lib. Also because ~/.notmuch-config already contains a list of my 
> addresses
> and therefore should have all information needed.

I'm not sure if that's a good idea: A frontend might want to make this
configurable, for example to give the user the opportunity to disable it
(possibly to see to which of his mail adresses he used in that thread,
if they have different real name components). It might also get tricky
to distinguish between someone called "me" participating in the thread
and the user, which might be relevant for highlighting the latter case
differently, while it's rather easy for a frontend to do the
transformation itself.

At least it should not be done in the library, because it'd need to read
the user's addresses from configuration file which the library is not
supposed to access, as far as I understand.

Cheers,
Daniel


pgpUCoO6A07CZ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

plans for 0.12

[Mark Walters]

On Sat, 25 Feb 2012 10:27:02 -0400, David Bremner  wrote:
> 
> I would like to start a freeze (i.e. merge master to release) for 0.12
> within the next week, say March 1 for an easy to remember date.
> 
> If you have suggestions for things that "should really go in", feel free
> to follow up. The main point here is bug fixes, or features which are
> there in a kindof half baked way.
> 
> Bug fix wise, I know about 
>   
>   id:"1330068983-4483-1-git-send-email-sojkam1 at fel.cvut.cz"
> 
> This could use some review.
> 
> It has also been some chatter that either (the next iteration of)
> 
>id:"1329296619-7463-1-git-send-email-markwalters1009 at gmail.com" 
> 
> Should go in, or we should revert amdragon's exclude stuff. 
> 
> I don't have strong feelings either way, except it is somewhat late in
> the day for a large(ish) and complicated series.

I agree it is a largish patch set: I think I would err against including
it for 0.12 as it has not had a lot of testing (I think only by me). It
would also allow people to work out what they wanted emacs to do with
the exclude flag. (The notmuch-show.el patch 12/13 needs simple rebasing
which I have done but not posted yet.)

A temporary revert might be reasonable: alternatively we could just turn
off the automatic addition of the exclude tags (deleted and spam) to the
config file in notmuch-config so only users who ask for it get it on
this release.

If it is not reverted then I think patches 1-3 of the latest series
id:"1330157204-26094-1-git-send-email-markwalters1009 at gmail.com"
might be worth including. They just add the --no-exclude option to
notmuch-count and notmuch-search and are simple (it's one "code" patch,
one "man" patch and some tests).

I guess my favoured option would just be to disable the automatic
addition of exclude tags (ideally with patches 1-3 above, but that is
not important).

Best wishes

Mark

> There are several other patch series that look ready from a review point
> of view, but I'd rather have them pushed earlier in the release cycle
> (or at least I don't see a hurry). For example 
> 
>id:"1329490088-8323-2-git-send-email-dmitry.kurochkin at gmail.com"
>id:"1329697590-7404-1-git-send-email-amdragon at mit.edu"
> 
> My (tentative) plan is to push those once I have branched for release.
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: Replacing my name/email with "me" (or similar) in author lists

[Patrick Totzke]

Quoting Daniel (2012-02-25 16:34:15)
>From what I understand, at least the Python bindings deliver primarily author
>names (not addresses),

To clarify, `notmuch.Thread.get_authors` returns a comma separated list of the 
realname parts of all From-headers that occur in messages of this thread.

> so it would seem more appropriate that this be done in the backend.
I agree. I personally think this is a nice feature to have in all
user interfaces to notmuch and therefore it makes sense to implement it once
in the lib. Also because ~/.notmuch-config already contains a list of my 
addresses
and therefore should have all information needed.

Implementing this feature for alot in python is easily doable, by constructing
the authors list from the messages From headers directly, comparing
the address part with all known own addresses.
We will do so if the response here is all too negative or nobody is brave 
enough to
step forward and touch the lib in this respect.

If I'm not mistaken, the lib extracts the authors name from the From-header
of a message, which is indexed. Somewhere around line 248 in thread.cc,
this string is added to a list of names.

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

Re: Double decoded text/html parts (was: [PATCH] test: Add test for searching of uncommonly encoded messages)

[Serge Z]

This works:
w3m -o document_charset=windows-1251 test.html

It says that w3m should suppose windows-1251 encoding if no html-meta
content-type tag given.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Double decoded text/html parts (was: [PATCH] test: Add test for searching of uncommonly encoded messages)

[Michal Sojka]

On Sat, 25 Feb 2012, Serge Z wrote:
> 
> Hi!
> I've struck another problem:
> 
> I've got an html/text email with body encoded with cp1251.
> Its encoding is mentioned in both Content-type: email header and html 
> tag. So when the client tries to display it with external html2text converter,
> The message is decoded twice: first by client, second by html2text (I
> use w3m).

Right. After my analysis of the problem (see below) it seems there is no
trivial solution for this.
 
> As I understand, notmuch (while indexing this message) decodes it once and
> index it in the right way (though including html tags to index). But what if
> the message contains no "charset" option in Content-Type email header but
> contain  content-type tag with charset noted?

This should not happen. It violates RFC 2046, section 4.1.2.

> Should such message be considered as being composed wrong or it should
> be indexed with diving into html details (content-type)?

I don't think it's wrongly composed and it should be even correctly
indexed (with my patch). The problem is when you view such a message
with an external HTML viewer.

In my mailbox I can find two different types of text/html parts. First,
the parts that contain complete HTML document including all headers and
especially .
Such parts could be passed to external HTML viewer without any decoding
by notmuch.

The second type is text/html part that does not contain any HTML
headers. Passing such a part to an external HTML viewer undecoded would
require it to guess the correct charset from the content.

AFAIK Firefox users can set fallback charset (used for HTML documents
with unknown charset) in the preferences, but I don't know what other
browsers would do. In particular, do you know how w3m behaves when
charset is not specified?

In any way, if we want notmuch to do the right thing, we should analyze
the content of text/html parts and decide whether to decode the part or
not. Perhaps, a simple heuristic could be to search the content of the
part for strings "charset=" and "encoding=" and if any is found, notmuch
wouldn't decode that part. Otherwise it will decode it according to
Content-Type header.

As a curiosity, I found the following in one of my emails. Note that two
different encodings (iso-8859-2 and windows-1250) are specified at the
same time :) That's the reason why I think that fixing the problem won't
be trivial.

Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: 8bit


http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
http://www.w3.org/1999/xhtml";>



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

[PATCH] man: add references to maildir flag synchronization

[Jani Nikula]

notmuch new, restore, and tag commands support maildir flag
synchronization with notmuch tags. Reference the notmuch-config(1) man
page about it in the relevant man pages.
---
 man/man1/notmuch-new.1 |5 +
 man/man1/notmuch-restore.1 |6 ++
 man/man1/notmuch-tag.1 |6 ++
 3 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/man/man1/notmuch-new.1 b/man/man1/notmuch-new.1
index 77d4776..76910a4 100644
--- a/man/man1/notmuch-new.1
+++ b/man/man1/notmuch-new.1
@@ -40,6 +40,11 @@ has previously been completed, but
 .B "notmuch new"
 has not previously been run.

+.B "notmuch new"
+updates tags according to maildir flag changes if the
+.B "maildir.synchronize_flags"
+configuration option is enabled. See \fBnotmuch-config\fR(1) for
+details.

 The
 .B new
diff --git a/man/man1/notmuch-restore.1 b/man/man1/notmuch-restore.1
index 2191df0..ef27938 100644
--- a/man/man1/notmuch-restore.1
+++ b/man/man1/notmuch-restore.1
@@ -29,6 +29,12 @@ dump file.
 See \fBnotmuch-search-terms\fR(7)
 for details of the supported syntax for .

+.B "notmuch restore"
+updates the maildir flags according to tag changes if the
+.B "maildir.synchronize_flags"
+configuration option is enabled. See \fBnotmuch-config\fR(1) for
+details.
+
 .RE
 .SH SEE ALSO

diff --git a/man/man1/notmuch-tag.1 b/man/man1/notmuch-tag.1
index 993911b..7281bb2 100644
--- a/man/man1/notmuch-tag.1
+++ b/man/man1/notmuch-tag.1
@@ -23,6 +23,12 @@ an initial search term beginning with '+' or '\-' is provided
 by allowing the user to specify a "\-\-" argument to separate
 the tags from the search terms.

+.B "notmuch tag"
+updates the maildir flags according to tag changes if the
+.B "maildir.synchronize_flags"
+configuration option is enabled. See \fBnotmuch-config\fR(1) for
+details.
+
 .SH SEE ALSO

 \fBnotmuch\fR(1), \fBnotmuch-config\fR(1), \fBnotmuch-count\fR(1),
-- 
1.7.5.4

[PATCH] emacs: Fix out of date comment

[Austin Clements]

The behavior of the header line in show-mode changed from showing the
subject of the first open message to showing the subject of the first
message in 4d77f18b.  Update a comment to reflect this.
---
 emacs/notmuch-show.el |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index dd1fb83..2cca2e2 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1114,7 +1114,7 @@ function is used."
 
   (run-hooks 'notmuch-show-hook))
 
-;; Set the header line to the subject of the first open message.
+;; Set the header line to the subject of the first message.
 (setq header-line-format (notmuch-show-strip-re 
(notmuch-show-get-pretty-subject)
 
 (defun notmuch-show-capture-state ()
-- 
1.7.7.3

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

[PATCH] man: document the notmuch configuration settings in notmuch-config(1)

[Jani Nikula]

At the risk of duplication between the man page and the configuration
file generated by default, document the notmuch configuration options
in the notmuch config man page.

Existing users of notmuch should not be expected to re-generate their
config file in order to get access to the documentation for new
configuration options.

Include some minor fixes and cleanups while at it.
---
 man/man1/notmuch-config.1 |  125 ++--
 1 files changed, 108 insertions(+), 17 deletions(-)

diff --git a/man/man1/notmuch-config.1 b/man/man1/notmuch-config.1
index cb3234f..0260eb7 100644
--- a/man/man1/notmuch-config.1
+++ b/man/man1/notmuch-config.1
@@ -1,6 +1,6 @@
 .TH NOTMUCH-CONFIG 1 2011-12-04 "Notmuch 0.10.2"
 .SH NAME
-notmuch-config \- Output a single part of a multipart MIME message.
+notmuch-config \- Access notmuch configuration file.
 .SH SYNOPSIS

 .B notmuch config get
@@ -16,34 +16,125 @@ The
 command can be used to get or set settings in the notmuch
 configuration file.

-.SS GET
-
+.RS 4
+.TP 4
+.B get
 The value of the specified configuration item is printed to stdout. If
-the item has multiple values, each value is separated by a newline
-character.
+the item has multiple values (it is a list), each value is separated
+by a newline character.
+.RE

-Available configuration items include at least
+.RS 4
+.TP 4
+.B set
+The specified configuration item is set to the given value. To specify
+a multiple-value item (a list), provide each value as a separate
+command-line argument.

-   database.path
+If no values are provided, the specified configuration item will be
+removed from the configuration file.
+.RE

-   user.name
+The available configuration items are described below.

-   user.primary_email
+.RS 4
+.TP 4
+.B database.path
+The top-level directory where your mail currently exists and to where
+mail will be delivered in the future. Files should be individual email
+messages. Notmuch will store its database within a sub-directory of
+the path configured here named
+.BR ".notmuch".
+.RE

-   user.other_email
+.RS 4
+.TP 4
+.B user.name
+Your full name.
+.RE

-   new.tags
+.RS 4
+.TP 4
+.B user.primary_email
+Your primary email address.
+.RE

-.SS SET
+.RS 4
+.TP 4
+.B user.other_email
+A list of other email addresses at which you receive email.
+.RE

-The specified configuration item is set to the given value.  To
-specify a multiple-value item, provide each value as a separate
-command-line argument.
+.RS 4
+.TP 4
+.B new.tags
+A list of tags that will be added to all messages incorporated by
+.BR "notmuch new".
+.RE

-If no values are provided, the specified configuration item will be
-removed from the configuration file.
+.RS 4
+.TP 4
+.B new.ignore
+A list of file and directory names, without path, that will not be
+searched for messages by
+.BR "notmuch new".
+All the files and directories matching any of the names specified here
+will be ignored, regardless of the location in the mail store
+directory hierarchy.
 .RE

+.RS 4
+.TP 4
+.B search.exclude
+A list of tags that will be excluded from search results by
+default. Using an excluded tag in a query will override that
+exclusion.
+.RE
+
+.RS 4
+.TP 4
+.B maildir.synchronize_flags
+If true, then the following maildir flags (in message filenames) will
+be synchronized with the corresponding notmuch tags:
+
+  FlagTag
+  ---
+  D   draft
+  F   flagged
+  P   passed
+  R   replied
+  S   unread (added when 'S' flag is not present)
+
+The
+.B notmuch new
+command will notice flag changes in filenames and update tags, while
+the
+.B notmuch tag
+and
+.B notmuch restore
+commands will notice tag changes and update flags in filenames.
+
+If there have been any changes in the maildir (new messages added, old
+ones removed or renamed, maildir flags changed, etc.), it is advisable
+to run
+.B notmuch new
+before
+.B notmuch tag
+or
+.B notmuch restore
+commands to ensure the tag changes are properly synchronized to the
+maildir flags, as the commands expect the database and maildir to be
+in sync.
+.RE
+
+.RE
+.SH ENVIRONMENT
+The following environment variables can be used to control the
+behavior of notmuch.
+.TP
+.B NOTMUCH_CONFIG
+Specifies the location of the notmuch configuration file. Notmuch will
+use ${HOME}/.notmuch\-config if this variable is not set.
 .SH SEE ALSO

 \fBnotmuch\fR(1), \fBnotmuch-count\fR(1),
-- 
1.7.5.4

Re: plans for 0.12

[Mark Walters]

On Sat, 25 Feb 2012 10:27:02 -0400, David Bremner  wrote:
> 
> I would like to start a freeze (i.e. merge master to release) for 0.12
> within the next week, say March 1 for an easy to remember date.
> 
> If you have suggestions for things that "should really go in", feel free
> to follow up. The main point here is bug fixes, or features which are
> there in a kindof half baked way.
> 
> Bug fix wise, I know about 
>   
>   id:"1330068983-4483-1-git-send-email-sojk...@fel.cvut.cz"
> 
> This could use some review.
> 
> It has also been some chatter that either (the next iteration of)
> 
>id:"1329296619-7463-1-git-send-email-markwalters1...@gmail.com" 
> 
> Should go in, or we should revert amdragon's exclude stuff. 
> 
> I don't have strong feelings either way, except it is somewhat late in
> the day for a large(ish) and complicated series.

I agree it is a largish patch set: I think I would err against including
it for 0.12 as it has not had a lot of testing (I think only by me). It
would also allow people to work out what they wanted emacs to do with
the exclude flag. (The notmuch-show.el patch 12/13 needs simple rebasing
which I have done but not posted yet.)

A temporary revert might be reasonable: alternatively we could just turn
off the automatic addition of the exclude tags (deleted and spam) to the
config file in notmuch-config so only users who ask for it get it on
this release.

If it is not reverted then I think patches 1-3 of the latest series
id:"1330157204-26094-1-git-send-email-markwalters1...@gmail.com"
might be worth including. They just add the --no-exclude option to
notmuch-count and notmuch-search and are simple (it's one "code" patch,
one "man" patch and some tests).

I guess my favoured option would just be to disable the automatic
addition of exclude tags (ideally with patches 1-3 above, but that is
not important).

Best wishes

Mark

> There are several other patch series that look ready from a review point
> of view, but I'd rather have them pushed earlier in the release cycle
> (or at least I don't see a hurry). For example 
> 
>id:"1329490088-8323-2-git-send-email-dmitry.kuroch...@gmail.com"
>id:"1329697590-7404-1-git-send-email-amdra...@mit.edu"
> 
> My (tentative) plan is to push those once I have branched for release.
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch