Re: Segfault when tagging results of to: query

[Suvayu Ali]

Hi,

On Mon, Nov 11, 2019 at 8:54 PM Hugh Williams  wrote:
>
> When trying to tag all messages to a particular address using the query
> `notmuch tag +College to:exam...@example.com` I get a segfault. The
> backtrace from gdb is shown below.
>
> ```
> #0  0x778deee4 in  () at /usr/lib/libxapian.so.30
> #1  0x778e26fe in  () at /usr/lib/libxapian.so.30
> #2  0x778e90a2 in  () at /usr/lib/libxapian.so.30
> #3  0x778081f8 in Xapian::Enquire::Internal::get_mset(unsigned int, 
> unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) 
> const () at /usr/lib/libxapian.so.30
> #4  0x77808466 in Xapian::Enquire::get_mset(unsigned int, unsigned 
> int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () 
> at /usr/lib/libxapian.so.30
> #5  0x77fb69ca in  () at /usr/lib/libnotmuch.so.5
> #6  0x5556bca2 in  ()
> #7  0x5556c21a in  ()
> #8  0xc12c in  ()
> #9  0x779c9153 in __libc_start_main () at /usr/lib/libc.so.6
> #10 0xc2ee in  ()
> ```

I see the same issue as well!  I'm on Fedora 30, using the package
available in the repos.
5.1.20-300.fc30.x86_64
notmuch-0.29.1-1.fc30.x86_64

Here's an example stack trace:

Stack trace of thread 26982:
#0  0x7f6a3f4c42b8 _ZNK14AndNotPostList10get_weightEv (libxapian.so.30)
#1  0x7f6a3f4c7d06 _ZNK14SelectPostList10get_weightEv (libxapian.so.30)
#2  0x7f6a3f4cf62a
_ZN10MultiMatch8get_msetEjjjRN6Xapian4MSetERNS0_6Weight8InternalEPKNS0_12MatchDeciderEPKNS0_8KeyMakerE
(libxapian.so.30)
#3  0x7f6a3f3e50e6
_ZNK6Xapian7Enquire8Internal8get_msetEjjjPKNS_4RSetEPKNS_12MatchDeciderE
(libxapian.so.30)
#4  0x7f6a3f3e5359
_ZNK6Xapian7Enquire8get_msetEjjjPKNS_4RSetEPKNS_12MatchDeciderE
(libxapian.so.30)
#5  0x7f6a3f9a6da0 n/a (libnotmuch.so.5)
#6  0x00419468 tag_query (notmuch)
#7  0x004199d2 notmuch_tag_command (notmuch)
#8  0x00409efb main (notmuch)
#9  0x7f6a3f5b2f43 __libc_start_main (libc.so.6)
#10 0x0040a0ae _start (notmuch)

