Re: Possible some threads are not complete due to bug?
On Sun, Oct 4, 2015 at 6:57 AM, David Bremner wrote: > Xu Wang writes: > >> >> $ notmuch search --output=threads "id:MYMSGID" >> thread:a125 >> $ notmuch search --output=messages "thread:a125" >> id:MYMSGID >> $ >> # I know that MYMSGIDREPLY did respond to that message. I have it in >> my mutt mailbox and it shows the down-right arrow signifying this. I >> inspect the headers and there is indeed a header in MYMSGIDREPLY that >> says "In-Reply-To: ". I then do... >> $ notmuch search --output=threads "id:MYMSGIDREPLY" >> thread:c125 >> $ notmuch search --output=messages "thread:c125" >> id:MYMSGIDREPLY >> $ > > If the thread-id's are accurate, then it looks like the two messages are > not in the same thread according to notmuch (it's easy to be fooled > because the thread-ids are so similar). I can't really explain how > those messages might have ended up in different threads. > > - One potential issue is that if message ids are extra long or badly > formed, then notmuch might make up a new message id. In that case your > thread-id search wouldn't work at all. > > - If there are actually multiple (unrelated) files with message-id > MYMSGIDREPLY, then the indexed one might not have the in-reply-to > header. But in this case you could tell by > > notmuch show id:MYMSGIDREPLY > > and/or > > notmuch search --output=files id:MSGIDREPLY > > In order for the thread-ids to change when you run "notmuch new", I > _think_ that there has to be a third message in the thread disovered. > > So it's a mystery. If it happens again with public messages, it would be > worth sharing the messages (as attachements) with the list, just in case > there is something in the headers that explains it. > OK I will be careful to document if I find a repeatable example and share with the list. I would like to help in any possible way that I am capable. Kind regards, Xu ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PÄTCH] notmuch-emacs-mua: set EMACS{,CLIENT} variables to defaults when empty
... in addition to doing this when these variables are unset.
It is more useful to use defaults (emacs or emacsclient) than empty
string as a command name.
---
Without this:
$ EMACS= ./notmuch-emacs-mua
./notmuch-emacs-mua: line 150: exec: --: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
zsh: exit 2 EMACS= ./notmuch-emacs-mua
notmuch-emacs-mua | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/notmuch-emacs-mua b/notmuch-emacs-mua
index 016fa12613c4..4404cd7c33b8 100755
--- a/notmuch-emacs-mua
+++ b/notmuch-emacs-mua
@@ -30,8 +30,8 @@ escape ()
printf -v $2 '%s' "${__escape_arg__//\"/\\\"}"
}
-EMACS=${EMACS-emacs}
-EMACSCLIENT=${EMACSCLIENT-emacsclient}
+EMACS=${EMACS:-emacs}
+EMACSCLIENT=${EMACSCLIENT:-emacsclient}
PRINT_ONLY=
NO_WINDOW=
--
2.0.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch-emacs-mua: set EMACS{, CLIENT} variables to defaults when empty
... in addition to doing this when these variables are unset.
It is more useful to use defaults (emacs or emacsclient) than empty
string as a command name.
---
Without this:
$ EMACS= ./notmuch-emacs-mua
./notmuch-emacs-mua: line 150: exec: --: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
zsh: exit 2 EMACS= ./notmuch-emacs-mua
notmuch-emacs-mua | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/notmuch-emacs-mua b/notmuch-emacs-mua
index 016fa12613c4..4404cd7c33b8 100755
--- a/notmuch-emacs-mua
+++ b/notmuch-emacs-mua
@@ -30,8 +30,8 @@ escape ()
printf -v $2 '%s' "${__escape_arg__//\"/\\\"}"
}
-EMACS=${EMACS-emacs}
-EMACSCLIENT=${EMACSCLIENT-emacsclient}
+EMACS=${EMACS:-emacs}
+EMACSCLIENT=${EMACSCLIENT:-emacsclient}
PRINT_ONLY=
NO_WINDOW=
--
2.0.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Possible some threads are not complete due to bug?
Xu Wang writes: > > $ notmuch search --output=threads "id:MYMSGID" > thread:a125 > $ notmuch search --output=messages "thread:a125" > id:MYMSGID > $ > # I know that MYMSGIDREPLY did respond to that message. I have it in > my mutt mailbox and it shows the down-right arrow signifying this. I > inspect the headers and there is indeed a header in MYMSGIDREPLY that > says "In-Reply-To: ". I then do... > $ notmuch search --output=threads "id:MYMSGIDREPLY" > thread:c125 > $ notmuch search --output=messages "thread:c125" > id:MYMSGIDREPLY > $ If the thread-id's are accurate, then it looks like the two messages are not in the same thread according to notmuch (it's easy to be fooled because the thread-ids are so similar). I can't really explain how those messages might have ended up in different threads. - One potential issue is that if message ids are extra long or badly formed, then notmuch might make up a new message id. In that case your thread-id search wouldn't work at all. - If there are actually multiple (unrelated) files with message-id MYMSGIDREPLY, then the indexed one might not have the in-reply-to header. But in this case you could tell by notmuch show id:MYMSGIDREPLY and/or notmuch search --output=files id:MSGIDREPLY In order for the thread-ids to change when you run "notmuch new", I _think_ that there has to be a third message in the thread disovered. So it's a mystery. If it happens again with public messages, it would be worth sharing the messages (as attachements) with the list, just in case there is something in the headers that explains it. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] nmbug-status: print config errors to stderr
Jani Nikula writes: > Particularly scripted usage with stdout redirection can be confusing > if errors are printed to stdout instead of stderr. pushed d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