Query that triggered the segfault is: notmuch tag +fedora --
path:Gmail/** and to:lists.fedoraproject.org and is:new

-- 
Suvayu

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

Re: Loading a notmuch email buffer in Emacs from the command line

[Suvayu Ali]

On Sat, Feb 20, 2016 at 12:16:33PM +0200, Tomi Ollila wrote:
> On Sat, Feb 20 2016, Neeum Zawan  wrote:
> >
> > Is there a way (e.g. with emacsclient) to load up a particular email
> > thread or email message buffer from the command line?
> 
> quick test yields that at least
> 
>   emacs -f notmuch --eval '(notmuch-search "id:87egc8nhdh@nawaz.org")'
> 
> works (maybe not exactly as desired, but based on that more should
> be able to be achieved with moderate ease...)

I use the attached script to open the mail I'm reading in Mutt in Emacs
so that I can link to it in my Org mode notes, etc.  You could write a
function that calls the required capture templates and use it in place
of the call to notmuch-show.  Probably you also want to remove the GNU
Screen related stuff (call to screen select and the check for $STY).

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.
#!/bin/bash

# set -o xtrace

# FIXME: handle cases when not invoked from within screen
declare -a emacsen=(/tmp/emacs$UID/*) screens=(/var/run/screen/S-$USER/*)
# NOTE: look at screen -Q for querying

# FIXME: cleaner way of switching to threads (something like mutt-search)
declare thread=$1

[[ -n $STY ]] && { \
screen -X select nwc;   # emacsclient window name for me

# NB: reading from PIPE; and it's ok to remove all <, >, or
# spaces, they are not allowed in a Message-ID
msgid=$(formail -c -x Message-ID | sed -e 's/[<> ]//g')
if [[ -n $thread ]]; then
query=$(notmuch search --output=threads -- "id:$msgid")
emacsclient --eval "(notmuch-tree \"$query\")"
else
query="id:$msgid"
emacsclient --eval "(notmuch-show \"$query\")"
fi
}
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch-emacs: forward messages inline

[Suvayu Ali]

On Fri, Nov 06, 2015 at 06:42:26AM +0900, Daniel Kahn Gillmor wrote:
> 
> But can i ask why you'd want this?  forwarded messages as RFC 822
> attachments are significantly more sane for any MUA to deal with.

I'm not the OP, but often I prefer this over forwarding as attachments.
I find it useful when I only want to forward specific bits of an email.
Rather than sending the whole message (which often has lots of quoted
text from earlier in the thread), I can easily edit the message as
needed.  I guess this is functionally similar to your "reply and edit"
suggestion.

-- 
Suvayu

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

Re: correct way to search for only PDF attachments

[Suvayu Ali]

On Mon, Sep 28, 2015 at 07:00:13PM -0700, Carl Worth wrote:
> On Mon, Sep 28 2015, Xu Wang wrote:
> 
> > To understand more, what does the following search for?
> >
> > from:jongho attachment:.*pdf
> 
> Uhm, probably only strange things. There are some mechanisms for getting
> notmuch to emit some debugging information on what the final search
> terms end up being, (but I don't recall if they still require
> recompilation or not).

This should work:

  $ export NOTMUCH_DEBUG_QUERY=1
  $ notmuch count -- from:suvayu attachment:*.pdf
  Query string is:
  from:suvayu attachment:*.pdf
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND ZXFROMsuvayu:(pos=1) AND Zattach:(pos=2) AND 
Zpdf:(pos=3)))
  217
  $ notmuch count -- from:suvayu attachment:pdf
  Query string is:
  from:suvayu attachment:pdf
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND ZXFROMsuvayu:(pos=1) AND ZXATTACHMENTpdf:(pos=2)))
  151

I guess to answer the OP's question, the globbed form simply does a text
search of attach and pdf.  The keyword is not recognised at all.

Cheers,

-- 
Suvayu

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

Re: correct way to search for only PDF attachments

[Suvayu Ali]

On Tue, Sep 29, 2015 at 08:00:18AM -0300, David Bremner wrote:
>
> Of course it is getting pretty big, I don't know what to do about
> that.

How about an overview in notmuch-search-terms with more detailed docs in
an info page?  coreutils does this.  I don't think this will add any new
build dependencies either, as sphinx supports info pages.  I see
texinfo_documents is already defined in doc/conf.py.  Maybe that is an
option?

-- 
Suvayu

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

Re: Possible some threads are not complete due to bug?

[Suvayu Ali]

Hi,

You should include a reference to the original message, not everyone
will remember the thread.

  id:20150614082258.gd17...@chitra.no-ip.org or
  

On Sun, Sep 13, 2015 at 12:03:20AM -0400, Xu Wang wrote:
> 
> Sometimes I need to do:
> 
> $ notmuch search --output=threads "id:MYMSGID"
> thread:a125
> $ notmuch search --output=messages "thread:a125"

Looking at the script again, I see I assumed a message will belong to a
single thread.  You can remove that assumption by applying the following
change.

-8<8<-
diff -u nm-ack nm-ack
--- nm-ack  2015-06-15 01:30:40.327556510 +0200
+++ nm-ack  2015-09-13 07:58:30.734096931 +0200
@@ -10,8 +10,9 @@
 # debug
 # set -o xtrace
 
-declare query="$1" thread=$(notmuch search --output=threads -- "$1")
-declare -a msgs=$(notmuch search --output=messages -- "$thread") responses
+declare query="$1"
+declare -a thread=$(notmuch search --output=threads -- "$1")
+declare -a msgs=$(notmuch search --output=messages -- "${thread[@]}") responses
 
 function strip_mid() {
 sed -e 's/ \+//g' -e 's/<\([^ <>]\+\)>/\1/g'
->8>8-

> In theory, this should output the message that responded to message ID
> "MYMSGID". Sometimes it works. But sometimes it does not work. That
> is, there exists an email where I am sure (I checked the raw email)
> that there is a header
> In-Reply-To: 
> but that email does not show when I do the two commands above.
> Indeed, that mail belongs to a different thread ID.
> 
> I am just curious if the above is due to:
> 
> 1. My missing of understanding of how notmuch deals with threads
> 2. A bug or missing feature in notmuch causes some threads to be incomplete

Interesting issue.  I can think of a case, say a message is cross-posted
to multiple lists, it might then give you more than one thread ids.  Is
this the case for your message?  If you are up for it, look in
lib/thread.cc.  I think the relevant methods are:
_resolve_thread_relationships and _notmuch_thread_create, but I could be
wrong.  I'm not familiar with the notmuch source.

As I recall, you are using mutt-kz; does  work from
mutt-kz?  I would expect that to fail too.  It gets the thread id like
this:

  id = notmuch_message_get_thread_id(msg);

Hope this helps,

-- 
Suvayu

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

Re: how to make return follow hyperlink?

[Suvayu Ali]

On Thu, Aug 27, 2015 at 09:35:26AM +0100, David Edmondson wrote:
 On Wed, Aug 26 2015, Peter Salazar cycleofs...@gmail.com wrote:
  How do I make it so that hitting RET on a hyperlink follows it? Is there a
  setting analogous to org-return-follows-link? I often have links in
  incoming emails, and I'd like to be able to open them in my browser with
  one keystroke.
 
 Having that binding would conflict badly with the existing binding for
 `notmuch-show-toggle-message' (which has been in place for a long
 time!).
 
 Perhaps not what you want, but for me, clicking on the link with the
 mouse opens the link.

I think you can hack around by advicing notmuch-show-toggle-message and
making it context sensitive.  I don't really know the best way to
determine the context, but a quick hack would be to look at the
face-at-point.  Of course this requires font-lock-mode be active.

I once did something like this to expand abbreviations (below).  Of
course you will have to use a defadvice instead of a defun.

Hope this helps,


(defun sa-expand-abbrev-in-context (expand)
  Expands abbreviations according to the context. Determines
whether within comments or source by looking at the face name. If
within comments the `basic-text-mode-abbrev-table' is used, the
major mode abbrev-table is used otherwise.

Expansion is done by the function passed as the argument. This is
controlled by the \abnormal\ hook `abbrev-expand-functions'.
;; backward-char checks if end-of-buffer as when point at e-o-b face is `nil'
;; the function call expand does the expansion, usually `expand-abbrev'
  (if (save-excursion
(string-match comment\\|string
  (symbol-name (if ( (point) (point-max))
   (face-at-point)
 (backward-char)
 (face-at-point)
  (let ((local-abbrev-table basic-text-mode-abbrev-table))
(funcall expand))
(funcall expand)))


-- 
Suvayu

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

Searching for phrases in the body of an email

[Suvayu Ali]

On Sat, Jul 18, 2015 at 12:34:16PM -0400, Xu Wang wrote:
> On Sat, Jul 18, 2015 at 11:32 AM, Suvayu Ali
> <fatkasuvayu+linux at gmail.com> wrote:
> 
> > Of course this does not help me solve my original goal, but I guess now
> > I can try different queries based on your idea.
> 
> Ah I see. Your goal is to search for phrases close to "no plain text".
> But if you use fuzzy searching but an exact grep, then it is normal
> that the numbers are not consistent, no? Because your grep is not
> fuzzy.

My grep was this (case insensitive): 'plain[[:space:]/]+text'.  Since I
thought I was searching for the _phrase_ "plain text", that would be
adequately fuzzy.  However after following Jani's advice, I realise it
wasn't always being treated as a phrase, neither was NEAR being treated
as an operator.  

I wanted to combine a phrase (plain text) with the NEAR query (NEAR no),
but maybe that combination is not possible.  That's why I tried to
combine NEAR and ADJ (as per your suggestion) by grouping them, that
does not seem to work either!

-- 
Suvayu

Open source is the future. It sets us free.

Searching for phrases in the body of an email

[Suvayu Ali]

Hi Jani,

On Sat, Jul 18, 2015 at 06:53:53PM +0300, Jani Nikula wrote:
> On Jul 18, 2015 6:32 PM, "Suvayu Ali" <fatkasuvayu+linux at gmail.com> wrote:
> > On Sat, Jul 18, 2015 at 10:54:30AM -0400, Xu Wang wrote:
> > >
> > > First note that I believe notmuch search is case insensitive by
> > > default, so your grep should be case insensitive as well.
> >
> > Good point, I tried that, didn't change the numbers much.  The number of
> > matches from grep went up to 24, whereas notmuch count says 463.
> >
> > > More importantly, I'm not sure how 'no NEAR "plain text" ' syntax is
> > > parsed. Maybe it is parsed as {no NEAR plain} or {text}.
> > >
> >
> > Exactly, that's what I do not understand.
> >
> 
> export NOTMUCH_DEBUG_QUERY=1
> 
> might help.

That helped a lot!  This is what I get:

  $ notmuch count -- no NEAR \"plain\ text\"
  Query string is:
  no NEAR "plain text"
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND Zno:(pos=1) AND near:(pos=2) AND Zplain:(pos=3) AND 
text:(pos=4)))
  465
  $ notmuch count -- \"plain\ text\"
  Query string is:
  "plain text"
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND (plain:(pos=1) PHRASE 2 text:(pos=2
  870

I wanted the "plain text" to be treated as a phrase, as in the second
case.  I have tried nesting the quotes.  The closest I got to was this:

  $ notmuch count -- no NEAR 'plain\ text'
  Query string is:
  no NEAR plain\ text
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND (no:(pos=1) NEAR 11 plain:(pos=2)) AND 
Ztext:(pos=3)))
  151

I then tried this:

  $ notmuch count -- no NEAR \(plain ADJ/1 text\)
  Query string is:
  no NEAR (plain ADJ/1 text)
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND Zno:(pos=1) AND near:(pos=2) AND Zplain:(pos=3) AND 
(adj:(pos=4) PHRASE 2 1:(pos=5)) AND Ztext:(pos=6)))
  0

Again, this is not what I was expecting.  With the last one, I was
expecting to group "plain" and "text" within a distance of 1, in the
given order, and then requring "no" to be near (within 10 words, the
default) the "plain ADJ/1 text" combination.

Is my understanding of the query language completely wrong?  Apart from
`man notmuch-search-terms', I looked here:
http://xapian.org/docs/queryparser.html

Thanks for any help.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Searching for phrases in the body of an email

[Suvayu Ali]

Hi Xu,

On Sat, Jul 18, 2015 at 10:54:30AM -0400, Xu Wang wrote:
> 
> First note that I believe notmuch search is case insensitive by
> default, so your grep should be case insensitive as well.

Good point, I tried that, didn't change the numbers much.  The number of
matches from grep went up to 24, whereas notmuch count says 463.

> More importantly, I'm not sure how 'no NEAR "plain text" ' syntax is
> parsed. Maybe it is parsed as {no NEAR plain} or {text}.
> 

Exactly, that's what I do not understand.

> You would like to search for the exact phrase, correct? How about the
> following?
> 
> notmuch search no adj plain adj text

Good suggestion.  I tried it, and gives me very consistent numbers:

$ notmuch count -- no ADJ plain ADJ text
20
$ notmuch show -- $(notmuch search --output=messages -- no NEAR \"plain\ 
text\") | \
  grep -c -iE 'plain[[:space:]/]+text'
24

Of course this does not help me solve my original goal, but I guess now
I can try different queries based on your idea.

Thanks a lot!

-- 
Suvayu

Open source is the future. It sets us free.

Searching for phrases in the body of an email

[Suvayu Ali]

Hi Lewis,

On Fri, Jul 17, 2015 at 10:48:57AM -0500, J. Lewis Muir wrote:
> 
> 1. Perhaps you are remembering the "no plain text" message incorrectly?
>For example, the message could have referred to "text/plain" or
>"plaintext" (no space).  These would be sufficiently different to not
>match your grep pattern.

True, but my puzzlement is notmuch shouldn't return those results in the
first place, since I provided a quoted string: "plain text", unless of
course I need to escape the quotes.  Okay, just checked it, doesn't make
a difference in the number of hits from notmuch.

> 2. Perhaps your email client rendered the "no plain text" message when
>it encountered an email with only a "text/html" content type?  In
>this case, the "no plain text" (or whatever) message would not be
>present in the email itself since it would be generated by the email
>client when rendering the email.

This is possible, but I use mutt.  As far as I know, it doesn't do
"smart" things like that.  I also recall looking at the mime parts
individually as I was surprised at the behaviour, and it was indeed a
useless text/plain part with that message.

> 3. A really long shot, but could a line wrap have occurred after "plain"
>such that "text" appeared on the next line?  Your grep pattern would
>not match that.

Good point, I tried grepping for this instead: 'plain[[:space:]/]+text',
no luck.

Thanks for your comments.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Searching for phrases in the body of an email

[Suvayu Ali]

Hi Xu,

On Sat, Jul 18, 2015 at 10:54:30AM -0400, Xu Wang wrote:
 
 First note that I believe notmuch search is case insensitive by
 default, so your grep should be case insensitive as well.

Good point, I tried that, didn't change the numbers much.  The number of
matches from grep went up to 24, whereas notmuch count says 463.

 More importantly, I'm not sure how 'no NEAR plain text ' syntax is
 parsed. Maybe it is parsed as {no NEAR plain} or {text}.
 

Exactly, that's what I do not understand.

 You would like to search for the exact phrase, correct? How about the
 following?
 
 notmuch search no adj plain adj text

Good suggestion.  I tried it, and gives me very consistent numbers:

$ notmuch count -- no ADJ plain ADJ text
20
$ notmuch show -- $(notmuch search --output=messages -- no NEAR \plain\ 
text\) | \
  grep -c -iE 'plain[[:space:]/]+text'
24

Of course this does not help me solve my original goal, but I guess now
I can try different queries based on your idea.

Thanks a lot!

-- 
Suvayu

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

Re: Searching for phrases in the body of an email

[Suvayu Ali]

On Sat, Jul 18, 2015 at 12:34:16PM -0400, Xu Wang wrote:
 On Sat, Jul 18, 2015 at 11:32 AM, Suvayu Ali
 fatkasuvayu+li...@gmail.com wrote:
 
  Of course this does not help me solve my original goal, but I guess now
  I can try different queries based on your idea.
 
 Ah I see. Your goal is to search for phrases close to no plain text.
 But if you use fuzzy searching but an exact grep, then it is normal
 that the numbers are not consistent, no? Because your grep is not
 fuzzy.

My grep was this (case insensitive): 'plain[[:space:]/]+text'.  Since I
thought I was searching for the _phrase_ plain text, that would be
adequately fuzzy.  However after following Jani's advice, I realise it
wasn't always being treated as a phrase, neither was NEAR being treated
as an operator.  

I wanted to combine a phrase (plain text) with the NEAR query (NEAR no),
but maybe that combination is not possible.  That's why I tried to
combine NEAR and ADJ (as per your suggestion) by grouping them, that
does not seem to work either!

-- 
Suvayu

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

Searching for phrases in the body of an email

[Suvayu Ali]

Hi,

I'm trying to find those annoying emails which have useless plain text
parts.  As I recall, they had a phrase something along the lines of "not
available in plain text" or "no plain text".  So of course I searched
for "plain text".  But that returns hundreds of messages with no obvious
matches, I can't even find the phrase "plain text" in the body for most
of the results!

Here is an example:

$ notmuch search --limit=1 -- no NEAR "plain text"
thread:a2a6   Sat. 00:30 [1/1] NASA Jet Propulsion Laboratory; 
NASA's Curiosity Mars Rover Tracks Sunspots (2015 2015-07 inbox)
$ notmuch show --format=raw -- thread:a2a6 | grep 'plain text'
$

To make this stranger, here are more numbers:

$ notmuch show -- $(notmuch search --output=messages -- no NEAR "plain text") | 
\
  grep -c -e 'plain text'
7
$ notmuch count -- no NEAR "plain text"
461

I do not understand this at all!  Any thoughts?

Thanks in advance,

-- 
Suvayu

Open source is the future. It sets us free.

Searching for phrases in the body of an email

[Suvayu Ali]

Hi,

I'm trying to find those annoying emails which have useless plain text
parts.  As I recall, they had a phrase something along the lines of not
available in plain text or no plain text.  So of course I searched
for plain text.  But that returns hundreds of messages with no obvious
matches, I can't even find the phrase plain text in the body for most
of the results!

Here is an example:

$ notmuch search --limit=1 -- no NEAR plain text
thread:a2a6   Sat. 00:30 [1/1] NASA Jet Propulsion Laboratory; 
NASA's Curiosity Mars Rover Tracks Sunspots (2015 2015-07 inbox)
$ notmuch show --format=raw -- thread:a2a6 | grep 'plain text'
$

To make this stranger, here are more numbers:

$ notmuch show -- $(notmuch search --output=messages -- no NEAR plain text) | 
\
  grep -c -e 'plain text'
7
$ notmuch count -- no NEAR plain text
461

I do not understand this at all!  Any thoughts?

Thanks in advance,

-- 
Suvayu

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

notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

First, apologies for the delay.  I had a bicycle accident, still
recovering.

On Tue, Jun 30, 2015 at 07:02:52PM +0200, David Bremner wrote:
> Suvayu Ali <fatkasuvayu+linux at gmail.com> writes:
> 
> > Yes, I have looked at what the official packages[1] do, I do exactly the
> > same[2].  Essentially the spec file does the following:
> >
> >   pushd bindings/ruby
> >   ruby extconf.rb --vendor --with-cflags="%{optflags}"
> >   make %{?_smp_mflags}
> >   popd
> 
> I think the problem is contained in the original message. Since we want
> to create a shared library "notmuch.so" for ruby to import, we need to
> compile the C files in bindings/ruby with -fPIC.
> 
> I don't know if this is Debian specific, or ruby version specific, but
> on my Debian Jessie machine with ruby 2.1, the generated Makefile
> bindings/ruby/Makefile has
> 
> CFLAGS   = $(CCDLFLAGS) -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -fPIC $(ARCH_FLAG)
> 
> in it
> 
> even when invoked outside the notmuch build system; e.g.
> 
> % cd bindings/ruby && ruby extconf.rb
> 
> I guess the first step is to see if the -fPIC flag is also there on
> Fedora, and if not, why not. If I look at the builds for 0.19 [1]
> it seems it is. But notice there it is not required to pass it in to 
> "--with-cflags"

Indeed.  I looked at the generated Makefiles, they like below:

--- nm-0.20.2.mk2015-07-06 15:11:26.138317221 +0200
+++ nm-master.mk2015-07-06 15:41:14.929951640 +0200
@@ -80,7 +80,7 @@
 debugflags = -ggdb3
 warnflags = -Wall -Wextra -Wno-unused-parameter -Wno-parentheses 
-Wno-long-long -Wno-missing-field-initializers -Wunused-variable 
-Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement 
-Wimplicit-function-declaration -Wdeprecated-declarations 
-Wno-packed-bitfield-compat
 CCDLFLAGS = -fPIC
-CFLAGS   = $(CCDLFLAGS) -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic 
$(ARCH_FLAG)
+CFLAGS   = $(CCDLFLAGS) -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic -fPIC 
$(ARCH_FLAG)
 INCFLAGS = -I. -I../../lib -I$(arch_hdrdir) -I$(hdrdir)/ruby/backward 
-I$(hdrdir) -I$(srcdir)
 DEFS = 
 CPPFLAGS =   $(DEFS) $(cppflags)

So actually, the master version gets the -fPIC flag.  But it should be
redundant, since CCDLFLAGS is already set to -fPIC.  Now when I compare
the corresponding compile commands, I see (you also noticed that in the
logs):

0.20.2: gcc -I. -I../../lib -I/usr/include -I/usr/include/ruby/backward 
-I/usr/include -I.   -fPIC -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -m64 -o 
message.o -c message.c
master: gcc -I. -I../../lib -I/usr/include -I/usr/include/ruby/backward 
-I/usr/include -I.   -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -o 
message.o -c message.c

So the trailing bits of the command is somehow dropped, and the
CCDLFLAGS seems to be absent (see, no empty space either).  I do not
understand why that would be the case.  I'll dig further when I can find
some more time ...

> [1] 
> https://kojipkgs.fedoraproject.org/packages/notmuch/0.19/1.fc21/data/logs/x86_64/build.log
> - I couldn't find x86_64 build logs for 0.20  

You can't, Fedora ships only 0.19.  That's why I maintain the 0.20+ copr
repository, for myself and other interested (invisible) users out there
:-p.  This gap was much wider in the past.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

First, apologies for the delay.  I had a bicycle accident, still
recovering.

On Tue, Jun 30, 2015 at 07:02:52PM +0200, David Bremner wrote:
 Suvayu Ali fatkasuvayu+li...@gmail.com writes:
 
  Yes, I have looked at what the official packages[1] do, I do exactly the
  same[2].  Essentially the spec file does the following:
 
pushd bindings/ruby
ruby extconf.rb --vendor --with-cflags=%{optflags}
make %{?_smp_mflags}
popd
 
 I think the problem is contained in the original message. Since we want
 to create a shared library notmuch.so for ruby to import, we need to
 compile the C files in bindings/ruby with -fPIC.
 
 I don't know if this is Debian specific, or ruby version specific, but
 on my Debian Jessie machine with ruby 2.1, the generated Makefile
 bindings/ruby/Makefile has
 
 CFLAGS   = $(CCDLFLAGS) -g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -fPIC $(ARCH_FLAG)
 
 in it
 
 even when invoked outside the notmuch build system; e.g.
 
 % cd bindings/ruby  ruby extconf.rb
 
 I guess the first step is to see if the -fPIC flag is also there on
 Fedora, and if not, why not. If I look at the builds for 0.19 [1]
 it seems it is. But notice there it is not required to pass it in to 
 --with-cflags

Indeed.  I looked at the generated Makefiles, they like below:

--- nm-0.20.2.mk2015-07-06 15:11:26.138317221 +0200
+++ nm-master.mk2015-07-06 15:41:14.929951640 +0200
@@ -80,7 +80,7 @@
 debugflags = -ggdb3
 warnflags = -Wall -Wextra -Wno-unused-parameter -Wno-parentheses 
-Wno-long-long -Wno-missing-field-initializers -Wunused-variable 
-Wpointer-arith -Wwrite-strings -Wdeclaration-after-statement 
-Wimplicit-function-declaration -Wdeprecated-declarations 
-Wno-packed-bitfield-compat
 CCDLFLAGS = -fPIC
-CFLAGS   = $(CCDLFLAGS) -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic 
$(ARCH_FLAG)
+CFLAGS   = $(CCDLFLAGS) -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic -fPIC 
$(ARCH_FLAG)
 INCFLAGS = -I. -I../../lib -I$(arch_hdrdir) -I$(hdrdir)/ruby/backward 
-I$(hdrdir) -I$(srcdir)
 DEFS = 
 CPPFLAGS =   $(DEFS) $(cppflags)

So actually, the master version gets the -fPIC flag.  But it should be
redundant, since CCDLFLAGS is already set to -fPIC.  Now when I compare
the corresponding compile commands, I see (you also noticed that in the
logs):

0.20.2: gcc -I. -I../../lib -I/usr/include -I/usr/include/ruby/backward 
-I/usr/include -I.   -fPIC -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -m64 -o 
message.o -c message.c
master: gcc -I. -I../../lib -I/usr/include -I/usr/include/ruby/backward 
-I/usr/include -I.   -O2 -g -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -o 
message.o -c message.c

So the trailing bits of the command is somehow dropped, and the
CCDLFLAGS seems to be absent (see, no empty space either).  I do not
understand why that would be the case.  I'll dig further when I can find
some more time ...

 [1] 
 https://kojipkgs.fedoraproject.org/packages/notmuch/0.19/1.fc21/data/logs/x86_64/build.log
 - I couldn't find x86_64 build logs for 0.20  

You can't, Fedora ships only 0.19.  That's why I maintain the 0.20+ copr
repository, for myself and other interested (invisible) users out there
:-p.  This gap was much wider in the past.

Cheers,

-- 
Suvayu

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

notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 09:34:36AM +0200, David Bremner wrote:
> Suvayu Ali <fatkasuvayu+linux at gmail.com> writes:
> > On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
> >> 
> >> Where to obtain notmuch 0.20.2
> >> ===
> >>   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz
> >
> > I took a quick pass at building the release for Fedora.  The ruby
> > bindings seem to fail to build (actually linking fails).
> >
> 
> The ruby bindings are not built automatically by 0.20.2.  You seem to be
> building a snapshot of master. If you want to build the release from
> git, use the signed tag.

Yes, I was aware.  I tried again with proper 0.20.2.  And everything
succeeds.  So I guess something with master.  I usually build master in
that repo, I guess I'll stick to the release for now.

> The question of why master won't build for you is also interesting, but
> a different question. A quick search reveals packages of notmuch 0.19
> ruby bindings seemingly for fc22
> 
>  https://apps.fedoraproject.org/packages/ruby-notmuch/contents
> 
> So I guess have a look and see what existing fedora packaging does.

Yes, I have looked at what the official packages[1] do, I do exactly the
same[2].  Essentially the spec file does the following:

  pushd bindings/ruby
  ruby extconf.rb --vendor --with-cflags="%{optflags}"
  make %{?_smp_mflags}
  popd

where, _smp_mflags is -jN, and optflags is options for gcc.  If you need
the specific flags, I can try to look it up.

> At the moment the only way to disable the ruby bindings (other than
> hacking the build system) is not to have the ruby development files in
> the build env. This may change by the time this is part of a release.

Since everything is built in a chroot, I have control over the build
environment via the spec file.  If need be, I can disable it.  However
it would be interesting to know why master fails.

Thanks for your comments.

Cheers,

Footnotes:

[1] http://pkgs.fedoraproject.org/cgit/notmuch.git/tree/notmuch.spec#n137
[2] https://github.com/suvayu/notmuch-spec/blob/master/notmuch.spec#L139

-- 
Suvayu

Open source is the future. It sets us free.

notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
> 
> Where to obtain notmuch 0.20.2
> ===
>   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz

I took a quick pass at building the release for Fedora.  The ruby
bindings seem to fail to build (actually linking fails).

https://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-22-x86_64/notmuch-0.20.2-1.20150627.git.8cca886b.fc22/build.log.gz

See to the end of the log, search for "make -C bindings/ruby", then you
can see the link failure a few lines down.

Any thoughts?

-- 
Suvayu

Open source is the future. It sets us free.

Re: notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 09:34:36AM +0200, David Bremner wrote:
 Suvayu Ali fatkasuvayu+li...@gmail.com writes:
  On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
  
  Where to obtain notmuch 0.20.2
  ===
http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz
 
  I took a quick pass at building the release for Fedora.  The ruby
  bindings seem to fail to build (actually linking fails).
 
 
 The ruby bindings are not built automatically by 0.20.2.  You seem to be
 building a snapshot of master. If you want to build the release from
 git, use the signed tag.

Yes, I was aware.  I tried again with proper 0.20.2.  And everything
succeeds.  So I guess something with master.  I usually build master in
that repo, I guess I'll stick to the release for now.

 The question of why master won't build for you is also interesting, but
 a different question. A quick search reveals packages of notmuch 0.19
 ruby bindings seemingly for fc22
 
  https://apps.fedoraproject.org/packages/ruby-notmuch/contents
 
 So I guess have a look and see what existing fedora packaging does.

Yes, I have looked at what the official packages[1] do, I do exactly the
same[2].  Essentially the spec file does the following:

  pushd bindings/ruby
  ruby extconf.rb --vendor --with-cflags=%{optflags}
  make %{?_smp_mflags}
  popd

where, _smp_mflags is -jN, and optflags is options for gcc.  If you need
the specific flags, I can try to look it up.

 At the moment the only way to disable the ruby bindings (other than
 hacking the build system) is not to have the ruby development files in
 the build env. This may change by the time this is part of a release.

Since everything is built in a chroot, I have control over the build
environment via the spec file.  If need be, I can disable it.  However
it would be interesting to know why master fails.

Thanks for your comments.

Cheers,

Footnotes:

[1] http://pkgs.fedoraproject.org/cgit/notmuch.git/tree/notmuch.spec#n137
[2] https://github.com/suvayu/notmuch-spec/blob/master/notmuch.spec#L139

-- 
Suvayu

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

Re: notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
 
 Where to obtain notmuch 0.20.2
 ===
   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz

I took a quick pass at building the release for Fedora.  The ruby
bindings seem to fail to build (actually linking fails).

https://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-22-x86_64/notmuch-0.20.2-1.20150627.git.8cca886b.fc22/build.log.gz

See to the end of the log, search for make -C bindings/ruby, then you
can see the link failure a few lines down.

Any thoughts?

-- 
Suvayu

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

ANNOUNCE: muchsync 1 - share notmuch DB across machines

[Suvayu Ali]

On Fri, Jun 19, 2015 at 02:55:19PM -0700, David Mazieres wrote:
> Suvayu Ali <fatkasuvayu+linux at gmail.com> writes:
> 
> > I noticed that the configure script didn't notice notmuch-devel was not
> > installed on my system.  I noticed it when the compilation failed.  Bug?
> 
> What OS and distribution are you using?  notmuch-devel sounds like
> something a linux distribution might do, rather than anything that's
> part of notmuch itself.  On arch linux, for example, there's just a
> notmuch package that includes notmuch.
> 
> Obviously there's no way to compile muchsync without notmuch installed.
> But if you elaborate on what it is you saw and what you would like to
> see I might be able to address it in the next release.

Sorry, I wasn't specific.  I'm on Fedora.  On Fedora, packages are split
into runtime dependencies and build dependencies.  So installing notmuch
will give you the notmuch binary as well as libnotmuch.  Whereas if you
want to compile, the you install notmuch-devel to get the headers.

When I ran the configure script, it failed couple of times.  The first
time it could not find sqlite headers, the second time I was missing
libcrypto related headers.  I installed sqlite-devel and openssl-devel
to resolve these.  The configure script succeeded after this, when it
should have failed since the notmuch headers were missing.  I realised
it when compilation failed.  Installing notmuch-devel resolved this.

> > Besides that, I had a question.  I would like to synchronize just the
> > tags, not the maildirs, I want to use OfflineIMAP for that.  Is that
> > possible?
> 
> Not really, no.  You could run offlineimap followed by muchsync, but you
> run the risk that mail will be delivered in the meantime.  You could
> also run offlineimap to fetch your mail in the first place, and then
> muchsync to sync it between your devices.
> 
> Can I ask why you would want to do this, anyway?  Muchsync should be
> faster than notmuch, particularly if you have a lot of mail directories
> and/or are going to pay the cost of tag synchronization anyway.

I don't quite have a very reliable connection between my server &
laptop.  So I prefer to download my emails from the source, Gmail, at
both locations.  I usually read and respond to emails from my laptop,
but I do use the server sometimes.  So I only need to synchronise the
tags.  I also keep the server around to synchronize a few more maildirs,
the ones I read irregularly and would prefer does not occupy valuable
disk space on my laptop.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

ANNOUNCE: muchsync 1 - share notmuch DB across machines

[Suvayu Ali]

On Wed, Jun 10, 2015 at 11:36:15PM -0700, David Mazieres wrote:
> I've just released a new version of muchsync, the tool for replicating
> your notmuch database on multiple machines.  The source release is
> available at:
> 
> http://www.muchsync.org/src/muchsync-1.tar.gz
> 
> The new version fixes a bug that incorrectly synchronized tags
> containing '%' characters.  It also fixes several build problems people
> reported.  Hence, the new version should work out of the box on more
> operating systems.

I noticed that the configure script didn't notice notmuch-devel was not
installed on my system.  I noticed it when the compilation failed.  Bug?

Besides that, I had a question.  I would like to synchronize just the
tags, not the maildirs, I want to use OfflineIMAP for that.  Is that
possible?

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

Re: ANNOUNCE: muchsync 1 - share notmuch DB across machines

[Suvayu Ali]

On Wed, Jun 10, 2015 at 11:36:15PM -0700, David Mazieres wrote:
 I've just released a new version of muchsync, the tool for replicating
 your notmuch database on multiple machines.  The source release is
 available at:
 
 http://www.muchsync.org/src/muchsync-1.tar.gz
 
 The new version fixes a bug that incorrectly synchronized tags
 containing '%' characters.  It also fixes several build problems people
 reported.  Hence, the new version should work out of the box on more
 operating systems.

I noticed that the configure script didn't notice notmuch-devel was not
installed on my system.  I noticed it when the compilation failed.  Bug?

Besides that, I had a question.  I would like to synchronize just the
tags, not the maildirs, I want to use OfflineIMAP for that.  Is that
possible?

Thanks,

-- 
Suvayu

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

Re: ANNOUNCE: muchsync 1 - share notmuch DB across machines

[Suvayu Ali]

On Fri, Jun 19, 2015 at 02:55:19PM -0700, David Mazieres wrote:
 Suvayu Ali fatkasuvayu+li...@gmail.com writes:
 
  I noticed that the configure script didn't notice notmuch-devel was not
  installed on my system.  I noticed it when the compilation failed.  Bug?
 
 What OS and distribution are you using?  notmuch-devel sounds like
 something a linux distribution might do, rather than anything that's
 part of notmuch itself.  On arch linux, for example, there's just a
 notmuch package that includes notmuch.
 
 Obviously there's no way to compile muchsync without notmuch installed.
 But if you elaborate on what it is you saw and what you would like to
 see I might be able to address it in the next release.

Sorry, I wasn't specific.  I'm on Fedora.  On Fedora, packages are split
into runtime dependencies and build dependencies.  So installing notmuch
will give you the notmuch binary as well as libnotmuch.  Whereas if you
want to compile, the you install notmuch-devel to get the headers.

When I ran the configure script, it failed couple of times.  The first
time it could not find sqlite headers, the second time I was missing
libcrypto related headers.  I installed sqlite-devel and openssl-devel
to resolve these.  The configure script succeeded after this, when it
should have failed since the notmuch headers were missing.  I realised
it when compilation failed.  Installing notmuch-devel resolved this.

  Besides that, I had a question.  I would like to synchronize just the
  tags, not the maildirs, I want to use OfflineIMAP for that.  Is that
  possible?
 
 Not really, no.  You could run offlineimap followed by muchsync, but you
 run the risk that mail will be delivered in the meantime.  You could
 also run offlineimap to fetch your mail in the first place, and then
 muchsync to sync it between your devices.
 
 Can I ask why you would want to do this, anyway?  Muchsync should be
 faster than notmuch, particularly if you have a lot of mail directories
 and/or are going to pay the cost of tag synchronization anyway.

I don't quite have a very reliable connection between my server 
laptop.  So I prefer to download my emails from the source, Gmail, at
both locations.  I usually read and respond to emails from my laptop,
but I do use the server sometimes.  So I only need to synchronise the
tags.  I also keep the server around to synchronize a few more maildirs,
the ones I read irregularly and would prefer does not occupy valuable
disk space on my laptop.

Cheers,

-- 
Suvayu

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

search query "replytoid:"

[Suvayu Ali]

Hi,

On Mon, Jun 15, 2015 at 12:30:57AM +0200, Gregor Zattler wrote:
> 
> This is a nice script.  The very first Message(-Id:) I tried was
> replied to by a message with this In-Reply-To: header:
> 
> In-Reply-To: <7e093509.51e.14ddb300091.Coremail.chxp_moon at 163.com> 
> (windy’s
>message of „Wed, 10 Jun 2015 09:57:45 +0800 (CST)“)
> 
> Since the script extracts Message-Id:s from In-Reply-To; headers via
> 
> > function strip_mid() {
> > sed -e 's/[<> ]//g'
> > }
> 
> the Message-Id:s did not match.  I therefore changed this to
> 
> function strip_mid() {
> egrep  -a -o "<[^[:space:]<>]+@[^@[:space:]<>]+>"|sed -e 's/[<> ]//g'
> }

It was a quick hack.  In fact, there is another limitation.  IIRC, I
think the In-Reply-To header can have multiple Message-Id-s.  That is
not handled at all!  

The correct logic to get the ids should probably be something that picks
out the content inside angular brackets, but non-greedily.  Note that,
the allowance of characters inside Message-ID-s is rather liberal.  I
think it can be anything other than whitespace or angular brackets.
What you do above is probably very close, but still not general enough.
In fact, I think the foo at domain structure you require is not mandatory!
In my opinion, one should use an email handling library, or better yet
use the python bindings.

For the sake of completeness, here is a pure sed solution:

  function strip_mid() {
  sed -e 's/ \+//g' -e 's/<\([^ <>]\+\)>/\1/g'
  }

;)

-- 
Suvayu

Open source is the future. It sets us free.

search query "replytoid:"

[Suvayu Ali]

On Sat, Jun 13, 2015 at 10:55:52PM +0200, Suvayu Ali wrote:
> On Sat, Jun 13, 2015 at 02:47:00PM -0400, Xu Wang wrote:
> > 
> > Is it possible to search based on which message ID a message
> > *responds* to? For example, suppose message id is MESSAGEID. I want to
> > find all emails that responded to MESSAGEID. How to enter such a query
> > into notmuch?
> 
> AFAIK, this is not possible.  Notmuch does not allow searching special
> headers.  You could probably write a script using the threads output
> format to get the thread, and then use formail to find the responses.

Try the attached script.  It accepts notmuch queries by message id.
E.g. to get the responses to your OP, you can do:

  $ ./nm-ack id:CAJhTkNhYew6H-bptACTew3gN3DLWg6agTYu8hAkdwFS=z4VFWg at 
mail.gmail.com
  id:877fr79upd.fsf at maritornes.cs.unb.ca id:20150613205552.GC17381 at 
chitra.no-ip.org

The first one is David's response, the second one is mine.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.
-- next part --
#!/bin/bash

# Return responses to message id query
#
# $ nm-ack id:msgid at domain
# id:response1 at domain1 id:response2 at domain2 ...
#
# Author: Suvayu Ali

# debug
# set -o xtrace

declare query="$1" thread=$(notmuch search --output=threads -- "$1")
declare -a msgs=$(notmuch search --output=messages -- "$thread") responses

function strip_mid() {
sed -e 's/[<> ]//g'
}

for m in ${msgs[@]}; do
[[ $query == $m ]] && continue
r=id:$(notmuch show --format=raw -- $m | formail -x In-Reply-To: | 
strip_mid)
[[ $query == $r ]] && responses+=($m)
done

echo ${responses[@]}

Re: search query replytoid:blah

[Suvayu Ali]

On Sat, Jun 13, 2015 at 10:55:52PM +0200, Suvayu Ali wrote:
 On Sat, Jun 13, 2015 at 02:47:00PM -0400, Xu Wang wrote:
  
  Is it possible to search based on which message ID a message
  *responds* to? For example, suppose message id is MESSAGEID. I want to
  find all emails that responded to MESSAGEID. How to enter such a query
  into notmuch?
 
 AFAIK, this is not possible.  Notmuch does not allow searching special
 headers.  You could probably write a script using the threads output
 format to get the thread, and then use formail to find the responses.

Try the attached script.  It accepts notmuch queries by message id.
E.g. to get the responses to your OP, you can do:

  $ ./nm-ack 
id:CAJhTkNhYew6H-bptACTew3gN3DLWg6agTYu8hAkdwFS=z4v...@mail.gmail.com
  id:877fr79upd@maritornes.cs.unb.ca 
id:20150613205552.gc17...@chitra.no-ip.org

The first one is David's response, the second one is mine.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.
#!/bin/bash

# Return responses to message id query
#
# $ nm-ack id:msgid@domain
# id:response1@domain1 id:response2@domain2 ...
#
# Author: Suvayu Ali

# debug
# set -o xtrace

declare query=$1 thread=$(notmuch search --output=threads -- $1)
declare -a msgs=$(notmuch search --output=messages -- $thread) responses

function strip_mid() {
sed -e 's/[ ]//g'
}

for m in ${msgs[@]}; do
[[ $query == $m ]]  continue
r=id:$(notmuch show --format=raw -- $m | formail -x In-Reply-To: | 
strip_mid)
[[ $query == $r ]]  responses+=($m)
done

echo ${responses[@]}
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: search query replytoid:blah

[Suvayu Ali]

Hi,

On Mon, Jun 15, 2015 at 12:30:57AM +0200, Gregor Zattler wrote:
 
 This is a nice script.  The very first Message(-Id:) I tried was
 replied to by a message with this In-Reply-To: header:
 
 In-Reply-To: 7e093509.51e.14ddb300091.coremail.chxp_m...@163.com 
 (windy’s
message of „Wed, 10 Jun 2015 09:57:45 +0800 (CST)“)
 
 Since the script extracts Message-Id:s from In-Reply-To; headers via
 
  function strip_mid() {
  sed -e 's/[ ]//g'
  }
 
 the Message-Id:s did not match.  I therefore changed this to
 
 function strip_mid() {
 egrep  -a -o [^[:space:]]+@[^@[:space:]]+|sed -e 's/[ ]//g'
 }

It was a quick hack.  In fact, there is another limitation.  IIRC, I
think the In-Reply-To header can have multiple Message-Id-s.  That is
not handled at all!  

The correct logic to get the ids should probably be something that picks
out the content inside angular brackets, but non-greedily.  Note that,
the allowance of characters inside Message-ID-s is rather liberal.  I
think it can be anything other than whitespace or angular brackets.
What you do above is probably very close, but still not general enough.
In fact, I think the foo@domain structure you require is not mandatory!
In my opinion, one should use an email handling library, or better yet
use the python bindings.

For the sake of completeness, here is a pure sed solution:

  function strip_mid() {
  sed -e 's/ \+//g' -e 's/\([^ ]\+\)/\1/g'
  }

;)

-- 
Suvayu

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

search query "replytoid:"

[Suvayu Ali]

Hi,

On Sat, Jun 13, 2015 at 02:47:00PM -0400, Xu Wang wrote:
> 
> Is it possible to search based on which message ID a message
> *responds* to? For example, suppose message id is MESSAGEID. I want to
> find all emails that responded to MESSAGEID. How to enter such a query
> into notmuch?

AFAIK, this is not possible.  Notmuch does not allow searching special
headers.  You could probably write a script using the threads output
format to get the thread, and then use formail to find the responses.

I however think you are probably approaching the problem incorrectly,
but that's just a guess.  More information about what is your goal and
why, would help.  Maybe there is another way to achieve what you want to
achieve.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Understanding the "replied" tag

[Suvayu Ali]

Hi,

On Sat, Jun 13, 2015 at 02:44:46PM -0400, Xu Wang wrote:
> 
> Thank you. The problem in the end is that I would like 'notmuch new'
> to not only schronize the 'reply' tag but to master handle the reply
> tag because notmuch knows which messages have been replied to (because
> it is aware of threads).

Sorry, I have no idea what you are saying.  It would help a lot if you
explicitly state what you tried, what you expected, and what you saw.
For example, you still haven't mentioned that you are using mutt-kz as
your MUA.  I know that because we had an earlier discussion on
mutt-users.  It is very hard to suggest something without knowing
precisely what you tried.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Understanding the replied tag

[Suvayu Ali]

Hi,

On Sat, Jun 13, 2015 at 02:44:46PM -0400, Xu Wang wrote:
 
 Thank you. The problem in the end is that I would like 'notmuch new'
 to not only schronize the 'reply' tag but to master handle the reply
 tag because notmuch knows which messages have been replied to (because
 it is aware of threads).

Sorry, I have no idea what you are saying.  It would help a lot if you
explicitly state what you tried, what you expected, and what you saw.
For example, you still haven't mentioned that you are using mutt-kz as
your MUA.  I know that because we had an earlier discussion on
mutt-users.  It is very hard to suggest something without knowing
precisely what you tried.

Cheers,

-- 
Suvayu

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

Re: search query replytoid:blah

[Suvayu Ali]

Hi,

On Sat, Jun 13, 2015 at 02:47:00PM -0400, Xu Wang wrote:
 
 Is it possible to search based on which message ID a message
 *responds* to? For example, suppose message id is MESSAGEID. I want to
 find all emails that responded to MESSAGEID. How to enter such a query
 into notmuch?

AFAIK, this is not possible.  Notmuch does not allow searching special
headers.  You could probably write a script using the threads output
format to get the thread, and then use formail to find the responses.

I however think you are probably approaching the problem incorrectly,
but that's just a guess.  More information about what is your goal and
why, would help.  Maybe there is another way to achieve what you want to
achieve.

Hope this helps,

-- 
Suvayu

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

Understanding the "replied" tag

[Suvayu Ali]

On Thu, Jun 11, 2015 at 01:25:44PM -0400, Xu Wang wrote:
> 
> I would really like to know if a message has been replied to (e.g.
> using a certain message id). It seems that all I need to do is check
> for the "replied" tag. But often this tag is not there, even when
> there has been a reply (I have confirmed this through the thread
> display and checking the message that replied to the message to make
> sure it indeed has header "replied-to:").

You do not give enough details, but I would guess you are probably
reading and replying emails from real maildirs in mutt-kz.  The
synchronising of notmuch tags and maildir flags happen correctly only
when you read and reply from virtual folders.  Of course they are
synchronised again when `notmuch new' is run the next time.  But until
such time, the tags and flags will not be in sync, if you are using real
folders instead of virtual folders.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Understanding the replied tag

[Suvayu Ali]

On Thu, Jun 11, 2015 at 01:25:44PM -0400, Xu Wang wrote:
 
 I would really like to know if a message has been replied to (e.g.
 using a certain message id). It seems that all I need to do is check
 for the replied tag. But often this tag is not there, even when
 there has been a reply (I have confirmed this through the thread
 display and checking the message that replied to the message to make
 sure it indeed has header replied-to:MSG-ID).

You do not give enough details, but I would guess you are probably
reading and replying emails from real maildirs in mutt-kz.  The
synchronising of notmuch tags and maildir flags happen correctly only
when you read and reply from virtual folders.  Of course they are
synchronised again when `notmuch new' is run the next time.  But until
such time, the tags and flags will not be in sync, if you are using real
folders instead of virtual folders.

Hope this helps,

-- 
Suvayu

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

[RFC] lib: add support for date:..! to mean date:..

[Suvayu Ali]

Hi,

On Fri, Apr 17, 2015 at 07:57:27PM +0100, Mark Walters wrote:
> 
> > 2) If yes, are there better alternatives to "!" as the end point? (Or
> > should the special case be the start point?) Also "@" and "same" have
> > been suggested. Examples: date:yesterday..! date:today..@
> > date:@..monday date:january..same.
> 
> I would be happy with any of these.

Many shells use ! for history expansion; maybe one of the other
characters would be better (no need to escape)?

I like @, purely aesthetic preference :).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: [RFC] lib: add support for date:query..! to mean date:query..query

[Suvayu Ali]

Hi,

On Fri, Apr 17, 2015 at 07:57:27PM +0100, Mark Walters wrote:
 
  2) If yes, are there better alternatives to ! as the end point? (Or
  should the special case be the start point?) Also @ and same have
  been suggested. Examples: date:yesterday..! date:today..@
  date:@..monday date:january..same.
 
 I would be happy with any of these.

Many shells use ! for history expansion; maybe one of the other
characters would be better (no need to escape)?

I like @, purely aesthetic preference :).

Cheers,

-- 
Suvayu

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

Unable to search for emails with content with a given MIME type

[Suvayu Ali]

Hi David,

On Wed, Feb 04, 2015 at 10:08:57PM +0100, David Bremner wrote:
> Suvayu Ali <fatkasuvayu+linux at gmail.com> writes:
> 
> > Hi,
> >
> > On Tue, Jan 27, 2015 at 08:01:31PM -0600, Todd wrote:
> >> 
> >> The feature you wanted was committed a few days ago (searching with a
> >> "mimetype:" prefix).  Searching for "mimetype:calendar" would get any
> >> "text/calendar" or "ics/calendar" attachments.
> >
> > I am using notmuch from HEAD, but I do not get any results with
> > mimetype:.  Is this only available for new emails?  If so, how do
> > I enable, searching with mimetype: for old emails?
> >
> 
> You'll have to dump your tags, re-index, and restore your tags.

I thought that might be needed.  It worked very nicely :).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Unable to search for emails with content with a given MIME type

[Suvayu Ali]

Hi,

On Tue, Jan 27, 2015 at 08:01:31PM -0600, Todd wrote:
> 
> The feature you wanted was committed a few days ago (searching with a
> "mimetype:" prefix).  Searching for "mimetype:calendar" would get any
> "text/calendar" or "ics/calendar" attachments.

I am using notmuch from HEAD, but I do not get any results with
mimetype:.  Is this only available for new emails?  If so, how do
I enable, searching with mimetype: for old emails?

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Unable to search for emails with content with a given MIME type

[Suvayu Ali]

Hi,

On Tue, Jan 27, 2015 at 08:01:31PM -0600, Todd wrote:
 
 The feature you wanted was committed a few days ago (searching with a
 mimetype: prefix).  Searching for mimetype:calendar would get any
 text/calendar or ics/calendar attachments.

I am using notmuch from HEAD, but I do not get any results with
mimetype:word.  Is this only available for new emails?  If so, how do
I enable, searching with mimetype: for old emails?

Thanks,

-- 
Suvayu

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

Re: Unable to search for emails with content with a given MIME type

[Suvayu Ali]

Hi David,

On Wed, Feb 04, 2015 at 10:08:57PM +0100, David Bremner wrote:
 Suvayu Ali fatkasuvayu+li...@gmail.com writes:
 
  Hi,
 
  On Tue, Jan 27, 2015 at 08:01:31PM -0600, Todd wrote:
  
  The feature you wanted was committed a few days ago (searching with a
  mimetype: prefix).  Searching for mimetype:calendar would get any
  text/calendar or ics/calendar attachments.
 
  I am using notmuch from HEAD, but I do not get any results with
  mimetype:word.  Is this only available for new emails?  If so, how do
  I enable, searching with mimetype: for old emails?
 
 
 You'll have to dump your tags, re-index, and restore your tags.

I thought that might be needed.  It worked very nicely :).

Cheers,

-- 
Suvayu

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

Looking for the perfect mail client

[Suvayu Ali]

Hi,

On Tue, Oct 21, 2014 at 12:42:39PM +0200, Simon Chopin wrote:
> Quoting Sepp Tannhuber (2014-10-21 12:02:37)
> 
> > - which doesn't need a mouse
> > - which is fast
> 
> That last point is my main problem with alot. There are some algorithms
> within the widgets that seem unobviously slow to me.

There is always mutt-kz, Mutt with Notmuch integrated.  I have been
using it for over a year now; no major issues.  I also maintain a Fedora
repository, in case someone wants to try.

http://copr-fe.cloud.fedoraproject.org/coprs/fatka/mutt-kz/
http://copr-fe.cloud.fedoraproject.org/coprs/fatka/notmuch/

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Looking for the perfect mail client

[Suvayu Ali]

Hi,

On Tue, Oct 21, 2014 at 12:42:39PM +0200, Simon Chopin wrote:
 Quoting Sepp Tannhuber (2014-10-21 12:02:37)
 
  - which doesn't need a mouse
  - which is fast
 
 That last point is my main problem with alot. There are some algorithms
 within the widgets that seem unobviously slow to me.

There is always mutt-kz, Mutt with Notmuch integrated.  I have been
using it for over a year now; no major issues.  I also maintain a Fedora
repository, in case someone wants to try.

http://copr-fe.cloud.fedoraproject.org/coprs/fatka/mutt-kz/
http://copr-fe.cloud.fedoraproject.org/coprs/fatka/notmuch/

Cheers,

-- 
Suvayu

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

SVG attachment crashes emacs

[Suvayu Ali]

On Wed, Aug 20, 2014 at 03:34:58PM +0200, Franz Fellner wrote:
> emacs-24.3 crashes (Gentoo version 24.3-r6)
> emacs-vcs-24.3.93 does NOT crash.
> So this issue seems to be fixed in recent snapshots/beta/whatever, but
> the fixed version is not released yet.

I don't know if people would call this a release, but the pretest has
been officially announced.

http://lists.gnu.org/archive/html/info-gnu-emacs/2014-08/msg0.html

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: SVG attachment crashes emacs

[Suvayu Ali]

On Wed, Aug 20, 2014 at 03:34:58PM +0200, Franz Fellner wrote:
 emacs-24.3 crashes (Gentoo version 24.3-r6)
 emacs-vcs-24.3.93 does NOT crash.
 So this issue seems to be fixed in recent snapshots/beta/whatever, but
 the fixed version is not released yet.

I don't know if people would call this a release, but the pretest has
been officially announced.

http://lists.gnu.org/archive/html/info-gnu-emacs/2014-08/msg0.html

Cheers,

-- 
Suvayu

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

emacs integration

[Suvayu Ali]

On Fri, May 23, 2014 at 04:02:16PM +0200, Gauthier ?stervall wrote:
> 
> I see, thank you. I am actually not interested in the source itself
> for now, I only attempted to get the emacs integration to work.
> I actually got notmuch via apt-get, and if I try to apt-get install
> notmuch-emacs, it says I have it already.
> So it seems I have notmuch-emacs installed, what I don't know is where
> to point emacs to for it to find this installation.
> 
> Now emacs seems to have found them somehow. I had a system restart in
> between, maybe that's what fixed it.
> After examining my load-path, I saw that
> /usr/share/emacs24/site-lisp/notmuch was added there.
> Who modified load-path, and how? I could see no environment variable
> about notmuch, maybe everything under site-lisp/ is added to load-path
> at each emacs start?

This is a standard way to deal with external packages in emacs.  The
setup stuff goes in the site start file.  The exact location is
distribution dependent, but generally it is something like
/usr/share/emacs/site-lisp/.

You should not worry about these details if you are using notmuch-emacs
as provided by your distribution.  Just put your personal configurations
in your ~/.emacs or better yet, use customize to set and save them.
Then `M-x notmuch RET' should get you started.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: emacs integration

[Suvayu Ali]

On Fri, May 23, 2014 at 04:02:16PM +0200, Gauthier Östervall wrote:
 
 I see, thank you. I am actually not interested in the source itself
 for now, I only attempted to get the emacs integration to work.
 I actually got notmuch via apt-get, and if I try to apt-get install
 notmuch-emacs, it says I have it already.
 So it seems I have notmuch-emacs installed, what I don't know is where
 to point emacs to for it to find this installation.
 
 Now emacs seems to have found them somehow. I had a system restart in
 between, maybe that's what fixed it.
 After examining my load-path, I saw that
 /usr/share/emacs24/site-lisp/notmuch was added there.
 Who modified load-path, and how? I could see no environment variable
 about notmuch, maybe everything under site-lisp/ is added to load-path
 at each emacs start?

This is a standard way to deal with external packages in emacs.  The
setup stuff goes in the site start file.  The exact location is
distribution dependent, but generally it is something like
/usr/share/emacs/site-lisp/.

You should not worry about these details if you are using notmuch-emacs
as provided by your distribution.  Just put your personal configurations
in your ~/.emacs or better yet, use customize to set and save them.
Then `M-x notmuch RET' should get you started.

Hope this helps,

-- 
Suvayu

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

Submodules for language bindings (was: Github?)

[Suvayu Ali]

On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> Suvayu Ali wrote:
> 
> > To explain my point with RPM specifics, if I were to
> > use separate spec files, python-notmuch would have:
> > 
> >   Requires: notmuch >= 
> > 
> > As you can see this only allows for tracking dependency based on
> > official version numbers.  With more bindings, many with different
> > version dependencies, this becomes quite cumbersome;
> 
> No, it doesn't:
> 
>   %package notmuch-ruby
>   Requires: notmuch = %{version}-%{release}, ruby

Doesn't that work when you have one spec file for all sub-packages (as I
do now)?  I was responding to Trevor's suggestion about not having
sub-packages, IOW, different spec files for different packages.

-- 
Suvayu

Open source is the future. It sets us free.

Submodules for language bindings (was: Github?)

[Suvayu Ali]

Hi Trevor,

On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote:
> On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
> > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > > > One of my TODOs is to also package the ruby bindings, and
> > > > notmuch-vim.  The only thing preventing me now is my
> > > > unfamiliarty with ruby, and Fedora packaging guidelines for
> > > > ruby-gems.
> > > 
> > > I think this is one argument argument in favor of submodules,
> > > because they make it easy to treat the bindings as separate
> > > packages.  Once you have separate packages, it's easy to delegate
> > > packaging (e.g. ?I don't use the Ruby bindings, so I'm not going
> > > to maintain the Ruby-binding package.  I'll leave that to Alice,
> > > who likes Ruby, but is less familiar with $distro's Python
> > > packaging?).
> > 
> > Well as far as my understanding of rpm goes, sub-packages are
> > prefered here rather than independent packages.  I believe the
> > reason is again easier dependency tracking[1]; all sub-packages
> > share the same source rpm, so no explicit `Requires' in the spec
> > file.
> 
> It looks like sub-packages share a single spec file with the main
> package [1].  That means you'll have to have authors with the full
> range of binding-language expertise to bump that spec file (assuming
> there are any changes that require bumps).  For example, Gentoo's
> Python eclasses have gone through a few revisions in the last year or
> two, and I wouldn't expect one person to stay on top of the latest
> packaging styles for every language with notmuch bindings.  I think
> the benefit of having separate packages (and spec files, or ebuilds,
> or whatever) is that you can release notmuch-0.18 without worrying
> about all those bindings, and leave it to the other maintainers (who
> might include you) to independently package notmuch-python-0.18,
> notmuch-ruby-0.18, notmuch-go-0.18, ?.  With only three sets of
> bindings, it doesn't really matter, but I think you'll want the weaker
> coupling of stand-alone packages by the time you hit a dozen
> languages.  ?Bump an explicit 'Requires'? certainly seems like a lower
> barrier than ?package Go bindings idiomatically for Fedora? ;).

You have a point, however I would still disagree.  You seem to use
Gentoo, and I think what you say works better for Gentoo because it is a
source distribution.  For binary distributions, this is a bit harder
(and limiting).  To explain my point with RPM specifics, if I were to
use separate spec files, python-notmuch would have:

  Requires: notmuch >= 

As you can see this only allows for tracking dependency based on
official version numbers.  With more bindings, many with different
version dependencies, this becomes quite cumbersome; more so when you
are doing snapshots (as I do for my repo[1]).  As a packager, I think I
would prefer to learn different packaging guidelines, setup my spec file
and forget about it rather than continually follow all changes.  But I
guess this is where you would argue with different responsible people, I
would not have to do all the thinking :-p.

Anyway, whichever way the devs choose to go, I (and other packagers)
will adapt.

Cheers,


Footnotes:

[1] I would love to know if anyone here uses it.  I announced it here
when I started it, but for all I know I could be the only user!  :-p

-- 
Suvayu

Open source is the future. It sets us free.

Submodules for language bindings (was: Github?)

[Suvayu Ali]

On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
> On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
> > One of my TODOs is to also package the ruby bindings, and
> > notmuch-vim.  The only thing preventing me now is my unfamiliarty
> > with ruby, and Fedora packaging guidelines for ruby-gems.
> 
> I think this is one argument argument in favor of submodules, because
> they make it easy to treat the bindings as separate packages.  Once
> you have separate packages, it's easy to delegate packaging (e.g. ?I
> don't use the Ruby bindings, so I'm not going to maintain the
> Ruby-binding package.  I'll leave that to Alice, who likes Ruby, but
> is less familiar with $distro's Python packaging?).

Well as far as my understanding of rpm goes, sub-packages are prefered
here rather than independent packages.  I believe the reason is again
easier dependency tracking[1]; all sub-packages share the same source
rpm, so no explicit `Requires' in the spec file.

Cheers,

Footnotes:

[1] yum and it's ilk don't do that by magic, the packager needs to add
instructions in the spec file for that to work correctly.  With
sub-packages, this becomes redundant.

-- 
Suvayu

Open source is the future. It sets us free.

Github?

[Suvayu Ali]

On Thu, May 08, 2014 at 11:21:00PM +0200, guyzmo wrote:
> On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote:
> > On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
> > > On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
> > > wrote:
> [...]
> > > Can you guys at least consider splitting contrib/ and bindings/ into their
> > > own repo? It will make it easier for people to use the go bindings (for
> > > example) or to include the vim plugin as a submodule (or Vundle bundle).
> > 
> > What is the problem if contrib and bindings are part of the main repo?
> > In fact I would argue it is undesirable to split them.  If there are
> > major changes in libnotmuch, or the cli, it is much easier to make the
> > corresponding changes in bindings to keep everything working.  If there
> > is a separate repo, communicating this dependency, although not
> > impossible, is difficult.  I would also like to point out almost all
> > FOSS projects I follow, or contribute to practises this.
> 
> do you know about git submodules? It's actually there to be  able to
> track changes on remote repositories  that  are  closely  related, while
> keeping a sane separation.

I do, hence the "although not impossible".  It's still adding complexity
that is not needed for something like language bindings.  

What is so hard to package them when part of the project repo?  In fact,
I package notmuch along with its python bindings and a few utilities
from contrib for Fedora[1].  The default Fedora packages are horribly
outdated.  One of my TODOs is to also package the ruby bindings, and
notmuch-vim.  The only thing preventing me now is my unfamiliarty with
ruby, and Fedora packaging guidelines for ruby-gems.

Footnotes:

[1] 
http://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-20-x86_64/notmuch-0.18-5.20140506.git.8ecc7db3.fc20/


-- 
Suvayu

Open source is the future. It sets us free.

Re: Submodules for language bindings (was: Github?)

[Suvayu Ali]

Hi Trevor,

On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote:
 On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote:
  On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
   On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
One of my TODOs is to also package the ruby bindings, and
notmuch-vim.  The only thing preventing me now is my
unfamiliarty with ruby, and Fedora packaging guidelines for
ruby-gems.
   
   I think this is one argument argument in favor of submodules,
   because they make it easy to treat the bindings as separate
   packages.  Once you have separate packages, it's easy to delegate
   packaging (e.g. “I don't use the Ruby bindings, so I'm not going
   to maintain the Ruby-binding package.  I'll leave that to Alice,
   who likes Ruby, but is less familiar with $distro's Python
   packaging”).
  
  Well as far as my understanding of rpm goes, sub-packages are
  prefered here rather than independent packages.  I believe the
  reason is again easier dependency tracking[1]; all sub-packages
  share the same source rpm, so no explicit `Requires' in the spec
  file.
 
 It looks like sub-packages share a single spec file with the main
 package [1].  That means you'll have to have authors with the full
 range of binding-language expertise to bump that spec file (assuming
 there are any changes that require bumps).  For example, Gentoo's
 Python eclasses have gone through a few revisions in the last year or
 two, and I wouldn't expect one person to stay on top of the latest
 packaging styles for every language with notmuch bindings.  I think
 the benefit of having separate packages (and spec files, or ebuilds,
 or whatever) is that you can release notmuch-0.18 without worrying
 about all those bindings, and leave it to the other maintainers (who
 might include you) to independently package notmuch-python-0.18,
 notmuch-ruby-0.18, notmuch-go-0.18, ….  With only three sets of
 bindings, it doesn't really matter, but I think you'll want the weaker
 coupling of stand-alone packages by the time you hit a dozen
 languages.  “Bump an explicit 'Requires'” certainly seems like a lower
 barrier than “package Go bindings idiomatically for Fedora” ;).

You have a point, however I would still disagree.  You seem to use
Gentoo, and I think what you say works better for Gentoo because it is a
source distribution.  For binary distributions, this is a bit harder
(and limiting).  To explain my point with RPM specifics, if I were to
use separate spec files, python-notmuch would have:

  Requires: notmuch = version-string

As you can see this only allows for tracking dependency based on
official version numbers.  With more bindings, many with different
version dependencies, this becomes quite cumbersome; more so when you
are doing snapshots (as I do for my repo[1]).  As a packager, I think I
would prefer to learn different packaging guidelines, setup my spec file
and forget about it rather than continually follow all changes.  But I
guess this is where you would argue with different responsible people, I
would not have to do all the thinking :-p.

Anyway, whichever way the devs choose to go, I (and other packagers)
will adapt.

Cheers,


Footnotes:

[1] I would love to know if anyone here uses it.  I announced it here
when I started it, but for all I know I could be the only user!  :-p

-- 
Suvayu

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

Re: Submodules for language bindings (was: Github?)

[Suvayu Ali]

On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
 Suvayu Ali wrote:
 
  To explain my point with RPM specifics, if I were to
  use separate spec files, python-notmuch would have:
  
Requires: notmuch = version-string
  
  As you can see this only allows for tracking dependency based on
  official version numbers.  With more bindings, many with different
  version dependencies, this becomes quite cumbersome;
 
 No, it doesn't:
 
   %package notmuch-ruby
   Requires: notmuch = %{version}-%{release}, ruby

Doesn't that work when you have one spec file for all sub-packages (as I
do now)?  I was responding to Trevor's suggestion about not having
sub-packages, IOW, different spec files for different packages.

-- 
Suvayu

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

Github?

[Suvayu Ali]

Hi,

Disclaimer: I'm not a developer, just a user who follows the list.

On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
> On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
> wrote:
> 
> > Hi everyone,
> >
> > I didn't see the previous email about it, thank you Jani for the link. It
> > looks like you guys have your hands full and everything setup the way you
> > like it, so here's what I'll do myself (if it's acceptable with you,
> > otherwise I'll just remove everything):
> >
> > - Revert my changes (except for the CI)
> > - Set a cron job to update the mirror hourly for the Github user wanting
> > to fork.
> > - Remove the Issues, Pull Request and the Wiki
> > - Add a "mirror of .." to the description on top of the page
> > - Manually update the contrib/ bindings/ as they change in here and maybe
> > automate it later.
> >
> 
> Can you guys at least consider splitting contrib/ and bindings/ into their
> own repo? It will make it easier for people to use the go bindings (for
> example) or to include the vim plugin as a submodule (or Vundle bundle).

What is the problem if contrib and bindings are part of the main repo?
In fact I would argue it is undesirable to split them.  If there are
major changes in libnotmuch, or the cli, it is much easier to make the
corresponding changes in bindings to keep everything working.  If there
is a separate repo, communicating this dependency, although not
impossible, is difficult.  I would also like to point out almost all
FOSS projects I follow, or contribute to practises this.

Just my 2?.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Github?

[Suvayu Ali]

Hi,

Disclaimer: I'm not a developer, just a user who follows the list.

On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
 On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
 wael.nasredd...@gmail.comwrote:
 
  Hi everyone,
 
  I didn't see the previous email about it, thank you Jani for the link. It
  looks like you guys have your hands full and everything setup the way you
  like it, so here's what I'll do myself (if it's acceptable with you,
  otherwise I'll just remove everything):
 
  - Revert my changes (except for the CI)
  - Set a cron job to update the mirror hourly for the Github user wanting
  to fork.
  - Remove the Issues, Pull Request and the Wiki
  - Add a mirror of .. to the description on top of the page
  - Manually update the contrib/ bindings/ as they change in here and maybe
  automate it later.
 
 
 Can you guys at least consider splitting contrib/ and bindings/ into their
 own repo? It will make it easier for people to use the go bindings (for
 example) or to include the vim plugin as a submodule (or Vundle bundle).

What is the problem if contrib and bindings are part of the main repo?
In fact I would argue it is undesirable to split them.  If there are
major changes in libnotmuch, or the cli, it is much easier to make the
corresponding changes in bindings to keep everything working.  If there
is a separate repo, communicating this dependency, although not
impossible, is difficult.  I would also like to point out almost all
FOSS projects I follow, or contribute to practises this.

Just my 2¢.

Cheers,

-- 
Suvayu

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

Re: Github?

[Suvayu Ali]

On Thu, May 08, 2014 at 11:21:00PM +0200, guyzmo wrote:
 On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote:
  On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote:
   On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine
   wael.nasredd...@gmail.comwrote:
 [...]
   Can you guys at least consider splitting contrib/ and bindings/ into their
   own repo? It will make it easier for people to use the go bindings (for
   example) or to include the vim plugin as a submodule (or Vundle bundle).
  
  What is the problem if contrib and bindings are part of the main repo?
  In fact I would argue it is undesirable to split them.  If there are
  major changes in libnotmuch, or the cli, it is much easier to make the
  corresponding changes in bindings to keep everything working.  If there
  is a separate repo, communicating this dependency, although not
  impossible, is difficult.  I would also like to point out almost all
  FOSS projects I follow, or contribute to practises this.
 
 do you know about git submodules? It's actually there to be  able to
 track changes on remote repositories  that  are  closely  related, while
 keeping a sane separation.

I do, hence the although not impossible.  It's still adding complexity
that is not needed for something like language bindings.  

What is so hard to package them when part of the project repo?  In fact,
I package notmuch along with its python bindings and a few utilities
from contrib for Fedora[1].  The default Fedora packages are horribly
outdated.  One of my TODOs is to also package the ruby bindings, and
notmuch-vim.  The only thing preventing me now is my unfamiliarty with
ruby, and Fedora packaging guidelines for ruby-gems.

Footnotes:

[1] 
http://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-20-x86_64/notmuch-0.18-5.20140506.git.8ecc7db3.fc20/


-- 
Suvayu

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

Re: Submodules for language bindings (was: Github?)

[Suvayu Ali]

On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote:
 On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote:
  One of my TODOs is to also package the ruby bindings, and
  notmuch-vim.  The only thing preventing me now is my unfamiliarty
  with ruby, and Fedora packaging guidelines for ruby-gems.
 
 I think this is one argument argument in favor of submodules, because
 they make it easy to treat the bindings as separate packages.  Once
 you have separate packages, it's easy to delegate packaging (e.g. “I
 don't use the Ruby bindings, so I'm not going to maintain the
 Ruby-binding package.  I'll leave that to Alice, who likes Ruby, but
 is less familiar with $distro's Python packaging”).

Well as far as my understanding of rpm goes, sub-packages are prefered
here rather than independent packages.  I believe the reason is again
easier dependency tracking[1]; all sub-packages share the same source
rpm, so no explicit `Requires' in the spec file.

Cheers,

Footnotes:

[1] yum and it's ilk don't do that by magic, the packager needs to add
instructions in the spec file for that to work correctly.  With
sub-packages, this becomes redundant.

-- 
Suvayu

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

folder and path completely broken in HEAD?

[Suvayu Ali]

On Fri, May 02, 2014 at 09:57:49PM -0700, dm-list-email-notmuch at 
scs.stanford.edu wrote:
> 
> Worse, because of my poor performance, I was hoping to segregate
> messages by year.  So it would be:
> 
>   2013/.mail.class
>   2013/.mail.voicemail
>   2014/.mail.class
>   2014/.mail.voicemail
> 
> All the way back.  Now you are saying there will be no convenient way to
> match just the "mail.class" part without the year?  How very
> distressing.  Ugh.

If you are using shell commands, you can always use:

  $ notmuch count -- folder:201{3,4}/.mail.class

Not sure how to achieve the same from the Emacs UI (or other UIs).

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

folder and path completely broken in HEAD?

[Suvayu Ali]

Hello David,

On Fri, May 02, 2014 at 02:16:07PM -0700, David Mazieres expires 2014-07-31 PDT 
wrote:
> Mark Walters  writes:
> >
> > Before checking other things: have you run notmuch new? That's needed to
> > update the database. It is an irreversible update so notmuch-0.17 will
> > not work with the updated database.
> 
> No, I haven't.  Okay, so that must be it.  Sorry for bothering people.
> The discussion of the NEWS was a bit confusing, so I wanted to check it
> out.  I knew something had to be very wrong.
> 
> Weill the new primitives still allow me to group my mail hierarchically
> in searches?  The new man page is not totally clear on what is being
> matched.

Here are some examples:

  $ notmuch config get database.path
  /home/user/Mail
  $ notmuch count -- folder:Gmail/Tux
  5113
  $ notmuch count -- 'path:Gmail/**'
  87807

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: folder and path completely broken in HEAD?

[Suvayu Ali]

Hello David,

On Fri, May 02, 2014 at 02:16:07PM -0700, David Mazieres expires 2014-07-31 PDT 
wrote:
 Mark Walters markwalters1...@gmail.com writes:
 
  Before checking other things: have you run notmuch new? That's needed to
  update the database. It is an irreversible update so notmuch-0.17 will
  not work with the updated database.
 
 No, I haven't.  Okay, so that must be it.  Sorry for bothering people.
 The discussion of the NEWS was a bit confusing, so I wanted to check it
 out.  I knew something had to be very wrong.
 
 Weill the new primitives still allow me to group my mail hierarchically
 in searches?  The new man page is not totally clear on what is being
 matched.

Here are some examples:

  $ notmuch config get database.path
  /home/user/Mail
  $ notmuch count -- folder:Gmail/Tux
  5113
  $ notmuch count -- 'path:Gmail/**'
  87807

Hope this helps,

-- 
Suvayu

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

Re: folder and path completely broken in HEAD?

[Suvayu Ali]

On Fri, May 02, 2014 at 09:57:49PM -0700, 
dm-list-email-notm...@scs.stanford.edu wrote:
 
 Worse, because of my poor performance, I was hoping to segregate
 messages by year.  So it would be:
 
   2013/.mail.class
   2013/.mail.voicemail
   2014/.mail.class
   2014/.mail.voicemail
 
 All the way back.  Now you are saying there will be no convenient way to
 match just the mail.class part without the year?  How very
 distressing.  Ugh.

If you are using shell commands, you can always use:

  $ notmuch count -- folder:201{3,4}/.mail.class

Not sure how to achieve the same from the Emacs UI (or other UIs).

Hope this helps,

-- 
Suvayu

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

Matching subthreads

[Suvayu Ali]

Hi,

I was wondering if it is possible to match subthreads?  In my case, I
want to kill irrelevant subthreads in really long threads.  Is this
possible somehow?  I usually kill threads by tagging a message in the
thread "killed", then in post-new hook I tag any incoming message in
that thread the same.  However this procedure does not understand
subthreads.

I'm using mutt-kz (mutt with notmuch support using the library).

Thanks in advance.

-- 
Suvayu

Open source is the future. It sets us free.

how to specify notmuch colors in emacs24

[Suvayu Ali]

On Thu, Mar 06, 2014 at 02:24:51PM +0100, David Belohrad wrote:
> Dear All,
> 
> so far I'm changing some color faces programmatically:
> 
>   (setq notmuch-search-line-faces '(("deleted" . (:foreground "red"
>   :background "blue"))
>  ("unread" . (:foreground "DeepSkyBlue"))
>  ("flagged" . (:foreground "firebrick1"))
>  ))

I use custom-set-faces and themes for this kind of customisation.

> I recently upgraded to emacs24. I was using default shipped tango-dark
> theme. Then (because of VHDL mode I'm using) I have created a custom
> theme, and I'd like to 'backport' the piece of code above into the
> custom theme so it is in accordance with the philosophy of themes.
> 
> I have no idea how to specify it using the 'class approach',as e.g.
> 
>`(gnus-group-news-1 ((,class (:foreground ,plum-1
>`(gnus-group-news-1-low ((,class (:foreground ,plum-2
> 
> Any hint would be greatly appreciated

You could get some ideas from my theme.



Essentially it boils down to:

  ((type ) (class ) (min-colors ))

You can find the gory docs here: (info "(elisp) Defining Faces")

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: how to specify notmuch colors in emacs24

[Suvayu Ali]

On Thu, Mar 06, 2014 at 02:24:51PM +0100, David Belohrad wrote:
 Dear All,
 
 so far I'm changing some color faces programmatically:
 
   (setq notmuch-search-line-faces '((deleted . (:foreground red
   :background blue))
  (unread . (:foreground DeepSkyBlue))
  (flagged . (:foreground firebrick1))
  ))

I use custom-set-faces and themes for this kind of customisation.

 I recently upgraded to emacs24. I was using default shipped tango-dark
 theme. Then (because of VHDL mode I'm using) I have created a custom
 theme, and I'd like to 'backport' the piece of code above into the
 custom theme so it is in accordance with the philosophy of themes.
 
 I have no idea how to specify it using the 'class approach',as e.g.
 
`(gnus-group-news-1 ((,class (:foreground ,plum-1
`(gnus-group-news-1-low ((,class (:foreground ,plum-2
 
 Any hint would be greatly appreciated

You could get some ideas from my theme.

https://github.com/suvayu/.emacs.d/blob/master/themes/dark-emacs-theme.el

Essentially it boils down to:

  ((type type) (class color/monochrome/etc) (min-colors number))

You can find the gory docs here: (info (elisp) Defining Faces)

Hope this helps,

-- 
Suvayu

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

RPM repository for Fedora on copr

[Suvayu Ali]

Hi,

The notmuch packages available for Fedora are rather old.  So I have
been building my own packages for a while.  Today I discovered copr[1],
so I thought others might be interested in the packages.  I have based
the spec on the version used for Fedora with some changes.  I update the
package from time to time when I see interesting changes in the Git
repository.  You can find the repository information here:

  

I also have a repo for the mutt fork, mutt-kz.

  

Hope people like it :).

Cheers,


Footnotes:

[1] 

-- 
Suvayu

Open source is the future. It sets us free.

RPM repository for Fedora on copr

[Suvayu Ali]

Hi,

The notmuch packages available for Fedora are rather old.  So I have
been building my own packages for a while.  Today I discovered copr[1],
so I thought others might be interested in the packages.  I have based
the spec on the version used for Fedora with some changes.  I update the
package from time to time when I see interesting changes in the Git
repository.  You can find the repository information here:

  http://copr-fe.cloud.fedoraproject.org/coprs/fatka/notmuch/

I also have a repo for the mutt fork, mutt-kz.

  http://copr-fe.cloud.fedoraproject.org/coprs/fatka/mutt-kz/

Hope people like it :).

Cheers,


Footnotes:

[1] https://fedorahosted.org/copr/wiki/UserDocs#FAQ

-- 
Suvayu

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

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

[Suvayu Ali]

Hi David,

On Wed, Sep 04, 2013 at 07:25:09AM -0300, David Bremner wrote:
> David Belohrad  writes:
> 
> > is actually someone using notmuch deliver? i was thinking to use is as
> > my 'implementation' of emailing uses remote access via SSH. This one is
> > considerably slower (especially when slow uplink) than local access and
> > hence if notmuch-deliver would be in a shape, that would spare at least
> > some time when 'notmuch new' is invoked from remote.
> >
> 
> notmuch-deliver is replaced by notmuch insert

I presume notmuch insert is a CLI only feature?  Or is it available from
the library too?  I was thinking of this in the context of mutt-kz
storing records.

-- 
Suvayu

Open source is the future. It sets us free.

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

[Suvayu Ali]

Hi David,

On Wed, Sep 04, 2013 at 07:25:09AM -0300, David Bremner wrote:
 David Belohrad da...@belohrad.ch writes:
 
  is actually someone using notmuch deliver? i was thinking to use is as
  my 'implementation' of emailing uses remote access via SSH. This one is
  considerably slower (especially when slow uplink) than local access and
  hence if notmuch-deliver would be in a shape, that would spare at least
  some time when 'notmuch new' is invoked from remote.
 
 
 notmuch-deliver is replaced by notmuch insert

I presume notmuch insert is a CLI only feature?  Or is it available from
the library too?  I was thinking of this in the context of mutt-kz
storing records.

-- 
Suvayu

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

$(date ...)..$(date ...) request from Emacs

[Suvayu Ali]

Hello Bastien!

On Sat, Aug 24, 2013 at 01:49:48PM +0300, Tomi Ollila wrote:
> On Sat, Aug 24 2013, Bastien  wrote:
> 
> > Hi again,
> >
> > notmuch search $(date +%s -d 2009-10-01)..$(date +%s -d 2009-10-02)
> >
> > works wonders from the command line, but not from within Emacs:
> >
> > M-x notmuch-search RET $(date +%s -d 2009-10-01)..$(date +%s -d 2009-10-02)
> 
> there is no shell expansion done to the string... 
> 
> ... however
> 
> M-x notmuch-search RET date:2009-10-01..2009-10-02
> 
> should do it (provided you have at least notmuch 0.15 (or so))

To add to that, notmuch now also understands relative dates, and many
other date expressions.  Check out the 'Date and time search' section in
`man notmuch-search-terms'.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: $(date ...)..$(date ...) request from Emacs

[Suvayu Ali]

Hello Bastien!

On Sat, Aug 24, 2013 at 01:49:48PM +0300, Tomi Ollila wrote:
 On Sat, Aug 24 2013, Bastien b...@altern.org wrote:
 
  Hi again,
 
  notmuch search $(date +%s -d 2009-10-01)..$(date +%s -d 2009-10-02)
 
  works wonders from the command line, but not from within Emacs:
 
  M-x notmuch-search RET $(date +%s -d 2009-10-01)..$(date +%s -d 2009-10-02)
 
 there is no shell expansion done to the string... 
 
 ... however
 
 M-x notmuch-search RET date:2009-10-01..2009-10-02
 
 should do it (provided you have at least notmuch 0.15 (or so))

To add to that, notmuch now also understands relative dates, and many
other date expressions.  Check out the 'Date and time search' section in
`man notmuch-search-terms'.

Cheers,

-- 
Suvayu

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

Aliases in notmuch queries

[Suvayu Ali]

Hi,

I was wondering if it is possible to have email/name aliases of some
kind when performing notmuch queries.

I work in a very international environment.  It is quite common for
people with complicated names to go by simpler nicknames (e.g. Greek,
Russian, Chinese names).

Often when searching for messages from these collaborators, I realise I
cannot recall their real names (or cannot spell it correctly).  It would
be great if notmuch had a facility to map nicknames to real names;
something like what git does with .mailmap.

Does something like this exist?  If not, is it feasible?  I think it
would be a great addition.

Thanks,

-- 
Suvayu

Open source is the future. It sets us free.

notmuch search --output=files error with AND NOT search terms

[Suvayu Ali]

Hi Ingo,

Disclaimer: I'm just a user, with almost no knowledge of notmuch
internals.

On Thu, Jul 11, 2013 at 01:39:20AM -0700, ingo wrote:
> 
> And both mails have the same message-id in the message header. 
> 
> Still, only one of both files really should be found with this search, so
> why is the out put different?

If there are multiple copies of a message, I would expect --output=files
to show all the copies (files).  I believe this is notmuch's way to
handle duplicate messages.  I think the confusion arises from the notion
of treating unique message id, and not unique physical files as the
definition of a message.  If you think a bit, seems reasonable too.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

notmuch search --output=files error with AND NOT search terms

[Suvayu Ali]

Hi Ingo,

On Wed, Jul 10, 2013 at 04:55:13AM -0700, ingo wrote:
> Mark Walters wrote
> > 
> > The most likely cause is that these two messagefiles have the same
> > message-ids (so in notmuch's view are the same message). Try
> > 
> > notmuch search --output=messages  folder:1_Personal AND NOT tag:1_Personal
> > 
> > If you only see one message-id then notmuch thinks there is a single
> > message
> > that matches the search. The way notmuch works is that it first finds
> > which messages match and then prints the requested information for those
> > messages. So in this case it finds the matching message(s) then prints
> > all filenames for those matching messages.
> 
> Hi Mark,
> 
> thank you for your answer, actually I only get one single message id, the
> one I get without using --output=files.
> 
> notmuch search --output=messages  folder:1_Personal AND NOT tag:1_Personal 
> id:f76b9be792c46795945e1486ccb2b2ab at www.kikidan.com

Doesn't that confirm Mark's explanation?  Notmuch sees multiple files
associated to the same message (identified by the message id).

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

the future of notmuch-vim?

[Suvayu Ali]

On Wed, Apr 03, 2013 at 03:09:39AM -0600, Felipe Contreras wrote:
> guyzmo wrote:
> 
> > I  personnally  prefer a thousand times to use mutt-kz, alot as MUA,  and
> > vim  only  for writing mails.

[...]

> I've tried mutt-kz and alot, and I was utterly dissapointed by both.
> 
> See how snappy and fast notmuch-vim-ruby is[1], alot is much worst in these
> respects.
> 
> [1] http://www.youtube.com/watch?v=JGD7IbZmnIs

I'm a mutt-kz user, and I am not a vim user.  That said, I agree with
you that both mutt-kz and alot can be slow to start.  Opening virtual
folders in mutt-kz is quite slow compared to regular maildirectories.
And there seems to be no solution yet.  For example you can see this
message from Karel:



-- 
Suvayu

Open source is the future. It sets us free.

Re: the future of notmuch-vim?

[Suvayu Ali]

On Wed, Apr 03, 2013 at 03:09:39AM -0600, Felipe Contreras wrote:
 guyzmo wrote:
 
  I  personnally  prefer a thousand times to use mutt-kz, alot as MUA,  and
  vim  only  for writing mails.

[...]

 I've tried mutt-kz and alot, and I was utterly dissapointed by both.
 
 See how snappy and fast notmuch-vim-ruby is[1], alot is much worst in these
 respects.
 
 [1] http://www.youtube.com/watch?v=JGD7IbZmnIs

I'm a mutt-kz user, and I am not a vim user.  That said, I agree with
you that both mutt-kz and alot can be slow to start.  Opening virtual
folders in mutt-kz is quite slow compared to regular maildirectories.
And there seems to be no solution yet.  For example you can see this
message from Karel:

http://lists.fedoraproject.org/pipermail/mutt-kz/2013-April/000138.html

-- 
Suvayu

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

How to get thread id in emacs ui?

[Suvayu Ali]

On Mon, Feb 18, 2013 at 04:05:26PM +0100, Rainer M Krug wrote:
> On 18/02/13 15:42, David Bremner wrote:
> > Rainer M Krug  writes:
> >> 
> >>> By the way, the library org-notmuch distributed with org-mode should make 
> >>> it easy to link
> >>> into notmuch.
> >> 
> >> Then I probably haven't loaded org-notmuch properly? What do I have to put 
> >> into my .emacs
> >> file to load it properly?
> >> 
> > 
> > I put what I know at
> > 
> > http://notmuchmail.org/emacstips/#index24h2
> 
> Thanks - got it working under Ubuntu. One thing: in my org from git, 
> org-notmuch is in
> .../org-mode/contrib/lisp and not .../lisp

My following comment is probably OT, but still ...

If you install org-mode from git following the instructions from the
Makefile, then you should be putting something like the following in
your local.mk.

  # Define if you want to include some (or all) files from contrib/lisp
  # just the filename please (no path prefix, no .el suffix), maybe with
  # globbing
  ORG_ADD_CONTRIB = org-notmuch

If you do that, then David's instructions are accurate.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

How to get thread id in emacs ui?

[Suvayu Ali]

Hello again Rainer,

On Mon, Feb 18, 2013 at 03:05:49PM +0100, Rainer M Krug wrote:
> On 18/02/13 14:36, Suvayu Ali wrote:
> > On Mon, Feb 18, 2013 at 02:21:30PM +0100, Rainer M Krug wrote:
> >> 
> >> I am using notmuch in emacs, and I linkt from my notes in org mode to 
> >> emails using the
> >> thread: id or the message id. Is there a possibility to get these from 
> >> within emacs, or do I
> >> have to go to the cli from notmuch?
> >> 
> > 
> > As far as I'm aware, org-notmuch does all that for you.
> 
> Actually, you might be right. But then it seems, I somehow haven't loaded 
> org-notmuch.el properly
> - - I guess I am miaaing something at this step.
> 
> But it also seems that org-notmuch-search-store-link stores the search string 
> and not the thread
> or message id?
> 

AFAIU, it does that when you call org-store-link in a search buffer.  If
you do that in the message buffer, it stores the message id.

>From the search buffer:

[[notmuch-search:from:myfriend%2520is:inbox][Notmuch search: from:myfriend 
is:inbox]]

>From the message buffer:

[[notmuch:id:C8BF5B7C-6F2E-4754-B27D-A828D894B7EA at gmail.com][Email from 
Myfriend]]

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

How to get thread id in emacs ui?

[Suvayu Ali]

On Mon, Feb 18, 2013 at 02:21:30PM +0100, Rainer M Krug wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi
> 
> I am using notmuch in emacs, and I linkt from my notes in org mode to emails 
> using the thread: id
> or the message id. Is there a possibility to get these from within emacs, or 
> do I have to go to
> the cli from notmuch?
> 

As far as I'm aware, org-notmuch does all that for you.  Do you need it
for something else?  You can always look at org-notmuch source.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: How to get thread id in emacs ui?

[Suvayu Ali]

On Mon, Feb 18, 2013 at 02:21:30PM +0100, Rainer M Krug wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi
 
 I am using notmuch in emacs, and I linkt from my notes in org mode to emails 
 using the thread: id
 or the message id. Is there a possibility to get these from within emacs, or 
 do I have to go to
 the cli from notmuch?
 

As far as I'm aware, org-notmuch does all that for you.  Do you need it
for something else?  You can always look at org-notmuch source.

Cheers,

-- 
Suvayu

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

Re: How to get thread id in emacs ui?

[Suvayu Ali]

Hello again Rainer,

On Mon, Feb 18, 2013 at 03:05:49PM +0100, Rainer M Krug wrote:
 On 18/02/13 14:36, Suvayu Ali wrote:
  On Mon, Feb 18, 2013 at 02:21:30PM +0100, Rainer M Krug wrote:
  
  I am using notmuch in emacs, and I linkt from my notes in org mode to 
  emails using the
  thread: id or the message id. Is there a possibility to get these from 
  within emacs, or do I
  have to go to the cli from notmuch?
  
  
  As far as I'm aware, org-notmuch does all that for you.
 
 Actually, you might be right. But then it seems, I somehow haven't loaded 
 org-notmuch.el properly
 - - I guess I am miaaing something at this step.
 
 But it also seems that org-notmuch-search-store-link stores the search string 
 and not the thread
 or message id?
 

AFAIU, it does that when you call org-store-link in a search buffer.  If
you do that in the message buffer, it stores the message id.

From the search buffer:

[[notmuch-search:from:myfriend%2520is:inbox][Notmuch search: from:myfriend 
is:inbox]]

From the message buffer:

[[notmuch:id:c8bf5b7c-6f2e-4754-b27d-a828d894b...@gmail.com][Email from 
Myfriend]]

Hope this helps,

-- 
Suvayu

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

Re: How to get thread id in emacs ui?

[Suvayu Ali]

On Mon, Feb 18, 2013 at 04:05:26PM +0100, Rainer M Krug wrote:
 On 18/02/13 15:42, David Bremner wrote:
  Rainer M Krug r.m.k...@gmail.com writes:
  
  By the way, the library org-notmuch distributed with org-mode should make 
  it easy to link
  into notmuch.
  
  Then I probably haven't loaded org-notmuch properly? What do I have to put 
  into my .emacs
  file to load it properly?
  
  
  I put what I know at
  
  http://notmuchmail.org/emacstips/#index24h2
 
 Thanks - got it working under Ubuntu. One thing: in my org from git, 
 org-notmuch is in
 .../org-mode/contrib/lisp and not .../lisp

My following comment is probably OT, but still ...

If you install org-mode from git following the instructions from the
Makefile, then you should be putting something like the following in
your local.mk.

  # Define if you want to include some (or all) files from contrib/lisp
  # just the filename please (no path prefix, no .el suffix), maybe with
  # globbing
  ORG_ADD_CONTRIB = org-notmuch

If you do that, then David's instructions are accurate.

Hope this helps,

-- 
Suvayu

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

notmuch-mutt: Use of uninitialized value.

[Suvayu Ali]

Hi Kevin and others,

On Thu, Feb 14, 2013 at 03:06:51PM -0800, Kevin J. McCarthy wrote:
> 
> Here are some proposed improved macros.  (I'll attach a patch file in
> another email.)  Despite my earlier warning about not line-breaking
> macros, these are getting a bit unreadable.  We may want to see
> if/where we can safely line-break them.

I find sticking by the rule "do not introduce whitespaces to make it
readable" very useful in multi-line macros.  For example,

macro index  "some text\
continuation"

the above is preferable over,

macro index  "some text \
   continuation"

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

notmuch-mutt: Use of uninitialized value.

[Suvayu Ali]

On Thu, Feb 14, 2013 at 09:37:13AM +0100, Stefano Zacchiroli wrote:
> 
> I guess it would also be nice to actually disable $pipe_decode in the
> relevant Mutt macros, but I'm not sure about to do that without
> interfering with user desired configuration. Kevin: do you know if there
> is a common Mutt trick to store the value of a variable before changing
> it, and restoring it a posteriori?  More isolation for this kind of
> things in Mutt would definitely be welcome...

This should work:

"set my_var=$varunset var\
\
set var=$my_var"

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: notmuch-mutt: Use of uninitialized value.

[Suvayu Ali]

On Thu, Feb 14, 2013 at 09:37:13AM +0100, Stefano Zacchiroli wrote:
 
 I guess it would also be nice to actually disable $pipe_decode in the
 relevant Mutt macros, but I'm not sure about to do that without
 interfering with user desired configuration. Kevin: do you know if there
 is a common Mutt trick to store the value of a variable before changing
 it, and restoring it a posteriori?  More isolation for this kind of
 things in Mutt would definitely be welcome...

This should work:

enter-commandset my_var=$varenterenter-commandunset varenter\
do-your-stuff\
enter-commandset var=$my_varenter

Hope this helps,

-- 
Suvayu

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

Re: notmuch-mutt: Use of uninitialized value.

[Suvayu Ali]

Hi Kevin and others,

On Thu, Feb 14, 2013 at 03:06:51PM -0800, Kevin J. McCarthy wrote:
 
 Here are some proposed improved macros.  (I'll attach a patch file in
 another email.)  Despite my earlier warning about not line-breaking
 macros, these are getting a bit unreadable.  We may want to see
 if/where we can safely line-break them.

I find sticking by the rule do not introduce whitespaces to make it
readable very useful in multi-line macros.  For example,

macro index key some-long-functionsome textanother-function\
continuationfinally-the-end

the above is preferable over,

macro index key some-long-functionsome textanother-function \
   continuationfinally-the-end

Hope this helps,

-- 
Suvayu

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

Reply all - issue

[Suvayu Ali]

On Mon, Feb 04, 2013 at 11:39:44AM +0100, Micha? Nazarewicz wrote:
> 2 lut 2013 17:21, "Robert Mast"  napisa?(a):
> > Anyone interested in me patching Notmuch, or shall I keep the changes to
> myself?
> 
> I was actually wondering that instead of hard coding the logic into notmuch
> itself, maybe it would be better to provide some sort of "split-thread" and
> "join-threads" which could than be used by separate tagging tool.
> 
> To be user-friendly this may require a possibly to search for all ancestors
> of a given message and possibly an option to sort results topologically
> which I dunno if notmuch has.

This would be a wonderful addition.  :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: Reply all - issue

[Suvayu Ali]

On Mon, Feb 04, 2013 at 11:39:44AM +0100, Michał Nazarewicz wrote:
 2 lut 2013 17:21, Robert Mast beheer...@tekenbeetziekten.nl napisał(a):
  Anyone interested in me patching Notmuch, or shall I keep the changes to
 myself?
 
 I was actually wondering that instead of hard coding the logic into notmuch
 itself, maybe it would be better to provide some sort of split-thread and
 join-threads which could than be used by separate tagging tool.
 
 To be user-friendly this may require a possibly to search for all ancestors
 of a given message and possibly an option to sort results topologically
 which I dunno if notmuch has.

This would be a wonderful addition.  :)

-- 
Suvayu

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

Reply all - issue

[Suvayu Ali]

Hi,

I am a *very new* notmuch user (notmuch + mutt-kz/Emacs), but I would
like to throw in a few opinions about this topic.

On Wed, Jan 30, 2013 at 06:14:48PM +0100, Robert Mast wrote:
> Thanks for your clear explanation.
> 
> The thread-merging and breaking is in the procedure already pointed at by
> Jani: (_notmuch_database_link_message() in lib/database.cc.)
> 
> Is there a quick way to recognize those git-threads by subject-syntax, or to
> reliably tag them to exclude them from subject-breaking?
> 

I don't like this feature at all.  Threads with patches from
git-send-email are not the only kind of threads where this might be
relevant.  Often I encounter threads with sub-threads which are a little
OT hence get renamed, but they are still related to the parent thread.
Sometimes this helps in following how a topic came up while discussing
something else.  This is especially true when going through old emails
for reference.  I have encountered this in mailing lists, personal
emails and discussions with colleagues.  One of the many other reasons
for me to switch from Gmail to my present setup was to avoid this
"feature".

That said, I think this feature is indeed useful at times but it should
be implemented in the UI on user command or as a configurable (e.g. mutt
provides the  command), not a default underlying behaviour
of the backend.  If this is pursued, implementing it as a configurable
in the Emacs UI might be more appropriate (or whatever other UIs exists
out there).

Hope this is constructive to the discussion.  :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Reply all - issue

[Suvayu Ali]

Hi,

I am a *very new* notmuch user (notmuch + mutt-kz/Emacs), but I would
like to throw in a few opinions about this topic.

On Wed, Jan 30, 2013 at 06:14:48PM +0100, Robert Mast wrote:
 Thanks for your clear explanation.
 
 The thread-merging and breaking is in the procedure already pointed at by
 Jani: (_notmuch_database_link_message() in lib/database.cc.)
 
 Is there a quick way to recognize those git-threads by subject-syntax, or to
 reliably tag them to exclude them from subject-breaking?
 

I don't like this feature at all.  Threads with patches from
git-send-email are not the only kind of threads where this might be
relevant.  Often I encounter threads with sub-threads which are a little
OT hence get renamed, but they are still related to the parent thread.
Sometimes this helps in following how a topic came up while discussing
something else.  This is especially true when going through old emails
for reference.  I have encountered this in mailing lists, personal
emails and discussions with colleagues.  One of the many other reasons
for me to switch from Gmail to my present setup was to avoid this
feature.

That said, I think this feature is indeed useful at times but it should
be implemented in the UI on user command or as a configurable (e.g. mutt
provides the break-thread command), not a default underlying behaviour
of the backend.  If this is pursued, implementing it as a configurable
in the Emacs UI might be more appropriate (or whatever other UIs exists
out there).

Hope this is constructive to the discussion.  :)

Cheers,

-- 
Suvayu

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

Linking to emails via notmuch

[Suvayu Ali]

On Wed, Jan 23, 2013 at 01:32:42PM +0100, Rainer M Krug wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi
> 
> I would like to cross-reference emails via notmuch, i.e. I would like to 
> include a link to an
> email in a git commit message (this is a private gip repo and I am the only 
> developer and
> committer, so no problem from that side). Is it possible to get a link to an 
> email which, when
> clicked in emacs, opens the corresponding email using notmuch? Or should I 
> use a different approach?
> 

You can take a look at how org-notmuch handles this and try something
similar.

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Linking to emails via notmuch

[Suvayu Ali]

On Wed, Jan 23, 2013 at 01:32:42PM +0100, Rainer M Krug wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi
 
 I would like to cross-reference emails via notmuch, i.e. I would like to 
 include a link to an
 email in a git commit message (this is a private gip repo and I am the only 
 developer and
 committer, so no problem from that side). Is it possible to get a link to an 
 email which, when
 clicked in emacs, opens the corresponding email using notmuch? Or should I 
 use a different approach?
 

You can take a look at how org-notmuch handles this and try something
similar.

Hope this helps,

-- 
Suvayu

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

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

[Suvayu Ali]

Hi Justus,

I finally had time to go through your response carefully.

On Mon, Oct 15, 2012 at 12:58:30PM +0200, Justus Winter wrote:
 
---
[~] 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 module
  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

[...]

  As mentioned before, I think you invalidate the Database object concurrently
  while your long-running algorithm goes through all messages.
  Xapian doesn't handle concurrent access to the index like a normal™ 
  database would.
  This means you are notified by this error that some changes were detected.
  Maybe the error message should be more telling here though. Teythoon?
 
 The reason for this error is exactly what the error message says, you
 are opening to many files. Check out this limit using ulimit -n:
 
 % ulimit -n
 4096
 
 This problem is subtle. Here is a minimal test case:
 
 ~~~ snip ~~~
 import notmuch
 
 with notmuch.Database() as db:
 query = notmuch.Query(db, 'a').search_messages()
 for msg in query:
 msg.get_header('from')
 
 with notmuch.Database() as db:
 query = notmuch.Query(db, 'a').search_messages()
 for msg in list(query):
 msg.get_header('from')
 ~~~ snap ~~~
 
 % python test.py
 Error opening 
 /home/teythoon/Maildir/.lists.notmuch/cur/1323251462.M53044P18514.thinkbox,S=7306,W=7466:2,:
  Too many open files
 Traceback (most recent call last):
   File test.py, line 11, in module
 msg.get_header('from')
   File 
 /home/teythoon/.local/lib/python2.7/site-packages/notmuch/message.py, line 
 237, in get_header
 raise NullPointerError()
 notmuch.errors.NullPointerError
 
 Observe that it blows up in line 11, the first version works. The only
 difference is that the second version creates a list from the notmuch
 query. This prevents the garbage collector from collecting the message
 objects and thus closing the file handles. So here's your fix:
 
 ~~~ snip ~~~
 diff --git a/nbook b/nbook
 index 387c71d..b3d4fd6 100755
 --- a/nbook
 +++ b/nbook
 @@ -173,7 +173,7 @@ class AddressHeaders(object):
  # Search
  db = Database()
  query = Query(db, 'from:{0} or to:{0}'.format(querystr))
 -msgs = list(query.search_messages())
 +msgs = query.search_messages()
  
  addresses = AddressHeaders(msgs, querystr)
  print addresses
 ~~~ snap ~~~
 

This explanation helped me a lot, thanks!

 A few more comments:
 
  from notmuch import *
 
 Please avoid * imports, they prevent tools like pyflakes from checking
 whether you accidentally misspelled any identifiers.
 

Point taken.  I'll be more careful in the future.  :)

  pyversion = float('%d.%d' % (sys.version_info.major, 
  sys.version_info.minor))
  if pyversion  2.7:
 
 Converting this to float feels wrong. Consider doing sth like
 
 if sys.version_info.major  2 or (sys.version_info.major == 2 and 
 sys.version_info.minor = 7):
 

I incorporated these suggestions too.

  print '`nbook\' needs Python 2.7 or higher for argparse'
 
 Note that in py3k print is a function and not a statement, so you need
 to use braces. Consider dropping this at the beginning of all your
 python files to make py2.7 use the new features:
 
 from __future__ import print_function, absolute_import, unicode_literals
 
  exit(-1)
 
 exit is not a builtin function. You have to use sys.exit. Tools like
 pyflakes can spot this kind of mistakes. Also, sys.exit also accepts a
 string as argument which it prints to stderr before exiting with an
 error code.
 

I will read-up some more about the above suggestions and update
accordingly.

  self.__fromhdr__ += ',' + msg.get_header('from')
 
 Hm, this is somewhat unpythonic. It used to be the case that building
 strings this way was a lot slower than building a list and then
 joining it on a delimiter of your choice
 (i.e. ','.join(from_headers)). This is (was?) because strings are
 immutable in python and constantly creating strings just to throw them
 away in the next iteration puts a lot of pressure on the memory
 management system. Somewhat recent discussion here:
 
 http://stackoverflow.com/questions/1316887/what-is-the-most-efficient-string-concatenation-method-in-python
 

I had a commit with ','.join(..) in a private branch, but thanks for
pointing out the reasons and the links to the discussion.  This was very
helpful.

  def print_addrs(self, fmtstr='', query=''):
  if '' == fmtstr: fmtstr = '%s%s\n'
 
 Ok, several things here:
 
 * The comparison looks weird, you are using the string constant as the
   first operand. While this is technically not wrong, it is 

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

[Suvayu Ali]

Hello Patrick,

On Sat, Oct 13, 2012 at 05:58:51PM +0100, Patrick Totzke wrote:
 Quoting Suvayu Ali (2012-10-08 10:34:29)
  
   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.
  
  Since the idea was inspired by the completion on the Gmail web
  interface, I already do a partial search so wildcards should not be
  necessary.
 
 Not sure what you mean here: If I compose a mail using gmails web interface
 and type a prefix of someone's name I will get this contect as a suggestion.
 My point was that using your tool, I did not get a contact suggested
 for all prefixes.
 

What I meant was, I search for *query* in the name or email address
strings.  So adding a glob character is not needed; in fact adding it
would mean my algorithm would search for a literal * and fail.

[...]

 
 I think this is a conceptual problem with your algorithm:
 You look up *all* messages and add a name to your result-list
 if it matches. This means you go through some condidate
 as often as you index contains mails from/to him.
 What one really wants is to ask the database to do something like
   SELECT name,email from RECIPIENTS_OR_SENDER
 where RECIPIENTS_OR_SENDER is some imaginary list that stores
 a set of contacts.
 
 Bottom line: One would have to change the layout of the underlying
 database (not likely) or do regularly update some cache
 and only work on that. This is what some of the mentioned tools do if i'm not 
 mistaken.
 

Yes, you are right.  I realised this too when I tried out
nottoomuch-address a few days back.  Caching seems to be the solution
for performance issues.

[...]

   ---
   [~] 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 module
 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

[...]

I see in the meantime I was writing this email, Justus gave an
explanation for the issue; I'll go through the response carefully.

 
 https://github.com/teythoon/afew
 https://github.com/pazz/alot
 http://excess.org/urwid/
 
 I'm sure patches will be welcome to any of the above :)

Al 3 seem very interesting, but I think I will take a closer look at
afew and urwid.

Thanks for the pointers,

:)

-- 
Suvayu

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

nbook: a notmuch based address book written in python

[Suvayu Ali]

Hi Patrick,

Sorry for the very late reply; I got distracted with some personal
matters.

On Tue, Sep 25, 2012 at 11:44:57AM +0100, Patrick Totzke wrote:
> 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.
> 

I wasn't aware of either of them, thanks for pointing them out.  I'll
take a look for inspiration and ideas.

> 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.

Since the idea was inspired by the completion on the Gmail web
interface, I already do a partial search so wildcards should not be
necessary.

> 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
> ---

Yes, I noticed this too when I searched for the more common names.  Not
sure how to get around this though.

> 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
> 
> 

Yes someone else pointed this out too.  Again I'm not sure how to
proceed here.  I had a quick look at this last week and it seemed to me
the limitation comes from within the python bindings for notmuch.  Do
you have any ideas?

> 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

That would be wonderful.  To give you my background, I'm a graduate
student in physics and I have to do a lot of C/C++ and python
programming for my research.  Contributing to FOSS projects seems like a
wonderful way to learn to collaborate and clean programming (we
physicists tend to be sloppy programmers :-p).

> Best,
> /p

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

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

[Suvayu Ali]

Hi Patrick,

Sorry for the very late reply; I got distracted with some personal
matters.

On Tue, Sep 25, 2012 at 11:44:57AM +0100, Patrick Totzke wrote:
 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.
 

I wasn't aware of either of them, thanks for pointing them out.  I'll
take a look for inspiration and ideas.

 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.

Since the idea was inspired by the completion on the Gmail web
interface, I already do a partial search so wildcards should not be
necessary.

 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
 ---

Yes, I noticed this too when I searched for the more common names.  Not
sure how to get around this though.

 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 module
   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 module
   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
 
 

Yes someone else pointed this out too.  Again I'm not sure how to
proceed here.  I had a quick look at this last week and it seemed to me
the limitation comes from within the python bindings for notmuch.  Do
you have any ideas?

 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

That would be wonderful.  To give you my background, I'm a graduate
student in physics and I have to do a lot of C/C++ and python
programming for my research.  Contributing to FOSS projects seems like a
wonderful way to learn to collaborate and clean programming (we
physicists tend to be sloppy programmers :-p).

 Best,
 /p

Cheers,

-- 
Suvayu

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

nbook: a notmuch based address book written in python

[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] https://github.com/suvayu/nbook

-- 
Suvayu

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

nbook: a notmuch based address book written in python

[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.