Re: [notmuch] reading with multiple MUAs from MailDir
On Fri, 2009-12-11 at 10:44 +0100, Marten Veldthuis wrote: Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: Is there a workaround? For now, you can do notmuch dump somefile mv Mail/.notmuch /tmp notmuch new notmuch restore somefile Which will re-index all your mail, and restore your tags, as far as the messages are still called the same. Deleted messages will disappear from the library, and moved messages remain in the inbox. Still a pain in the ass, but at least it gets rid of all those errors. With all due respect... Seriously? That doesn't even qualify as a crazy hack... this process takes something like 15 minutes for me. Carl, any idea how when an actual solution to this problem will arrive? /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] reordering and cleanup of thread authors
This is based in part on some discussion on IRC today.
When a thread is displayed in the search results, previously the authors
were always displayed in chronological order. But if only part of the
thread matches the query, that may or may not be the intuitive thing to
do.
Imagine the default +inbox query. Those mails in the thread that
match the query are actually new (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread, the
author column in the search display will first show Dirk Hohndel - I
think it should first show the actual author(s) of the new mail(s).
The second cleanup that I've done in this context is to convert all
author names into the much easier to parse Firstname Lastname
format. Some broken mail systems (cough - Exchange - Cough) seem to
prefer Lastname, Firstname - which makes the comma separated list of
authors really hard to parse at one glance. Worse, it creates douplicate
entries if a person happens to show in both orders. So this does a
rather simplistic look for a comma, if it's there, reorder approach to
cleaning up the author name.
I don't think this is ready to be pulled. There was a strong request on
IRC to make the re-ordering of the author names configurable. I think
the cleanup of the names (First Last) should be configurable as well.
And of course I wonder about my implementation, given that I'm still
trying to wrap my mind around the current code base.
Thanks
/D
diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..ac0afd9 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
char *thread_id;
char *in_reply_to;
char *filename;
+char *author;
notmuch_message_file_t *message_file;
notmuch_message_list_t *replies;
unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
message-in_reply_to = NULL;
message-filename = NULL;
message-message_file = NULL;
+message-author = NULL;
message-replies = _notmuch_message_list_create (message);
if (unlikely (message-replies == NULL)) {
@@ -533,6 +535,20 @@ notmuch_message_get_tags (notmuch_message_t *message)
return _notmuch_convert_tags(message, i, end);
}
+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message-author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+ const char *author)
+{
+message-author = talloc_strdup(message, author);
+return;
+}
+
void
_notmuch_message_set_date (notmuch_message_t *message,
const char *date)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 88da078..79638bb 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -771,6 +771,17 @@ notmuch_message_set_flag (notmuch_message_t *message,
time_t
notmuch_message_get_date (notmuch_message_t *message);
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message
+ */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message'
+ */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
/* Get the value of the specified header from 'message'.
*
* The value will be read from the actual message file, not from the
diff --git a/lib/thread.cc b/lib/thread.cc
index 48c070e..c3c83a3 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
char *subject;
GHashTable *authors_hash;
char *authors;
+char *nonmatched_authors;
GHashTable *tags;
notmuch_message_list_t *message_list;
@@ -69,8 +70,95 @@ _thread_add_author (notmuch_thread_t *thread,
thread-authors = talloc_asprintf (thread, %s, %s,
thread-authors,
author);
-else
+else {
thread-authors = talloc_strdup (thread, author);
+}
+}
+
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * oldest first order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authorscopy;
+char *currentauthor;
+int idx,nmstart,author_len,authors_len;
+
+if (thread-authors == NULL)
+ return;
+if (thread-nonmatched_authors == NULL)
+ thread-nonmatched_authors = thread-authors;
+author_len = strlen(author);
+authors_len = strlen(thread-authors);
+if (author_len == authors_len) {
+ /* just one author */
+ thread-nonmatched_authors += author_len;
+ return;
+}
+currentauthor
[PATCH] Fix code extracting the MTA from Received: headers
The previous code made too many assumptions about the (sadly not
standardized) format of the Received headers. This version should
be more robust to deal with different variations.
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
notmuch-reply.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 8eb4754..39377e1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -296,28 +296,23 @@ guess_from_received_header (notmuch_config_t *config,
notmuch_message_t *message
received = notmuch_message_get_header (message, received);
by = strstr (received, by );
if (by *(by+4)) {
- /* we know that there are 4 characters after by - either the 4th one
-* is '\0' (broken header) or it is the first letter of the hostname
-* that last received this email - which we'll use to guess the right
-* from email address
+ /* sadly, the format of Received: headers is a bit inconsistent,
+* depending on the MTA used. So we try to extract just the MTA
+* here by removing leading whitespace and assuming that the MTA
+* name ends at the next whitespace
+* we test for *(by+4) to be non-'\0' to make sure there's something
+* there at all - and then assume that the first whitespace delimited
+* token that follows is the last receiving server
*/
mta = strdup (by+4);
if (mta == NULL)
return NULL;
-
- /* After the MTA comes its IP address (or HELO response) in parenthesis.
-* so let's terminate the string there
-*/
- if ((ptr = strchr (mta, '(')) == NULL) {
- free (mta);
+ token = strtok(mta, \t);
+ if (token == NULL)
return NULL;
- }
- *ptr = '\0';
-
/* Now extract the last two components of the MTA host name
* as domain and tld
*/
- token = mta;
while ((ptr = strsep (token, delim)) != NULL) {
if (*ptr == '\0')
continue;
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:13:20 +0100, David Edmondson d...@dme.org wrote: On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote: * The big batch of emacs-client improvements from David E.'s repository. David, do you have particular things to recommend here? It's necessary for me to merge with your latest batch of changes. That won't happen until next week, when I can set aside a few hours. (The merge is somewhat painful, as I have modified versions of some of the recently applied patches in my tree.) I hope that this will be a less frequent thing to happen as Carl is quicker in picking up patches. I'm very eager to see the emacs client improvements, though. I worry about committing the JSON based Emacs UI and then immediately producing a release - it would be useful to have more people test it from git HEAD before dropping it on an unsuspecting public. Not sure how much of an unsuspecting public we have at this point... but in general this is of course valid. The question is what are releases. Or what does it mean to release 0.2. I don't think we have the notion of a stable branch and a development cycle, yet. Everything is development (correct me if I'm wrong, Carl) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins jroll...@finestructure.net wrote: So keep the patches coming, and the pointers to patches that you want me to look at. I would really like to see the patch in spaetz/issue15-handle-fcc-bcc applied soon. This is the lingering issue of bcc'ing the primary email address in notmuch replies, which I think really needs to be removed. +1 The FCC solution is much more sane. Especially with the From address based path selection that I proposed (but haven't been able to implement for lack of Lisp skills) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Have notmuch count default to showing the total.
On Fri, 09 Apr 2010 15:01:35 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-04-08, Mike Kelly wrote: If no parameters are given to notmuch-count, or just '' or '*' are given, return the total number of messages in the database. I know that cworth was concerned about this syntax on IRC as that would mean that notmuch show would have to spew out all your emails in order to remain consistent with the search term (he rather wanted to output a help text if no search term was given). But let me express support (It's notmuch worth, I know (haha)) for this patch. I think it makes lots of sense: 1) I often want to know how many mails are in my db. notmuch count or notmuch count * is the intuitive syntax I would use for that. Right now there is no way as far as I can see. I use notmuch count To - not very intuitive, though. 2) Search terms filter out things. The empty search term stands therefore for all my mails. It is consistent to have the search term '' represent all my mail. Actually, I'd like to disagree. A search argument of '' should get you a help text. A search argument of '*' should give you all email. 3) I don't expect a help text for notmuch count just as I don't expect a help text for notmuch log, we are very explicit about notmuch help and notmuch help count in many parts of our documentation. My main concern here is that once you have a gazzillion emails, typing notmuch search with no argument over a slow link (or using it from within a gui by mistake) could really cause a lot of unnecessary compute / data transfer. So I'd rather have a special character be the one that triggers that behavior. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] reordering and cleanup of thread authors
On Sat, 10 Apr 2010 03:53:59 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: I think that using | as a separator would help here. Let's say that initially we have Matched Author, Non Matched, Matched Again we can tranform this to Matched Author, Matched Again| Non Matched. This way, the length of the string remains the same. If there is no | after transformation, we know that all authors matched because there is always at least one mathed author in the search results. That's a great idea. I'll update the patch to do that. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: User-Agent header
On Fri, 09 Apr 2010 19:55:17 -0700, Carl Worth cwo...@cworth.org wrote: So I propose something like: User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) +1 /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
here's what's going wrong. Look at the To: line... /D On Fri, 09 Apr 2010 20:06:09 -0700, Carl n∅tmuch 䚳 Worth cwo...@cworth.org wrote: On Fri, 09 Apr 2010 09:35:07 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-04-09, Michal Sojka wrote: Perhaps Carl should get more Nørwég¡añ friends, :-). Or Görmän or 中文 Are you all trying to show a problem here? All of the above comes through fine. Perhaps it's only with non-ASCII in the From line being replied to? Let's test that here... -Carl PS. How about this for something interesting from Unicode: 䚳 Definition in English: do not know, to know nothing about, quickly; fast, sharp; keen Non-text part: application/pgp-signature -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel hohn...@infradead.org wrote: here's what's going wrong. Look at the To: line... Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth cwo...@cworth.org, that's not pretty... nor readable. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 09:05:00 -0400, Jameson Rollins jroll...@finestructure.net wrote: On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel hohn...@infradead.org wrote: On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel hohn...@infradead.org wrote: here's what's going wrong. Look at the To: line... Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth cwo...@cworth.org, The To: line shows up fine in notmuch-show for me (in emacs). It only shows up like this when editing. I think this is actually a general mail issue, and is not a notmuch issue. I don't understand all the issues, but I think non-ASCII characters in headers have to be encoded, and that's what you're seeing. Yes, I understand the RFCs and encoding fairly well. That wasn't my point. The point is that for some reason we display the encoded text shown above in the Messages Mode buffer, instead of displaying the non-ASCII characters as we (IMHO) should. Maybe this is an issue of different versions of Emacs behaving slightly differently as Carl seems not to have this issue... I'm on GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.18.6) of 2010-01-14 on x86-02.phx2.fedoraproject.org /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 15:52:04 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote: Are you all trying to show a problem here? All of the above comes through fine. Perhaps it's only with non-ASCII in the From line being replied to? Let's test that here... I think there are 2 issues being discussed here. One is the encoding in the subject line (which does not look pretty in compose mail, but seems to be the standard). I did not refer to that. That's the issue I refer to. Yes, it needs to be decoded for the actual mail transport. But it should be displayed correctly not only in the summary view but also in the message buffer when responding to an email. What I referred to was the json output as the encode_as_json_string (or however it is called), simply drops chars 127, leading to missing letters in e.g. the author names etc. I could see that in the web frontends that are making use of json already, and once (if?) emacs uses the json output too, this will become an issue there too. Separate issue that almost certainly has a different cause. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: User-Agent header
On Sat, 10 Apr 2010 16:00:49 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-04-10, Carl Worth wrote: So I propose something like: User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) That looks good to me. So I assume the correct strategy here would be to: 1) have notmuch reply insert a header: User-Agent: Notmuch/0.2 (http://notmuchmail.org) 2) have notmuch-reply.el (or whatever) add a setup mail hook that searches for an existing User-Agent header and appends Emacs/23.1.1 (gnu/linux) One issue is again, such a hook would be message mode specific, so gnus users might not appreciate that. Also when composing a message via c-x m this would not work. So perhaps an all lisp solution? Again, can we hijack message mode to add our own promotion header? Or has the time come for a notmuch-message-mode that somehow inherits from message mode? bremner said something about dynamic bindings that would allow that. I really think we need to investigate having a notmuch-message-mode as there are now a number of reasons to be able to customize things when the user is running notmuch. BTW: I don't think these are promotion headers - I relatively frequently want to check which email client someone else is using when I'm trying to figure out why things go wrong (incorrect mail headers, mangled spacing (in patches, for example), incorrect HTML messages, etc) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] notmuch new --new-tags=tags...
On Sun, 11 Apr 2010 01:03:04 +1000, Anthony Towns a...@erisian.com.au wrote: Hi *, The attached patch makes notmuch new --new-tags=unread,new set the unread and new tags on any new mail it finds rather than unread and inbox. Or whatever other tags you happen to specify. I really like this - I have a similar patch that hardcodes a +new tag that I use to figure out which emails were imported during the last run of notmuch new - and that I then clear as the final step in my initial tagging script. But this is much cleaner and more generic. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fixing possible dereferencing of NULL pointer
I must have misunderstood the cases in which this function can be called It seemed odd to try to manage authors when author==NULL, but that's what we appear to be doing; so now we check that autho != NULL and bail otherwise. Signed-off-by: Dirk Hohndel hohn...@infradead.org --- lib/thread.cc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/thread.cc b/lib/thread.cc index c3c83a3..93a7264 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -88,7 +88,7 @@ _thread_move_matched_author (notmuch_thread_t *thread, char *currentauthor; int idx,nmstart,author_len,authors_len; -if (thread-authors == NULL) +if (thread-authors == NULL || author == NULL) return; if (thread-nonmatched_authors == NULL) thread-nonmatched_authors = thread-authors; -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Use of strcasestr
On Mon, 12 Apr 2010 15:58:10 +0200, Tomas Carnecky t...@dbservice.com wrote: In 4fd9ea0 (guess From address from Received headers, 2010-04-06) you introduced strcasestr, which is not portable, see 82e47ec (notmuch reply: Use strstr instead of strcasestr for portability., 2010-02-04). Is strcasestr really necessary there or can it be replaced with strstr? Well, I'm trying to make sure that rAndOm case in email addresses doesn't throw of the matching - it's quite common for people to write email addresses as first.l...@company.com - the RFCs that I've seen (can't double check, on a plane right now) seem to indicate that you can't rely on the headers being lowercase - so even preprocessing the configured email addresses might not be enough. I guess we could selectively force some of the headers to be stored as lower case - Received, X-Original-To, Envelope-To in my case - but that seems wrong somehow. Open to better ideas... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: please eat my data!
On Mon, 12 Apr 2010 19:10:25 -0400, Servilio Afre Puentes servi...@gmail.com wrote: On 12 April 2010 13:47, Dirk Hohndel hohn...@infradead.org wrote: On Mon, 12 Apr 2010 10:14:05 -0700, Stewart Smith stew...@flamingspork.com wrote: On Mon, 12 Apr 2010 17:24:35 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: What I find intersting is that we have a 2x speedup and a 10x speedup for different queries. Olly was saying on IRC that both *should* really be behaving in much the same manner. Remember that on ext3 (and pretty sure ext4) fsync is the same as sync(). So performance depends on how much dirty data you have in your cache. libeatmydata also gets rid of msync(), O_SYNC etc as well. Which is why so many of us have started to use BTRFS... How stable is it now? What kernel version and distro are you using? Several. Fedora 12 with 2.6.34-rc3. Moblin-2.1 (derivative) with 2.6.33. Debian sid with 2.6.33 I've been using it for most everything I do since some point in the 2.6.32 rcs. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Use of strcasestr
On Tue, 13 Apr 2010 04:04:39 +0200, Tomas Carnecky t...@dbservice.com wrote: On 4/12/10 10:18 PM, Mikhail Gusarov wrote: Twas brillig at 15:58:10 12.04.2010 UTC+02 when t...@dbservice.com did gyre and gimble: TC In 4fd9ea0 (guess From address from Received headers, 2010-04-06) you introduced TC strcasestr, which is not portable, see 82e47ec (notmuch reply: Use strstr TC instead of strcasestr for portability., 2010-02-04). TC Is strcasestr really necessary there or can it be replaced with strstr? strcasecmp is POSIX.1-2001. Indeed it is, but the code uses strcasestr and I couldn't find any indication which standard that function is part of. Adding that function to compat/ probably is the way to go, but the whole compat mechanism doesn't work here. It's like if compat/Makefile.local was not included in the top-level makefile, notmuch_compat_srcs is empty there. Any ideas how to debug that? While I don't have access to a system that doesn't provide strcasest right now... I'll submit a patch in a moment that should add a replacement function to compat. Please check and make sure this works... Thanks /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add simplistic reimplementation of strcasestr to compat library
While all systems that I have access to support strcasestr, it is
in fact not part of POSIX. So here's a fallback reimplementation
based on POSIX functions.
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
compat/Makefile.local|4
compat/have_strcasestr.c | 10 ++
compat/strcasestr.c | 41 +
configure| 15 +++
4 files changed, 70 insertions(+), 0 deletions(-)
create mode 100644 compat/have_strcasestr.c
create mode 100644 compat/strcasestr.c
diff --git a/compat/Makefile.local b/compat/Makefile.local
index 81e6c70..2a52a14 100644
--- a/compat/Makefile.local
+++ b/compat/Makefile.local
@@ -8,3 +8,7 @@ notmuch_compat_srcs =
ifneq ($(HAVE_GETLINE),1)
notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
endif
+
+ifneq ($(HAVE_STRCASESTR),1)
+notmuch_compat_srcs += $(dir)/strcasestr.c
+endif
\ No newline at end of file
diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c
new file mode 100644
index 000..c0fb762
--- /dev/null
+++ b/compat/have_strcasestr.c
@@ -0,0 +1,10 @@
+#define _GNU_SOURCE
+#include strings.h
+
+int main()
+{
+char *found;
+const char *haystack, *needle;
+
+found = strcasestr(haystack, needle);
+}
diff --git a/compat/strcasestr.c b/compat/strcasestr.c
new file mode 100644
index 000..50bc89d
--- /dev/null
+++ b/compat/strcasestr.c
@@ -0,0 +1,41 @@
+/*
+ * slow simplistic reimplementation of strcasestr for systems that
+ * don't include it in their library
+ *
+ * based on a GPL implementation in OpenTTD found under GPL v2
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation, version 2.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA. */
+
+/* Imported into notmuch by Dirk Hohndel - original author unknown. */
+/* the semantic here actually puzzles me:
+ how can haystack be const char * - yet the return value is char *
+ after all, it points to a sub-string of haystack... */
+
+#include string.h
+
+char *strcasestr(const char *haystack, const char *needle)
+{
+ size_t hay_len = strlen(haystack);
+ size_t needle_len = strlen(needle);
+ while (hay_len = needle_len) {
+ if (strncasecmp(haystack, needle, needle_len) == 0)
+ return (char *) haystack;
+
+ haystack++;
+ hay_len--;
+ }
+
+ return NULL;
+}
diff --git a/configure b/configure
index 5af7852..023aa40 100755
--- a/configure
+++ b/configure
@@ -310,6 +310,17 @@ else
fi
rm -f compat/have_getline
+printf Checking for strcasestr...
+if ${CC} -o compat/have_strcasestr compat/have_strcasestr.c /dev/null 21
+then
+printf Yes.\n
+have_strcasestr=1
+else
+printf No (will use our own instead).\n
+have_strcasestr=0
+fi
+rm -f compat/have_strcasestr
+
cat EOF
All required packages were found. You may now run the following
@@ -384,6 +395,10 @@ zsh_completion_dir =
\$(prefix)/share/zsh/functions/Completion/Unix
# build its own version)
HAVE_GETLINE = ${have_getline}
+# Whether the strcasestr function is available (if not, then notmuch will
+# build its own version)
+HAVE_STRCASESTR = ${have_strcasestr}
+
# Flags needed to compile and link against Xapian
XAPIAN_CXXFLAGS = ${xapian_cxxflags}
XAPIAN_LDFLAGS = ${xapian_ldflags}
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add simplistic reimplementation of strcasestr to compat library
On Tue, 13 Apr 2010 15:59:24 +1000, Anthony Towns a...@erisian.com.au wrote: On Tue, Apr 13, 2010 at 14:10, Dirk Hohndel hohn...@infradead.org wrote: +/* the semantic here actually puzzles me: + how can haystack be const char * - yet the return value is char * + after all, it points to a sub-string of haystack... */ Dunno if this is a question from the original source, but the answer No, that was me being puzzled :-) if anyone's interested is probably because C doesn't have templates -- you'd ideally like to have it treated as: char *strcasestr(char *haystack, const char *needle); for when you're doing a search and replace on the needle (say), and: const char *strcasestr(const char *haystack, const char *needle); for when you're doing a search for the needle in something you can't modify. But C isn't clever enough to let you say that with just one function (and no fancy #defines), so you have to drop some of the typechecking with the (char*) cast on the return value if you want to handle both use cases, without the compiler complaining about const-non-const conversions in otherwise correct code in one case or the other. That makes sense. Thanks /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix code extracting the MTA from Received: headers
On Tue, 13 Apr 2010 10:37:49 -0700, Carl Worth cwo...@cworth.org wrote: On Thu, 08 Apr 2010 08:07:48 -0700, Dirk Hohndel hohn...@infradead.org wrote: Right now my plan is to do something like this: 1) look for my email address in To/Cc 2) look for my email in for em...@add.res in Received headers 3) look for my email in X-Original-To 4) look for the domain of my email in Received headers (not just 1st) 5) punt and use default email address Does that sound sane? It sounds sane. Good. (and thanks for sending the headers - this really helps... can others for whom the current code or the logic mentioned above wouldn't work send their headers, too, please?) I started using fetchmail many years ago and have never really needed to switch. So I'm still using that, (but don't necessarily recommend it to anyone. It seems to break the above since it delivers mail locally, so the first headers I get are: X-Original-To: cwo...@localhost Easy to detect. I'll add that as an exclusion Delivered-To: cwo...@localhost Received: from yoom.home.cworth.org (yoom.home.cworth.org [127.0.0.1]) by yoom.home.cworth.org (Postfix) with ESMTP id D391B5883A6 for cwo...@localhost; Mon, 12 Apr 2010 09:11:18 -0700 (PDT) MIME-Version: 1.0 Received: from 10.22.226.213 [10.22.226.213] by yoom.home.cworth.org with IMAP (fetchmail-6.3.16) for cwo...@localhost (single-drop); Mon, 12 Apr 2010 09:11:18 -0700 (PDT) A (he runs screaming out of the room) And none of these are useful for your detection. Worse, the presence of cworth.org in the above might throw your detection off before it could find something useful like intel.com in a later Received header. I have some choice words for these headers... And an idea how to exclude these false positives as well... It's kind of a hack, but I'm thinking that in order for the Received: ... by ... part to be truly relevant to us, the from host should have a non-private IP address. Yes, I can envision within-your-own-network cases where none of the systems have a non-private email address... but then hopefully your last hop is correct... if not - your setup is even more screwed up than Carl's. I'll send a complete message with full headers to you separately. Thanks Perhaps I can just switch programs to transfer email and avoid this problem. Anyone have a recommendation for something to transfer mail From an imap server to the local matchine, (but *not* leaving it stored on the imap server)[*]. I don't think offlineimap supports this mode does it? Don't think so. I'm not going to comment on the usefulness of this mode in public :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
v.3 of this patch, now with the changes to makefiles, configure script
compat.h and all new files that I need
Please test on platforms lacking strcasestr
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
compat/Makefile.local|4
compat/compat.h |4
compat/have_strcasestr.c | 10 ++
compat/strcasestr.c | 41 +
configure| 20 ++--
5 files changed, 77 insertions(+), 2 deletions(-)
create mode 100644 compat/have_strcasestr.c
create mode 100644 compat/strcasestr.c
diff --git a/compat/Makefile.local b/compat/Makefile.local
index 81e6c70..2a17309 100644
--- a/compat/Makefile.local
+++ b/compat/Makefile.local
@@ -8,3 +8,7 @@ notmuch_compat_srcs =
ifneq ($(HAVE_GETLINE),1)
notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
endif
+
+ifneq ($(HAVE_STRCASESTR),1)
+notmuch_compat_srcs += $(dir)/strcasestr.c
+endif
diff --git a/compat/compat.h b/compat/compat.h
index d639e0f..173ef68 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -38,4 +38,8 @@ getdelim (char **lineptr, size_t *n, int delimiter, FILE *fp);
#endif /* !HAVE_GETLINE */
+#if !HAVE_STRCASESTR
+char* strcasestr(const char *haystack, const char *needle);
+#endif /* !HAVE_STRCASESTR */
+
#endif /* NOTMUCH_COMPAT_H */
diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c
new file mode 100644
index 000..c0fb762
--- /dev/null
+++ b/compat/have_strcasestr.c
@@ -0,0 +1,10 @@
+#define _GNU_SOURCE
+#include strings.h
+
+int main()
+{
+char *found;
+const char *haystack, *needle;
+
+found = strcasestr(haystack, needle);
+}
diff --git a/compat/strcasestr.c b/compat/strcasestr.c
new file mode 100644
index 000..50bc89d
--- /dev/null
+++ b/compat/strcasestr.c
@@ -0,0 +1,41 @@
+/*
+ * slow simplistic reimplementation of strcasestr for systems that
+ * don't include it in their library
+ *
+ * based on a GPL implementation in OpenTTD found under GPL v2
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation, version 2.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA. */
+
+/* Imported into notmuch by Dirk Hohndel - original author unknown. */
+/* the semantic here actually puzzles me:
+ how can haystack be const char * - yet the return value is char *
+ after all, it points to a sub-string of haystack... */
+
+#include string.h
+
+char *strcasestr(const char *haystack, const char *needle)
+{
+ size_t hay_len = strlen(haystack);
+ size_t needle_len = strlen(needle);
+ while (hay_len = needle_len) {
+ if (strncasecmp(haystack, needle, needle_len) == 0)
+ return (char *) haystack;
+
+ haystack++;
+ hay_len--;
+ }
+
+ return NULL;
+}
diff --git a/configure b/configure
index 5af7852..90a399c 100755
--- a/configure
+++ b/configure
@@ -310,6 +310,17 @@ else
fi
rm -f compat/have_getline
+printf Checking for strcasestr...
+if ${CC} -o compat/have_strcasestr compat/have_strcasestr.c /dev/null 21
+then
+printf Yes.\n
+have_strcasestr=1
+else
+printf No (will use our own instead).\n
+have_strcasestr=0
+fi
+rm -f compat/have_strcasestr
+
cat EOF
All required packages were found. You may now run the following
@@ -384,6 +395,10 @@ zsh_completion_dir =
\$(prefix)/share/zsh/functions/Completion/Unix
# build its own version)
HAVE_GETLINE = ${have_getline}
+# Whether the strcasestr function is available (if not, then notmuch will
+# build its own version)
+HAVE_STRCASESTR = ${have_strcasestr}
+
# Flags needed to compile and link against Xapian
XAPIAN_CXXFLAGS = ${xapian_cxxflags}
XAPIAN_LDFLAGS = ${xapian_ldflags}
@@ -405,9 +420,10 @@ VALGRIND_CFLAGS = ${valgrind_cflags}
# Combined flags for compiling and linking against all of the above
CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS) \\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
- \$(VALGRIND_CFLAGS)
+ \$(VALGRIND_CFLAGS) -DHAVE_STRCASESTR=\$(HAVE_STRCASESTR)
CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
-\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS)
+\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\
+ -DHAVE_STRCASESTR
[PATCH] Add simplistic compat implementation for strcasestr
v.2 of the patch, this time including the Makefile logic.
All platforms I have access to support strcasestr - so please test
that the implementation / integration works correctly on those
plattforms.
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
compat/have_strcasestr.c | 10 ++
compat/strcasestr.c | 41 +
2 files changed, 51 insertions(+), 0 deletions(-)
create mode 100644 compat/have_strcasestr.c
create mode 100644 compat/strcasestr.c
diff --git a/compat/have_strcasestr.c b/compat/have_strcasestr.c
new file mode 100644
index 000..c0fb762
--- /dev/null
+++ b/compat/have_strcasestr.c
@@ -0,0 +1,10 @@
+#define _GNU_SOURCE
+#include strings.h
+
+int main()
+{
+char *found;
+const char *haystack, *needle;
+
+found = strcasestr(haystack, needle);
+}
diff --git a/compat/strcasestr.c b/compat/strcasestr.c
new file mode 100644
index 000..50bc89d
--- /dev/null
+++ b/compat/strcasestr.c
@@ -0,0 +1,41 @@
+/*
+ * slow simplistic reimplementation of strcasestr for systems that
+ * don't include it in their library
+ *
+ * based on a GPL implementation in OpenTTD found under GPL v2
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation, version 2.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ 02110-1301, USA. */
+
+/* Imported into notmuch by Dirk Hohndel - original author unknown. */
+/* the semantic here actually puzzles me:
+ how can haystack be const char * - yet the return value is char *
+ after all, it points to a sub-string of haystack... */
+
+#include string.h
+
+char *strcasestr(const char *haystack, const char *needle)
+{
+ size_t hay_len = strlen(haystack);
+ size_t needle_len = strlen(needle);
+ while (hay_len = needle_len) {
+ if (strncasecmp(haystack, needle, needle_len) == 0)
+ return (char *) haystack;
+
+ haystack++;
+ hay_len--;
+ }
+
+ return NULL;
+}
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky t...@dbservice.com wrote: On 4/13/10 6:47 PM, Dirk Hohndel wrote: v.3 of this patch, now with the changes to makefiles, configure script compat.h and all new files that I need Please test on platforms lacking strcasestr Signed-off-by: Dirk Hohndelhohn...@infradead.org Tested-by: Tomas Carnecky t...@dbservice.com (on OpenSolaris snv_134) Thanks Tomas, I really appreciate it. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Next attempt to get guessing of From addresses correct in replies
On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth cwo...@cworth.org wrote:
On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel hohn...@infradead.org
wrote:
+ * WARNING - if the caller is asking for a header that could occur
+ * multiple times than they MUST first call this function with a
+ * a value of NULL for header_desired to ensure that all of the
+ * headers are parsed and concatenated before a match is returned
...
+ } else {
+ /* not sure this makes sense for all headers that can occur
+* multiple times, but for now just concatenate headers
+*/
+ newhdr = strlen(decoded_value);
+ hdrsofar = strlen(header_sofar);
I'm a little nervous about this semantic change.
So am I - but I haven't found a message where this would have bitten me.
For example, I know that my mail collection contains at least some
messages with multiple Message-ID headers, (I'm not sure that's legal,
but they are there).
No, that is absolutely NOT RFC compliant. Wonder what creates those
messages...
I found those when doing detailed comparisons of
the database created by sup with that created by very early versions of
what became the indexing code for notmuch. [Sup prefers the
last-encountered Message-Id in the file, while Notmuch prefers the
first.]
Actually, prior to another fix that I sent (and that you already
applied), notmuch would use the first if you came across this header for
the first time when searching for it (but since you'd search for
Message-Id fairly early on, that's likely what happened). But if your
header was remembered en-passant while searching for a different
header later in the file, notmuch would actually remember the last.
But again, I fixed that before making the change to concatenate
duplicates instead.
So I'm concerned about the change above introducing subtle problems that
might be hard to notice.
Yes, absolutely - a concatenated Message-Id would SUCK.
How about an argument that asks explicitly for concatenated header
values, (and this could just trigger a rescan of the headers and ignore
the hash). I think that will be fine for your use case where you're just
opening this message file to get this one concatenated header out,
right?
That would work just fine. And avoid the potential unintended side
effects.
I'm about to head for the airport - do you want to make that
modification yourself or should I do it tonight?
/D
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
added feature idea page to the wiki
I figured we should have a central place to collect feature ideas - finding them in the mail archives (and IRC logs) is getting old... So I started a feature idea / request page on the wiki - please comment and add your own requests. http://notmuchmail.org/feature-requests/ /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
improve from-header guessing
The following two patches should address most of the concerns raised to my previous series. The first patch simply adds an interface to obtain a concatenation of all instances of a specific header from an email. The second patch uses that in order to get the full Received: headers. It now looks at Envelope-to: and X-Original-To: headers, then at the concatenated Received headers for either a for em...@add.res clause that matches a configured address or for a by clause that matches the domain of a configured address. What is still missing is the check if the host from which the mail was received in this last case had a routable IP address. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Address completion
On Tue, 20 Apr 2010 23:33:11 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: Oh my goodness. I just tried http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el together with the latest version of my addrlookup tool (which does the same as jkr's notmuch_addresses.py) and it just works, even in current cworth/master. Address completion for to: and cc: headers based on my notmuch database, sweet! Thanks David. I only need to reverse the sort order of addrlookup as this uses most-to-least likely (which is more intuitive than eudc's least-to-most likely sort order). BTW, addrlookup now first tries to find matches that I previously sent mails to and failing that it will try to find matches for all from: addresses that match the search. BTW: your version fails badly with the Last, First (including quotes) names that Exchange produces... I get First em...@add.res Not ideal :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
test suite for fancy From guessing
This adds five tests for the five main cases in the fancy from guessing. It assumes that you have applied id:1271451102-11336-1-git-send-email-hohn...@infradead.org which will get you the latest fancy From guessing. We have one test case each for - nothing to go on - Envelope-To: - X-Original-To: - Received: ... for ... - Received: domain guessing The second patch adds the Bcc headers that you will get as part of the results with an unpatched notmuch. I consider these Bcc headers broken as they are a potential information leak; the Bcc always goes to the primary email address, so information that isn't related to that account is still routed back to it. Bcc logic should be fixed to copy the address that is used as From: address But since I don't use Bcc at all I didn't attempt to fix that part. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
add delete keybinding
Straight forward addition to the Emacs UI. The 'd' keybinding is implemented very similar to the 'a' keybinding - it only adds a +deleted tag as well. This tag is used by notmuchsync to delete (-p prune) files in the mailstore. I'm sending this mostly as an RFC - I use this and like it, but people seem to have strong feelings as to how they want to deal with deleting email (or for some people, how they don't want to do that at all). /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add 'd'elete keybinding to search and show views
This is a variation of the 'a'rchive binding - it additionally sets the deleted tag (which notmuchsync uses to trigger pruning of files) Signed-off-by: Dirk Hohndel hohn...@infradead.org --- emacs/notmuch-show.el | 26 ++ emacs/notmuch.el | 10 ++ 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 916b39e..45d1abe 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -520,6 +520,7 @@ function is used. (define-key map + 'notmuch-show-add-tag) (define-key map x 'notmuch-show-archive-thread-then-exit) (define-key map a 'notmuch-show-archive-thread) + (define-key map d 'notmuch-show-delete-thread) (define-key map N 'notmuch-show-next-message) (define-key map P 'notmuch-show-previous-message) (define-key map n 'notmuch-show-next-open-message) @@ -910,10 +911,13 @@ to stdout or stderr will appear in the *Messages* buffer. (interactive) (backward-button 1)) -(defun notmuch-show-archive-thread-internal (show-next) +(defun notmuch-show-archive-or-delete-thread-internal (show-next delete) ;; Remove the tag from the current set of messages. (goto-char (point-min)) - (loop do (notmuch-show-remove-tag inbox) + (loop do (progn +(notmuch-show-remove-tag inbox) +(if delete +(notmuch-show-add-tag deleted))) until (not (notmuch-show-goto-message-next))) ;; Move to the next item in the search results, if any. (let ((parent-buffer notmuch-show-parent-buffer)) @@ -925,6 +929,20 @@ to stdout or stderr will appear in the *Messages* buffer. (if show-next (notmuch-search-show-thread)) +(defun notmuch-show-delete-thread () + Delete each message in thread, then show next thread from search. + +Archive each message currently shown by removing the \inbox\ +tag from each. Then kill this buffer and show the next thread +from the search from which this thread was originally shown. + +Note: This command is safe from any race condition of new messages +being delivered to the same thread. It does not archive the +entire thread, but only the messages shown in the current +buffer. + (interactive) + (notmuch-show-archive-or-delete-thread-internal t t)) + (defun notmuch-show-archive-thread () Archive each message in thread, then show next thread from search. @@ -937,12 +955,12 @@ being delivered to the same thread. It does not archive the entire thread, but only the messages shown in the current buffer. (interactive) - (notmuch-show-archive-thread-internal t)) + (notmuch-show-archive-or-delete-thread-internal t nil)) (defun notmuch-show-archive-thread-then-exit () Archive each message in thread, then exit back to search results. (interactive) - (notmuch-show-archive-thread-internal nil)) + (notmuch-show-archive-or-delete-thread-internal nil nil)) (defun notmuch-show-do-stash (text) (kill-new text) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index f135bca..372f940 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -254,6 +254,7 @@ For a mouse binding, return nil. (define-key map [mouse-1] 'notmuch-search-show-thread) (define-key map * 'notmuch-search-operate-all) (define-key map a 'notmuch-search-archive-thread) +(define-key map d 'notmuch-search-delete-thread) (define-key map - 'notmuch-search-remove-tag) (define-key map + 'notmuch-search-add-tag) (define-key map (kbd RET) 'notmuch-search-show-thread) @@ -551,6 +552,15 @@ This function advances the next thread when finished. (notmuch-search-remove-tag-thread inbox) (forward-line)) +(defun notmuch-search-delete-thread () + Delete the currently selected thread (remove its \inbox\ tag and add \deleted\ tag). + +This function advances the next thread when finished. + (interactive) + (notmuch-search-remove-tag-thread inbox) + (notmuch-search-add-tag-thread deleted) + (forward-line)) + (defun notmuch-search-process-sentinel (proc msg) Add a message to let user know when \notmuch search\ exits (let ((buffer (process-buffer proc)) -- 1.6.6.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add 'd'elete keybinding to search and show views
On Wed, 21 Apr 2010 19:32:39 -0400, Jameson Rollins jroll...@finestructure.net wrote: On Wed, 21 Apr 2010 16:16:02 -0700, Dirk Hohndel hohn...@infradead.org wrote: Straight forward addition to the Emacs UI. The 'd' keybinding is implemented very similar to the 'a' keybinding - it only adds a +deleted tag as well. This tag is used by notmuchsync to delete (-p prune) files in the mailstore. I'm sending this mostly as an RFC - I use this and like it, but people seem to have strong feelings as to how they want to deal with deleting email (or for some people, how they don't want to do that at all). Hey, Dirk. I'm definitely on board with this idea, and have in fact been doing exactly the same thing with my personal customizations as you propose (including using the 'd' key). Great. I only have a couple of nit-picky comments about your proposed implementation: That's why I sent this out... On Wed, 21 Apr 2010 16:16:03 -0700, Dirk Hohndel hohn...@infradead.org wrote: -(defun notmuch-show-archive-thread-internal (show-next) +(defun notmuch-show-archive-or-delete-thread-internal (show-next delete) ;; Remove the tag from the current set of messages. (goto-char (point-min)) - (loop do (notmuch-show-remove-tag inbox) + (loop do (progn +(notmuch-show-remove-tag inbox) +(if delete +(notmuch-show-add-tag deleted))) until (not (notmuch-show-goto-message-next))) ;; Move to the next item in the search results, if any. (let ((parent-buffer notmuch-show-parent-buffer)) @@ -925,6 +929,20 @@ to stdout or stderr will appear in the *Messages* buffer. (if show-next (notmuch-search-show-thread)) I'm not sure I like the idea of piggybacking on the notmuch-show-archive-thread-internal function. Why not just make a new separate notmuch-show-delete-thread-internal function? I think it makes the code clearer and easier to parse for the calls to these functions (otherwise it's a little unclear what t t and nil nil and so on mean). It's the C programmer in me who hates code duplication. This way, if the algorithm for walking the mails in the thread changes, you only fix it once. But I see your point about weird options... in C I'd have constants named THREAD_DELETE and THREAD_ARCHIVE_ONLY that I'd pass around... +(defun notmuch-search-delete-thread () + Delete the currently selected thread (remove its \inbox\ tag and add \deleted\ tag). + +This function advances the next thread when finished. + (interactive) + (notmuch-search-remove-tag-thread inbox) + (notmuch-search-add-tag-thread deleted) + (forward-line)) I'm also not a fan of these functions (notmuch-search-delete-thread and notmuch-show-delete-thread) removing the inbox tag. Just because I want to mark a messages as deleted doesn't mean that I want to archive it. I would really like to keep these concepts distinct if possible. Well, that would take away a big reason for adding this - convenience. In the end it's user experience design. The question is (based on expected behavior) - do you expect a deleted email to stay visible in your inbox. I don't - and I know that many people do. So while I agree with the other conclusion in the thread that deleted as tag for deleted messages doesn't have to be configurable - maybe this feature wants to be configurable. notmuch-archive-deleted or something like that /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Update on 0.3 progress
On Wed, 21 Apr 2010 18:11:14 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 16 Apr 2010 13:32:25 -0700, Carl Worth cwo...@cworth.org wrote: I know that I want to merge David Edmunson's rewrite of the emacs interface to be built on top of --format=json and add a ton of features, (better attachment handling, notmuch-hello, etc.). I think that's more than enough to justify a new release right there. The bulk of this rewrite is merged now. I left a few features out with review to David. He (or others) may want to refresh some of those to get them in. (I'd especially like a binding for opening all messages in a thread). I also want to look at notmuch-hello stuff now. But if you have other things you'd like to see in this release, please send a message to the list Most of what came in in response to this request has now been merged. Notable things that made the merge window but have not been merged yet include: * Improve heuristic for guessing best from address in replies id:1271451102-11336-1-git-send-email-hohn...@infradead.org I just need to review and test this still. I submitted tests for this today. id:1271886958-3276-1-git-send-email-hohn...@infradead.org * The archive operation should only archive open messages id:87633sfnyq@yoom.home.cworth.org This still needs an implementation or else it won't make it. PS. I still never sent a list of the features which were proposed for the 0.2 release but postponed. I'll assemble that list soon with my comments on where each of the features stand. Here's that list now. I really should have had this list ready at the time I announced the opening of the 0.3 window so that people would have had more notice to refresh these. I'll try to be better about that in the future: * Add maildir directory name as tag name for messages id:20100210030142.gd16...@mail.rocksoft.com I've postponed this until a database-schema-update planned for 0.4 * Initial support for maildir flags id:1270755931-24290-1-git-send-email-pi...@pioto.org Same here * Reordering and cleanup of thread authors id:m31veru7vn@x200.gr8dns.org This is an interesting feature, but says I don't think this is ready to be pulled in the commit message and then says I'll update the patch at the end of the thread with no update. So I'd still like to see this refreshed (and could still take this for 0.3). Note that the recent fix for the sorting of calls to _add_matched_messages probably means that this feature will work better now than before. Cool - I'll take a look if I can get you an updated patch tonight. * 'F' in search mode takes us to a list of folders id:87vdc2q2l7@yoom.home.cworth.org I rejected this on the basis of the choice of key-binding. I expect we'll get a good keybinding once we add notmuch-hello. * Fcc, Maildir, and Emacs message-mode -- a bit of code id:873a1zs3t5@jhu.edu I've postponed this due to the I've not tested this robustly since I don't actually use it. With a little confirmed testing, I'd love to have this in place (and on by default) * RFC: User-Agent header id:87iq821hba@sspaeth.de This seemed like a good feature proposal, but I didn't see a complete implementation in time for 0.2. There is one now * Mailstore abstraction v4 id:1270737766-29237-1-git-send-email-sojk...@fel.cvut.cz I rejected this due to being extra abstraction in advance of any use case. Michal has recently been following up with pieces of this that are directly justified, (like notmuch cat). Thanks! Thanks for these updates. I have two more that I submitted - the 'G' keybinding that calls an external poll program: this allows you to run notmuch new from within emacs at times that are convenient for the user; otherwise a user either needs to manually run this from outside emacs, or notmuch new is run through cron or offlineimap and in that case we get the weird Xapian database access errors in the discussion of the patch there was concern that this stalls emacs for potentially a long time - I find that acceptable as email is imported - other people may find differently (and decide not to use this feature) id:m339z4csi1@x200.gr8dns.org - the 'd' keybinding that deletes mail/threads (similar to 'a'rchive) id:1271891763-10757-1-git-send-email-hohn...@infradead.org Additionally, I'd really love to see the address completion to be included in notmuch (at least the emacs part of it - I think there's still some debate whether the vala sources would cause too much of a build dependency to be integrated. I don't think this was ever submitted to the mailing list as a patch. The .el file that was posted on IRC is here: http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el Thanks /D -- Dirk Hohndel
Re: [RFC] reordering and cleanup of thread authors
On Fri, 09 Apr 2010 19:42:49 -0700, Dirk Hohndel hohn...@infradead.org wrote: On Sat, 10 Apr 2010 03:53:59 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: I think that using | as a separator would help here. Let's say that initially we have Matched Author, Non Matched, Matched Again we can tranform this to Matched Author, Matched Again| Non Matched. This way, the length of the string remains the same. If there is no | after transformation, we know that all authors matched because there is always at least one mathed author in the search results. That's a great idea. I'll update the patch to do that. Since Carl just prompted me, I wrote an updated patch (will post in a separate message replying to this one). I made the change suggested by Michal, fixed a bug or two and removed the part of the patch that was trying to cleanup author names in Last, First format - on IRC it was pointed out to me that I was overlooking another use of the ',' in email addresses: accounts that are shared by multiple people. And it makes no sense to reorder email addresses of the form Wife, Husband and child familyacco...@add.res I haven't given up on this, though. Since Exchange and Outlook have this nasty habit of creating these Last, First first.l...@company.com or Last, First MI first.mi.l...@company.com from headers, I really want to add the option to clean those up. So I'll submit a separate patch that checks if we have exactly one of these two pattern shown here - and that then reorders things /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Reordering of thread authors to list matching authors first
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','
Imagine the default +inbox query. Those mails in the thread that
match the query are actually new (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
Dirk Hohndel - I think it should first show the actual author(s) of the new
mail(s).
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
lib/message.cc | 16
lib/notmuch.h | 11
lib/thread.cc | 74
3 files changed, 101 insertions(+), 0 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..ac0afd9 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
char *thread_id;
char *in_reply_to;
char *filename;
+char *author;
notmuch_message_file_t *message_file;
notmuch_message_list_t *replies;
unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
message-in_reply_to = NULL;
message-filename = NULL;
message-message_file = NULL;
+message-author = NULL;
message-replies = _notmuch_message_list_create (message);
if (unlikely (message-replies == NULL)) {
@@ -533,6 +535,20 @@ notmuch_message_get_tags (notmuch_message_t *message)
return _notmuch_convert_tags(message, i, end);
}
+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message-author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+ const char *author)
+{
+message-author = talloc_strdup(message, author);
+return;
+}
+
void
_notmuch_message_set_date (notmuch_message_t *message,
const char *date)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index bae48a6..769f747 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -773,6 +773,17 @@ notmuch_message_set_flag (notmuch_message_t *message,
time_t
notmuch_message_get_date (notmuch_message_t *message);
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message
+ */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message'
+ */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
/* Get the value of the specified header from 'message'.
*
* The value will be read from the actual message file, not from the
diff --git a/lib/thread.cc b/lib/thread.cc
index e514bf8..baa0d7f 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
char *subject;
GHashTable *authors_hash;
char *authors;
+char *nonmatched_authors;
GHashTable *tags;
notmuch_message_list_t *message_list;
@@ -73,6 +74,76 @@ _thread_add_author (notmuch_thread_t *thread,
thread-authors = talloc_strdup (thread, author);
}
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authorscopy;
+char *currentauthor;
+char *lastpipe,*nextpipe;
+int idx,nmstart,author_len,authors_len;
+
+if (thread-authors == NULL || author == NULL)
+ return;
+if (thread-nonmatched_authors == NULL)
+ thread-nonmatched_authors = thread-authors;
+author_len = strlen(author);
+authors_len = strlen(thread-authors);
+if (author_len == authors_len) {
+ /* just one author */
+ thread-nonmatched_authors += author_len;
+ return;
+}
+currentauthor = strcasestr(thread-authors, author);
+if (currentauthor == NULL)
+ return;
+/* how far inside the nonmatched authors is our author? */
+idx = currentauthor - thread-nonmatched_authors;
+if (idx 0) {
+ /* already among matched authors */
+ return;
+}
+/* are there any authors in the list after our author? */
+if (thread-nonmatched_authors + author_len thread-authors +
authors_len) {
+ /* we have to make changes, so let's get a temp copy */
+ authorscopy = xstrdup(thread-authors);
+ /* nmstart is the offset into where the non-matched authors start */
+ nmstart = thread-nonmatched_authors - thread-authors;
+ /* copy this author and add the | - the if clause above tells us
there's more */
+ strncpy(thread
Re: [PATCH] emacs: Add notmuch-address.el for address completion using notmuch
On Thu, 22 Apr 2010 10:03:43 +0100, David Edmondson d...@dme.org wrote: A tool `notmuch-addresses' is required to produce addresses which match a query string. An example of a suitable script can be found in the git repository at http://jkr.acm.jhu.edu/git/notmuch_addresses.git There are no doubt others. +1 on getting this into 0.3 /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add 'G' keybinding to folder and search view that triggers external poll
On Thu, 22 Apr 2010 14:50:33 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 09 Apr 2010 12:53:26 -0700, Dirk Hohndel hohn...@infradead.org wrote: The new functions first check if an external poll script has been defined in the variable 'notmuch-external-refresh-script and if yes, runs that script before executing the existing refresh function (which is bound to '=') Thanks Dirk, This is even handier than I expected. I've pushed this now, but followed up immediately with a (totally trivial) change to reduce code duplication, and then a (slightly more major) change to define the controlling variable with defcustom so that the user can find the variable in the customize screen for notmuch. I also renamed it to notmuch-poll-script so you'll need to update your setting for this feature to work. I appreciate how nicely you can say I liked the idea and then completely rewrote the crap elisp that you submitted :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Add tests (and fix bug exposed by test) for author reordering
I want Carl to enforce the adding of tests. Once again writing the test exposed a bug that I hadn't noticed before. So here's the test plus the patch that fixes the bug. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] Add tests for author reordering
Test the different permutation of which authors match the search; This exposes a bug in the existing reordering code Signed-off-by: Dirk Hohndel hohn...@infradead.org --- test/notmuch-test | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/test/notmuch-test b/test/notmuch-test index 3c1cd9f..2b76f04 100755 --- a/test/notmuch-test +++ b/test/notmuch-test @@ -858,6 +858,33 @@ printf Searching returns all three messages in one thread... output=$($NOTMUCH search foo | notmuch_search_sanitize) pass_if_equal $output thread:XXX 2000-01-01 [3/3] Notmuch Test Suite; brokenthreadtest (inbox unread) +printf \nTesting author reordering;\n +printf Adding parent message...\t\t\t +generate_message [body]=findme [id]=new-parent-id [subject]=author-reorder-threadtest '[from]=User u...@example.com' '[date]=Sat, 01 Jan 2000 12:00:00 -' +output=$(NOTMUCH_NEW) +pass_if_equal $output Added 1 new message to the database. +printf Adding initial child message...\t\t +generate_message [body]=findme '[in-reply-to]=\new-parent-id\' [subject]=author-reorder-threadtest '[from]=User1 us...@example.com' '[date]=Sat, 01 Jan 2000 12:00:00 -' +output=$(NOTMUCH_NEW) +pass_if_equal $output Added 1 new message to the database. +printf Adding second child message...\t\t\t +generate_message [body]=findme '[in-reply-to]=\new-parent-id\' [subject]=author-reorder-threadtest '[from]=User2 us...@example.com' '[date]=Sat, 01 Jan 2000 12:00:00 -' +output=$(NOTMUCH_NEW) +pass_if_equal $output Added 1 new message to the database. +printf Searching when all three messages match...\t +output=$($NOTMUCH search findme | notmuch_search_sanitize) +pass_if_equal $output thread:XXX 2000-01-01 [3/3] User, User1, User2; author-reorder-threadtest (inbox unread) +printf Searching when two messages match...\t\t +output=$($NOTMUCH search User1 or User2 | notmuch_search_sanitize) +pass_if_equal $output thread:XXX 2000-01-01 [2/3] User1, User2| User; author-reorder-threadtest (inbox unread) +printf Searching when only one message matches...\t +output=$($NOTMUCH search User2 | notmuch_search_sanitize) +pass_if_equal $output thread:XXX 2000-01-01 [1/3] User2| User, User1; author-reorder-threadtest (inbox unread) +printf Searching when only first message matches...\t +output=$($NOTMUCH search User | notmuch_search_sanitize) +pass_if_equal $output thread:XXX 2000-01-01 [1/3] User| User1, User2; author-reorder-threadtest (inbox unread) + + echo echo Notmuch test suite complete. -- 1.6.6.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] Remove the pipe symbol in the author list when the last author matches
this fixes the bug exposed by the tests for this feature
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
lib/thread.cc |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/lib/thread.cc b/lib/thread.cc
index 4e389c5..1dda220 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -140,6 +140,10 @@ _thread_move_matched_author (notmuch_thread_t *thread,
}
} else {
thread-nonmatched_authors += author_len;
+ /* so now all authors are matched - let's remove the '|' */
+ lastpipe = strchr(thread-authors,'|');
+ if (lastpipe)
+ *lastpipe = ',';
}
return;
}
--
1.6.6.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] removed unused variables
trivial compiler warning fix
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
notmuch-search.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/notmuch-search.c b/notmuch-search.c
index 25c9cfc..8a1cdca 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -104,8 +104,6 @@ format_thread_json (const void *ctx,
const char *authors,
const char *subject)
{
-struct tm *tm;
-char timestamp[40];
void *ctx_quote = talloc_new (ctx);
printf (\thread\: %s,\n
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Allow headers to be shown by default in show mode
On Fri, 23 Apr 2010 12:54:21 +0100, David Edmondson d...@dme.org wrote: Add `notmuch-show-headers-visible' which, when set `t', causes headers to be shown by default. Excellent - Carl, can you pull this into 0.3, please? /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add 'G' keybinding to folder and search view that triggers external poll
On Fri, 23 Apr 2010 08:20:40 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 23 Apr 2010 10:09:03 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: Hehe. Very useful indeed. There is one more thing: Would it be possible to provide user feedback while this is running (synchronously, I guess)? Like having some message in the minibuffer saying Calling all stations and Polling finished, please move along... ? Anything is possible, of course. It just always seems to mean someone learning a bit more elisp. ;-) I'm working on that. Check back in a few months :-) In the meantime, I've found it handy to put my mouse pointer over the emacs window when I run this command. Then I get a nice busy mouse cursor during this operation instead of the standard text-edit bar. That's what I'm doing as well. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: Set fixed time zone
On Fri, 23 Apr 2010 09:36:45 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: When the test suite is run in a different time zone that where Carl lives, some tests may fail depending on the time when the test suite is run. For example, just now I get: By setting a fixed time zone in the test script, these problems should be eliminated. The correct fix is of course that all of you need to move to Portland... :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add 'G' keybinding to folder and search view that triggers external poll
On Fri, 23 Apr 2010 10:09:03 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-04-22, Dirk Hohndel wrote: I appreciate how nicely you can say I liked the idea and then completely rewrote the crap elisp that you submitted :-) Hehe. Very useful indeed. There is one more thing: Would it be possible to provide user feedback while this is running (synchronously, I guess)? Like having some message in the minibuffer saying Calling all stations and Polling finished, please move along... ? Right now all you get is the busy cursor. The problem with the updates is that notmuch/emacs calls just one script. I don't know how to display (progress-) output from that script in the mininuffer... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Updated elisp FCC patches (was: Fcc, Maildir, and Emacs message-mode)
On Fri, 23 Apr 2010 12:08:31 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: My last mail on this issue: I squashed the recent 7 patch series into 4 nicer ones. Rather than resending the patch series, here are the 4 commits from my repo at g...@github.com:spaetz/notmuch-all-feature.git (let me know if I should mail them too). I had talked to Carl about this yesterday - I think we both would prefer that patches be emailed, too. The git trees are great for pulling patches from, but it seems easier to review them here in email... I don't know how to test the emacs interaction or I would have provided some tests with it. Also, I am not sure if the error message still shows up when the user configures a non-existing maildir. But other than that it works nice and reliably here. I have now dumped my python script. I feel pretty confident that this can go in. I will play with it later today. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add NEWS updates for my last batch of patches
in the future I'll include those with my patches. Hope it's ok to do this as one single patch for this series. Signed-off-by: Dirk Hohndel hohn...@infradead.org --- NEWS | 35 +++ 1 files changed, 35 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index eba0fd5..5586386 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,38 @@ + +Even Better guessing of From: header. + + Notmuch now looks at a number of headers when trying to figure out + the best From: header to use in a reply. First it checks whether one + of the user's emails is in To: or Cc:, then it checks Envelope-To: + and X-Original-To: headers, then it analyses the Received headers + checking for a Received: by .. from .. for u...@add.res clause. And + finally it matches domains in the received path. + +Visualization of author names that match a search + + When notmuch displays threads as the result of a search, it now + lists the authors that match the search before listing the other + authors in the thread. It inserts a pipe '|' symbol between the last + matching and first non-matching author. This is especially useful in + a search that includes tag:unread. Now the authors of the unread + messages in the thread are listed first. + +Provide 'd' key binding to add the 'deleted' tag to messages and threads + + The 'd' key works wherever 'a'rchive works - it performs the same + actions but additionally sets the deleted tag. + +Provide 'G' key binding to trigger mail refresh + + The 'G' key works wherever '=' works. Before refreshing the screen + it calls an external program that can be used to poll email servers, + run notmuch new and setup specific tags for the new emails. The + script to be called can be customized with. Use the customize screen + to set the notmuch-poll-script variable to the program that you want + to execute when pressing 'G'. Note that this is synchronous - emacs + will wait until this program finishes. + + Notmuch 0.2 (2010-04-16) This is the second release of the notmuch mail system, with actual -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] RFC: Add From guessing when forwarding email
This adds a new guess-from option to notmuch and modifies the
emacs UI to use this to use the best guess from address when
forwarding email.
Given how little elisp I know I'm quite interested in feedback
and better implementations
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
emacs/notmuch-show.el |8 +++-
notmuch-client.h |3 +
notmuch-reply.c | 110 +
notmuch.c |8
4 files changed, 127 insertions(+), 2 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 53af301..8cec9e8 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -809,8 +809,12 @@ any effects from previous calls to
(defun notmuch-show-forward-message ()
Forward the current message.
(interactive)
- (with-current-notmuch-show-message
- (notmuch-mua-forward-message)))
+ (progn
+(let ((message-id (notmuch-show-get-message-id)))
+ (with-current-notmuch-show-message
+ (progn
+(setq user-mail-address (shell-command-to-string (concat notmuch
guess-from message-id)))
+(notmuch-mua-forward-message))
(defun notmuch-show-next-message ()
Show the next message.
diff --git a/notmuch-client.h b/notmuch-client.h
index 20be43b..ba5b002 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -93,6 +93,9 @@ int
notmuch_reply_command (void *ctx, int argc, char *argv[]);
int
+notmuch_guess_from_command (void *ctx, int argc, char *argv[]);
+
+int
notmuch_restore_command (void *ctx, int argc, char *argv[]);
int
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 230cacc..e9c8449 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -364,6 +364,55 @@ guess_from_received_header (notmuch_config_t *config,
notmuch_message_t *message
return NULL;
}
+/*
+ * simply figure out the best from address to use without creating
+ * a reply buffer or anything else
+ */
+static const char *
+notmuch_guess_from(notmuch_config_t *config, notmuch_query_t *query)
+{
+notmuch_messages_t *messages;
+notmuch_message_t *message;
+InternetAddressList *list;
+InternetAddressMailbox *mailbox;
+InternetAddress *address;
+char *recipients;
+const char *addr;
+const char *from_addr = NULL;
+int i;
+
+for (messages = notmuch_query_search_messages (query);
+notmuch_messages_valid (messages);
+notmuch_messages_move_to_next (messages))
+{
+ message = notmuch_messages_get (messages);
+ if ((asprintf (recipients, %s,%s, notmuch_message_get_header
(message, to),
+ notmuch_message_get_header (message, cc)) == -1) ||
recipients == NULL) {
+ fprintf (stderr, Out of memory\n);
+ return NULL;
+ }
+ list = internet_address_list_parse_string (recipients);
+ for (i = 0; i internet_address_list_length (list); i++) {
+ address = internet_address_list_get_address (list, i);
+ if (! INTERNET_ADDRESS_IS_GROUP (address)) {
+ mailbox = INTERNET_ADDRESS_MAILBOX (address);
+ addr = internet_address_mailbox_get_addr (mailbox);
+ if (address_is_users (addr, config) !from_addr) {
+ from_addr = addr;
+ break;
+ }
+ }
+ }
+ free (recipients);
+ if (from_addr == NULL)
+ from_addr = guess_from_received_header (config, message);
+
+ if (from_addr == NULL)
+ from_addr = notmuch_config_get_user_primary_email (config);
+}
+return from_addr;
+}
+
static int
notmuch_reply_format_default(void *ctx, notmuch_config_t *config,
notmuch_query_t *query)
{
@@ -567,3 +616,64 @@ notmuch_reply_command (void *ctx, int argc, char *argv[])
return ret;
}
+
+int
+notmuch_guess_from_command (void *ctx, int argc, char *argv[])
+{
+notmuch_config_t *config;
+notmuch_database_t *notmuch;
+notmuch_query_t *query;
+char *query_string;
+char const *addr;
+int i, ret = 0;
+
+for (i = 0; i argc argv[i][0] == '-'; i++) {
+ if (strcmp (argv[i], --) == 0) {
+ i++;
+ break;
+ }
+ fprintf (stderr, Unrecognized option: %s\n, argv[i]);
+ return 1;
+}
+
+argc -= i;
+argv += i;
+
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+ return 1;
+
+query_string = query_string_from_args (ctx, argc, argv);
+if (query_string == NULL) {
+ fprintf (stderr, Out of memory\n);
+ return 1;
+}
+
+if (*query_string == '\0') {
+ fprintf (stderr, Error: notmuch reply requires at least one search
term.\n);
+ return 1;
+}
+
+notmuch = notmuch_database_open (notmuch_config_get_database_path (config),
+NOTMUCH_DATABASE_MODE_READ_ONLY);
+if (notmuch == NULL)
+ return 1;
+
+query = notmuch_query_create (notmuch, query_string);
+if (query
Re: [PATCH] removed unused variables
On Fri, 23 Apr 2010 17:55:09 -0700, Carl Worth cwo...@cworth.org wrote: On Thu, 22 Apr 2010 20:26:46 -0700, Dirk Hohndel hohn...@infradead.org wrote: trivial compiler warning fix Thanks. I finally caught up to this. I had seen this patch from you earlier, when I didn't have a convenient working-directory for just applying it---so I've been religiously ignoring those warnings ever since rather than just fixing them. ;-) This is something that I got caught in last night. I have brought in more patches from others, worked on my own patches, and suddenly I got stuck in git-branch-hell and couldn't figure out how to move changes from one branch to another. That's why my reply-guessing-segfault fix is not relative to my last patch... I'm trying to clean up my mess this morning :-) /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Wrapping up the 0.3 release
On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth cwo...@cworth.org wrote: I pushed hard to get most everything we wanted for 0.3 done yesterday, (which was one week since 0.2). I think we're still within the tolerance of my published about a week schedule, but I would like to wrap things up soon. Here are the features that I still have left in my queue at this point: * improve from-header guessing Dirk is looking into fixing a segfault found by the test suite here I sent a patch last night - but it's not realtive to the last thing that I sent, instead relative to last night's master. Do you want me to create another one? Basically, the way I was trying to do concatenation of Received headers earlier was fundamentally broken - it made assumptions about being able to continue reading the headers even after we closed the file already. Not so good. * Fcc, Maildir, and Emacs message-mode -- a bit of code This is next on my list to apply. Thanks for the extra testing! There are a few other features that people had proposed but that didn't pass review yet. If people follow-up with those quickly, they can still go in. Otherwise, there's another new merge window coming up soon! I'll be working on notmuch for the next few hours and once my git trees are straightened out again, I'll look into what's missing from my wish list Meanwhile, I'm aware of two regressions I'd like to see fixed before 0.3: * Reply is now splitting the window We're copying the original message into the new reply buffer, so what's the advantage of splitting here? I'll voice my don't like of this feature as well, I guess. * Composing a new message with 'm' brings up headers in a scrambled order. A minor point, but it would be nice to fix this. It doesn't for me with origin/master. Or let me double check... what do you think would be the correct order (as this is a matter of taste for some people)... Finally, any of the tweaks I suggested to notmuch-hello mode would be quite welcome. I might take a whack at some of these. Then, there's the task of writing up NEWS. Dirk started helping with that, which I appreciate. If anyone else wants to write up descriptions of their favorite features that have been merged, that would be great. I think we should make this a requirement for patches to include a little NEWS blurb and either a test case or an explanation why there isn't a test case... /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Clean up author display for some Last, First cases
On Sat, 24 Apr 2010 08:30:22 -0700, Carl Worth cwo...@cworth.org wrote: On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel hohn...@infradead.org wrote: +/* clean up the uggly Lastname, Firstname format that some mail systems + * (most notably, Exchange) are creating to be Firstname Lastname + * To make sure that we don't change other potential situations where a + * comma is in the name, we check that we match one of these patterns + * Last, First first.l...@company.com + * Last, First MI first.mi.l...@company.com This is an interesting idea. We could make it a little more flexible by doing a regexp comparison of first.*last against the email address, (perhaps people have email addresses like carl_wo...@example.com?) I'll look into that. We actually had some discussion about this on IRC and I was thinking of taking this feature to a new level... something like: - by default we show names as they come in (least surprise) - we offer to reverse Last, First - we offer to shorten to FirstL - we offer an alias map So I could define that mail from cwo...@cworth.org gets the author listed as cworth. Or as CarlW. +char *cleanauthor,*testauthor; I'd much rather see an underscore separating two words in a single identifier, (so clean_author, test_author). Happy to comply to your preferences in the future + /* let's assemble what we think is the correct name */ + lname = comma - author; + fname = strlen(author) - lname - 2; + strncpy(cleanauthor, comma + 2, fname); + *(cleanauthor+fname) = ' '; + strncpy(cleanauthor + fname + 1, author, lname); + *(cleanauthor+fname+1+lname) = '\0'; The comment above, (what we think is the correct name), didn't help me understand what the code is doing. And the code is hard enough to follow that I could really use some help. Something like: /* Break at comma and reverse: Last, First etc. - First Last etc. */ Ok, I'll try to be more explicit in documenting algorithms Lots of little additions here and there so plenty of chance for an off-by-one. Do we have a test case for this yet? Nope. Will do. + /* make a temporary copy and see if it matches the email */ + testauthor = xstrdup(cleanauthor); It would be preferable to use talloc functions consistently. (Existing occurrences of xstrdup in the code base are for the sake of talloc-unfriendly glib data structures like GHashTable.) As is, testauthor is leaking. Oops. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Fix i-search to open up invisible citations as necessary
On Sat, 24 Apr 2010 07:42:48 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson d...@dme.org wrote: Add an `isearch-open-invisible' property to the overlays used to hide citations and signatures, together with an appropriate function to leave the invisible text visible should that be required. This is a fantastic feature, David. Thanks! This is pushed. I knew emacs could do this kind of thing, and I had even tried to implement it once, but I hadn't succeeded for some reason. Next, I wonder if we shouldn't do something similar for the search view. It might be quite handy if all authors and all unique subjects for a thread were made available for i-search in the buffer, but hidden by default and expanded as needed like this. What do you think? I would love this /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Reordering of thread authors to list matching authors first
On Fri, 23 Apr 2010 17:21:53 -0700, Carl Worth cwo...@cworth.org wrote:
On Wed, 21 Apr 2010 20:58:27 -0700, Dirk Hohndel hohn...@infradead.org
wrote:
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from
the
non-matching ones with a '|' instead of a ','
It seems a reasonable feature to me.
I switched back to origin/master to help get ready for 0.3 and
tremendously miss this feature :-)
Some notes on the patch:
+void
+notmuch_message_set_author (notmuch_message_t *message,
+ const char *author)
+{
+message-author = talloc_strdup(message, author);
+return;
+}
This is leaking any previously set author value, (admittedly, it's only
a talloc leak so it will still get cleaned up when the message is
cleaned up, but still.
Fixed in forthcoming revision of this patch
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message
+ */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char
*author);
+
+/* Get the author member of 'message'
+ */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
The notmuch.h file is our publicly installed header file for the library
interface. I don't think the feature here requires any new library
interface. Even if it did, we wouldn't want a public function like
set_author that could simply scramble internal state and change the
result of future calls to get_author.
My mistake - moved them to notmuch-private.h
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
The implementation here seems a bit fiddly.
We already have two passes over the messages, (first all messages, and
then all matched messages). And we're currently calling add_author from
the first pass.
How about simply calling a new add_matched_author from the second pass
which would look very much like the existing add_author. Then we could
change add_author to accumulate authors into an array rather than a
string. Then, finally, we would append any of these authors not already
in the matched_authors hash tabled onto the final string.
That should be less code and easier to understand I think.
I can take a whack at that later if you don't beat me to it.
Maybe I'm misunderstanding your proposed algorithm - but it seems quite
a bit more complicated than what I'm doing today...
/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
new patch series for author reordering code
I tried to break this out into logically independent pieces - but to connect this as a series. First we add the authors member and accessors to message Second the reordering of thread authors (still the original string based algorithm that I used before - I couldn't quite make sense of cworth's proposed algorithm Third a NEWS blurb Fourth test for the new functionality Fifth a first simple routine to make author names easier to read - this one undoes the typical Exchange ugliness I think this could go into 0.3 as is. I've been using the mostly identical previous version for about a week - the changes here are mostly cleanup based on cworth's feedback. I am planning to enhance the display author names in a friendlier way feature in the future, capturing more cases. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/5] Reorder displayed names of thread authors
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','
Imagine the default +inbox query. Those mails in the thread that
match the query are actually new (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
Dirk Hohndel - I think it should first show the actual author(s) of the new
mail(s).
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
lib/thread.cc | 77 +
1 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/lib/thread.cc b/lib/thread.cc
index e1da060..c80bb26 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
char *subject;
GHashTable *authors_hash;
char *authors;
+char *nonmatched_authors;
GHashTable *tags;
notmuch_message_list_t *message_list;
@@ -73,6 +74,79 @@ _thread_add_author (notmuch_thread_t *thread,
thread-authors = talloc_strdup (thread, author);
}
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * existing order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authors_copy;
+char *current_author;
+char *last_pipe,*next_pipe;
+int idx,nm_start,author_len,authors_len;
+
+if (thread-authors == NULL || author == NULL)
+ return;
+if (thread-nonmatched_authors == NULL)
+ thread-nonmatched_authors = thread-authors;
+author_len = strlen(author);
+authors_len = strlen(thread-authors);
+if (author_len == authors_len) {
+ /* just one author */
+ thread-nonmatched_authors += author_len;
+ return;
+}
+current_author = strcasestr(thread-authors, author);
+if (current_author == NULL)
+ return;
+/* how far inside the nonmatched authors is our author? */
+idx = current_author - thread-nonmatched_authors;
+if (idx 0) {
+ /* already among matched authors */
+ return;
+}
+/* are there any authors in the list after our author? */
+if (thread-nonmatched_authors + author_len thread-authors +
authors_len) {
+ /* we have to make changes, so let's get a temp copy */
+ authors_copy = talloc_strdup(thread,thread-authors);
+ /* nm_start is the offset into where the non-matched authors start */
+ nm_start = thread-nonmatched_authors - thread-authors;
+ /* copy this author and add the | - the if clause above tells us
there's more */
+ strncpy(thread-nonmatched_authors,author,author_len);
+ strncpy(thread-nonmatched_authors+author_len,| ,2);
+ thread-nonmatched_authors += author_len+2;
+ if (idx 0) {
+ /* we are actually moving authors around, not just changing the
separator
+ * first copy the authors that came BEFORE our author */
+ strncpy(thread-nonmatched_authors, authors_copy+nm_start, idx-2);
+ /* finally, if there are authors AFTER our author, copy those */
+ if(author_len+nm_start+idx authors_len) {
+ strncpy(thread-nonmatched_authors + idx - 2,, ,2);
+ strncpy(thread-nonmatched_authors + idx, authors_copy+nm_start +
idx + author_len + 2,
+ authors_len - (nm_start + idx + author_len + 2));
+ }
+ }
+ /* finally let's make sure there's just one '|' in the authors string */
+ last_pipe = strchr(thread-authors,'|');
+ while (last_pipe) {
+ next_pipe = strchr(last_pipe+1,'|');
+ if (next_pipe)
+ *last_pipe = ',';
+ last_pipe = next_pipe;
+ }
+} else {
+ thread-nonmatched_authors += author_len;
+ /* so now all authors are matched - let's remove the '|' */
+ last_pipe = strchr(thread-authors,'|');
+ if (last_pipe)
+ *last_pipe = ',';
+}
+return;
+}
+
/* Add 'message' as a message that belongs to 'thread'.
*
* The 'thread' will talloc_steal the 'message' and hold onto a
@@ -110,6 +184,7 @@ _thread_add_message (notmuch_thread_t *thread,
author = internet_address_mailbox_get_addr (mailbox);
}
_thread_add_author (thread, author);
+ notmuch_message_set_author (message, author);
}
g_object_unref (G_OBJECT (list));
}
@@ -182,6 +257,7 @@ _thread_add_matched_message (notmuch_thread_t *thread,
notmuch_message_set_flag (hashed_message
[PATCH 1/5] Add authors member to message
message-authors contains the author's name (as we want to print it)
get / set methods are declared in notmuch-private.h
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
lib/message.cc| 18 ++
lib/notmuch-private.h | 10 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..4b2f98f 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
char *thread_id;
char *in_reply_to;
char *filename;
+char *author;
notmuch_message_file_t *message_file;
notmuch_message_list_t *replies;
unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
message-in_reply_to = NULL;
message-filename = NULL;
message-message_file = NULL;
+message-author = NULL;
message-replies = _notmuch_message_list_create (message);
if (unlikely (message-replies == NULL)) {
@@ -533,6 +535,22 @@ notmuch_message_get_tags (notmuch_message_t *message)
return _notmuch_convert_tags(message, i, end);
}
+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message-author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+ const char *author)
+{
+if (message-author)
+ talloc_free(message-author);
+message-author = talloc_strdup(message, author);
+return;
+}
+
void
_notmuch_message_set_date (notmuch_message_t *message,
const char *date)
diff --git a/lib/notmuch-private.h b/lib/notmuch-private.h
index 94cce1b..6e83cc3 100644
--- a/lib/notmuch-private.h
+++ b/lib/notmuch-private.h
@@ -275,6 +275,16 @@ _notmuch_message_talloc_copy_data (notmuch_message_t
*message);
void
_notmuch_message_clear_data (notmuch_message_t *message);
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message' */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
+
/* index.cc */
notmuch_status_t
--
1.6.6.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/5] Add NEWS section for author reordering
This should be required in all patches Signed-off-by: Dirk Hohndel hohn...@infradead.org --- NEWS | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index eba0fd5..c2057c2 100644 --- a/NEWS +++ b/NEWS @@ -1,3 +1,13 @@ + +Visualization of author names that match a search + + When notmuch displays threads as the result of a search, it now + lists the authors that match the search before listing the other + authors in the thread. It inserts a pipe '|' symbol between the last + matching and first non-matching author. This is especially useful in + a search that includes tag:unread. Now the authors of the unread + messages in the thread are listed first. + Notmuch 0.2 (2010-04-16) This is the second release of the notmuch mail system, with actual -- 1.6.6.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: improve from-header guessing
On Fri, 23 Apr 2010 11:47:04 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 16 Apr 2010 13:51:40 -0700, Dirk Hohndel hohn...@infradead.org wrote: The following two patches should address most of the concerns raised to my previous series. Allow me to raise new concerns then. ;-) Any time The first patch simply adds an interface to obtain a concatenation of all instances of a specific header from an email. I was hoping to see the special-case value of NULL go away with this change. And I like that there's a new function to get the concatenated header, (I would prefer an unabbreviated name of get_concatenated_header than get_header_concat), but I don't like seeing all the existing callers of get_header updated to pass an extra 0. Instead, I'd prefer to see those calls unchanged, and a tiny new get_header that passes the 0 and then make the actual implementing function be static and named something like notmuch_message_file_get_header_internal. Turns out that the way I did this was broken anyway. So we can simply forget these patches and your concerns. I'm sure you'll raise new concerns on the new (rearchitected) patches. Both patches have some trailing whitespace. I see these easily wince I have the following in my ~/.gitconfig: [core] whitespace = trailing-space,space-before-tab I know. I'm trying to be better about checking whitespace pollution before submitting things. Finally, I'd like to see some tests for this feature. (But we do have the feature already without tests, so I won't strictly block on that). Hu? You even commited these already. Or am I reading email out of order again? /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Wrapping up the 0.3 release
On Sat, 24 Apr 2010 14:45:45 -0700, Carl Worth cwo...@cworth.org wrote: It doesn't for me with origin/master. Or let me double check... what do you think would be the correct order (as this is a matter of taste for some people)... The order in the reply buffer is fine. But with m I get the User-Agent first which looks a bit strange. Yep, same here. Dirk also mentioned in IRC that there's a regression with the signature being mispositioned before the quoted text with a reply buffer. Now that I've added a signature, I'm noticing this as well. Well - we don't seem to be adding the signature ourselves anymore... I still don't quite understand where and how we hand over to the existing message-mode functions - I why those decide to insert a signature at point. Here's a trivial patch that ALSO adds a signature at the end of the message buffer (where it belongs). But I haven't figured out how to get rid of the one above the reply... diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index acb7dbf..493cd0e 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -63,6 +63,7 @@ ;; line and then the body. (with-temp-buffer (call-process notmuch-command nil t nil reply query-string) + (message-insert-signature) (goto-char (point-min)) (if (re-search-forward ^$ nil t) (save-excursion I think we should make this a requirement for patches to include a little NEWS blurb and either a test case or an explanation why there isn't a test case... I've asked for these, but I haven't been pushing hard on this. I will start playing the nagger Review for some of these simple things would be much appreciated from anybody on the list, (and would help ensure that patches are more likely to be ready-to-go once I get them). So let's see more of things like this from anyone on the list: Looks like a great feature---now it just needs a test case. I've tested this and it does just what I want. Here's a follow-on patch that adds an item to the NEWS file for this. I can't common on the specific logic of the patch, but I did notice some trailing whitespace. You'll want to clean that up and resubmit so the patch won't be rejected. I can do all of those. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Wrapping up the 0.3 release
On Sat, 24 Apr 2010 15:05:55 -0700, Dirk Hohndel hohn...@infradead.org wrote: Dirk also mentioned in IRC that there's a regression with the signature being mispositioned before the quoted text with a reply buffer. Now that I've added a signature, I'm noticing this as well. Well - we don't seem to be adding the signature ourselves anymore... I still don't quite understand where and how we hand over to the existing message-mode functions - I why those decide to insert a signature at point. Learning elisp every day. I think I now understand at least somewhat what's happening there... Here's a trivial patch that ALSO adds a signature at the end of the message buffer (where it belongs). But I haven't figured out how to get rid of the one above the reply... diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index acb7dbf..493cd0e 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -63,6 +63,7 @@ ;; line and then the body. (with-temp-buffer (call-process notmuch-command nil t nil reply query-string) + (message-insert-signature) (goto-char (point-min)) (if (re-search-forward ^$ nil t) (save-excursion This patch is of course completely bogus. But understanding why it was bogus helped me come up with this patch, that hopefully makes more sense. People who ACTUALLY understand elisp - please take a look (I could have sworn there was a variable somewhere that gives me the correct regex to search for a signature separator... but I can't find it. so please replace '-- ' with that if you know) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index acb7dbf..05c9603 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -82,7 +82,13 @@ (message-hide-headers) (save-excursion (goto-char (point-max)) - (insert body)) + (if (re-search-backward -- nil t) + (progn + (forward-line -1) + (insert body)) + (progn + (goto-char (point-max)) + (insert body (set-buffer-modified-p nil))) (defun notmuch-mua-forward-message () -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 7/7] Integrate notmuch-fcc mechansim
On Fri, 23 Apr 2010 11:38:57 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: I have gone wild and added a defcustom notmuch-fcc-dirs. Depending on the value of that variable we will not do any maildir fcc at all (nil, the default), or it is of the format ((defaultsentbox) (full name em...@address . Work/sentbox) (full name2 ema...@address2 . Work2/sentbox)) I love this feature (unsurprising, as I was the one who requested it repeatedly...). One question from the elisp noop: + (let ((subdir (cdr (assoc (message-fetch-field from) notmuch-fcc-dirs Why not make this (let ((subdir (cdr (assoc-string (message-fetch-field from) notmuch-fcc-dirs t and have the association be case insensitive? /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: Adding an attachment composition interface to notmuch
On Sun, 25 Apr 2010 21:06:01 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote: Tach is a minor mode that adds mutt-like attachment handling to message mode. It's not notmuch specific, but I wrote it to use with notmuch, and I thought it might be of use to some on the list. I wanted to see if there would be any interest in adding this to notmuch in 0.4 or after. It makes composing messages with attachments much more pleasant that using raw mml-mode, and would likely be much more accomodating to new users. With the new notmuch-mua hooks, it would be easy to turn on and off as well. I've been using it for a number of months, and have not had any problems with it. I have not played with the version you posted earlier - sofar I use the attachment functionality that Emacs offers by default and I agree that this is lacking. From your description I can't quite tell if tach is overkill, though. When I just attach a file I'd like to be able to do this just using the minibuffer to pick a file - not having to open another buffer, press +, find the file, etc... One issue to note: if you start composing a message with tach-mode enabled, and then disable it, the attachments you added with tach won't get added properly (there will just be a plaintext list of them at the the bottom of the message after a separator). In other words, tach converts the attachment list on sending, just as message-mode adds headers, removes text follows this line, etc. This doesn't seem like an issue to me (a message started by message-mode can't be sent by another MUA either) but I did want to bring it to people's attention. I think that's reasonable If there is interest, I would take the necessary steps to integrate it and prepare a patch. I'd be interested to see a notmuch integration... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Some messages show only headers.
On Sun, 25 Apr 2010 10:57:10 +0530, Abhishek Dasgupta abh...@gmail.com wrote: Hi all, I've been using notmuch for some time, and I noticed that some mails show only the header when pressing [return] on notmuch-show-all. If I press [return] on the highlighted From: header then the entire message displays. This may be the bug that David fixed this morning - under some circumstances mails that matched the search were not displayed until you either hid and un-hid them or hid the headers. Is this behaviour expected? The default behaviour in most other MUAs is to show the message in full. notmuch should show all messages that match the search by default - other messages in the thread are shown closed. I think Carl already pushed the fix. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Allow headers to be shown by default in show mode
On Mon, 26 Apr 2010 11:55:33 +0100, David Edmondson d...@dme.org wrote: On Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth cwo...@cworth.org wrote: On Fri, 23 Apr 2010 21:08:48 +0100, David Edmondson d...@dme.org wrote: I like the current behaviour, but changing the default would be fine. Which parts of it do you like? Being able to toggle the header back and forth? Or just that the hidden headers take up so little vertical space? Both, particularly that the headers can be hidden by default. Mostly I care about what you have to say and who you are, not who you said it to. I think that this is something where we really need a customization - as my preference is the exact opposite of David's. Since I get email from so many people it really helps me to understand the context (and who else an email was sent to) when browsing through mail... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: More DWIM when editing messages
On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson d...@dme.org wrote: For composing new messages and forwarding, leave the cursor on the 'To:' field. For replies, leave the cursor at the start of the body. In all cases, mark the buffer as not modified so that the user is not prompted if she decides to immediately kill the buffer. YES! Brilliant. I didn't realize how much I wanted it till you sent this. Carl, please include in 0.3 /D --- emacs/notmuch-mua.el | 32 +++- 1 files changed, 19 insertions(+), 13 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index bca20db..c7a9aee 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -98,21 +98,24 @@ list. collect header))) (message-sort-headers) (message-hide-headers) -(save-excursion - (goto-char (point-max)) - (insert body)) -(set-buffer-modified-p nil))) +(goto-char (point-max)) +(insert body)) +(set-buffer-modified-p nil) + +(message-goto-body)) (defun notmuch-mua-forward-message () (message-forward) - (save-excursion -(when notmuch-mua-user-agent-function - (let ((user-agent (funcall notmuch-mua-user-agent-function))) - (when (not (string= user-agent)) - (message-add-header (format User-Agent: %s user-agent) -(message-sort-headers) -(message-hide-headers)) - (set-buffer-modified-p nil)) + + (when notmuch-mua-user-agent-function +(let ((user-agent (funcall notmuch-mua-user-agent-function))) + (when (not (string= user-agent)) + (message-add-header (format User-Agent: %s user-agent) + (message-sort-headers) + (message-hide-headers) + (set-buffer-modified-p nil) + + (message-goto-to)) (defun notmuch-mua-mail (optional to subject other-headers continue switch-function yank-action send-actions) @@ -126,7 +129,10 @@ list. (message-mail to subject other-headers continue switch-function yank-action send-actions) (message-sort-headers) - (message-hide-headers)) + (message-hide-headers) + (set-buffer-modified-p nil) + + (message-goto-to)) (defun notmuch-mua-send-and-exit (optional arg) (interactive P) -- 1.7.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] Make Received: header special in notmuch_message_file_get_header
With this patch the Received: header becomes special in the way
we treat headers - this is the only header for which we concatenate
all the instances we find (instead of just returning the first one).
This will be used in the From guessing code for replies as we need to
be able to walk ALL of the Received: headers in a message to have a
good chance to guess which mailbox this email was delivered to.
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
lib/message-file.c| 58 ++---
lib/notmuch-private.h |3 ++
2 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/lib/message-file.c b/lib/message-file.c
index 0c152a3..7722832 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -209,17 +209,24 @@ copy_header_unfolding (header_value_closure_t *value,
/* As a special-case, a value of NULL for header_desired will force
* the entire header to be parsed if it is not parsed already. This is
- * used by the _notmuch_message_file_get_headers_end function. */
+ * used by the _notmuch_message_file_get_headers_end function.
+ * Another special case is the Received: header. For this header we
+ * want to concatenate all instances of the header instead of just
+ * hashing the first instance as we use this when analyzing the path
+ * the mail has taken from sender to recipient.
+ */
const char *
notmuch_message_file_get_header (notmuch_message_file_t *message,
const char *header_desired)
{
int contains;
-char *header, *decoded_value;
+char *header, *decoded_value, *header_sofar, *combined_header;
const char *s, *colon;
-int match;
+int match, newhdr, hdrsofar, is_received;
static int initialized = 0;
+is_received = (strcmp(header_desired,received) == 0);
+
if (! initialized) {
g_mime_init (0);
initialized = 1;
@@ -312,22 +319,39 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
NEXT_HEADER_LINE (message-value);
- if (header_desired == 0)
+ if (header_desired == NULL)
match = 0;
else
match = (strcasecmp (header, header_desired) == 0);
decoded_value = g_mime_utils_header_decode_text (message-value.str);
- if (g_hash_table_lookup (message-headers, header) == NULL) {
- /* Only insert if we don't have a value for this header, yet.
-* This way we always return the FIRST instance of any header
-* we search for
-* FIXME: we should be returning ALL instances of a header
-*or at least provide a way to iterate over them
-*/
- g_hash_table_insert (message-headers, header, decoded_value);
+ header_sofar = (char *)g_hash_table_lookup (message-headers, header);
+ /* we treat the Received: header special - we want to concat ALL of
+* the Received: headers we encounter.
+* for everything else we return the first instance of a header */
+ if (is_received) {
+ if (header_sofar == NULL) {
+ /* first Received: header we encountered; just add it */
+ g_hash_table_insert (message-headers, header, decoded_value);
+ } else {
+ /* we need to add the header to those we already collected */
+ newhdr = strlen(decoded_value);
+ hdrsofar = strlen(header_sofar);
+ combined_header = xmalloc(hdrsofar + newhdr + 2);
+ strncpy(combined_header,header_sofar,hdrsofar);
+ *(combined_header+hdrsofar) = ' ';
+ strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+ g_hash_table_insert (message-headers, header, combined_header);
+ }
+ } else {
+ if (header_sofar == NULL) {
+ /* Only insert if we don't have a value for this header, yet. */
+ g_hash_table_insert (message-headers, header, decoded_value);
+ }
}
- if (match)
+ /* if we found a match we can bail - unless of course we are
+* collecting all the Received: headers */
+ if (match !is_received)
return decoded_value;
}
@@ -347,6 +371,14 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
message-value.len = 0;
}
+/* For the Received: header we actually might end up here even
+ * though we found the header (as we force continued parsing
+ * in that case). So let's check if that's the header we were
+ * looking for and return the value that we found (if any)
+ */
+if (is_received)
+ return (char *)g_hash_table_lookup (message-headers, received);
+
/* We've parsed all headers and never found the one we're looking
* for. It's probably just not there, but let's check that we
* didn't make a mistake preventing us from seeing it. */
diff --git a/lib/notmuch-private.h b/lib
Re: [PATCH] emacs: More DWIM when editing messages
On Mon, 26 Apr 2010 10:28:33 -0700, Carl Worth cwo...@cworth.org wrote: On Mon, 26 Apr 2010 09:31:49 -0700, Dirk Hohndel hohn...@infradead.org wrote: On Mon, 26 Apr 2010 15:01:25 +0100, David Edmondson d...@dme.org wrote: For composing new messages and forwarding, leave the cursor on the 'To:' field. For replies, leave the cursor at the start of the body. In all cases, mark the buffer as not modified so that the user is not prompted if she decides to immediately kill the buffer. YES! Brilliant. I didn't realize how much I wanted it till you sent this. Carl, please include in 0.3 Agreed! This is *so* pleasant. Thanks, David! This is pushed. This appears not to have gone out??? Must be that weird MUA that I'm using... From cbd9c96450f6481433877410bcf075d482b4be1b Mon Sep 17 00:00:00 2001 From: Dirk Hohndel hohn...@infradead.org Date: Mon, 26 Apr 2010 10:41:49 -0700 Subject: [PATCH] Put signatures at the very end of the message The existing code inserts the signature before inserting the message body (which it puts at the very end of the buffer - therefore AFTER the signature). This little snippet makes us search backwards and insert the message body before a signature, if it exists. Signed-off-by: Dirk Hohndel hohn...@infradead.org --- emacs/notmuch-mua.el |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index c7a9aee..9fbb94a 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -98,11 +98,16 @@ list. collect header))) (message-sort-headers) (message-hide-headers) +;; insert the message body - but put it in front of the signature +;; if one is present (goto-char (point-max)) +(if (re-search-backward -- nil t) + (forward-line -1) + (goto-char (point-max))) (insert body)) -(set-buffer-modified-p nil) + (set-buffer-modified-p nil) -(message-goto-body)) + (message-goto-body)) (defun notmuch-mua-forward-message () (message-forward) -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: fcc should fail at the right time if it doesn't point to a maildir
On Mon, 26 Apr 2010 20:29:27 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: Throw an error after the maildir is generated but before the message is sent. This change allows the user to edit the maildir if it fails, so that it will point to a correct place. Note that this changes the previous behavior which always overwrote the existing Fcc line. Now, an Fcc line is only auto-generated if there isn't one already there. I like this behavior The ideal change would be to prompt to create a maildir. This should enable a place for doing that in a future patch. It would also be nice to catch the common mistake of not ending the message-directory with a / /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
For 0.3.1: fix SEGV in notmuch search if author name ends in comma
Another incredibly stupid bug in my code. Rather obvious fix (I hope) coming up. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] Fix SEGV in _thread_cleanup_author if author ends with ', '
Admittedly, an author name ending in ',' guarantees this is spam, and
indeed this was triggered by a spam email, but that doesn't mean we
shouldn't handle this case correctly.
We now check that there is actually a component of the name (presumably
the first name) after the comma in the author name.
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
lib/thread.cc | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/lib/thread.cc b/lib/thread.cc
index dc74ee3..13872d4 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -156,11 +156,19 @@ _thread_cleanup_author (notmuch_thread_t *thread,
char *blank;
int fname,lname;
+if (author == NULL)
+ return NULL;
clean_author = talloc_strdup(thread, author);
if (clean_author == NULL)
return NULL;
+/* check if there's a comma in the name and that there's a
+ * component of the name behind it (so the name doesn't end with
+ * the comma - in which case the string that strchr finds is just
+ * one character long ,\0).
+ * Otherwise just return the copy of the original author name that
+ * we just made*/
comma = strchr(author,',');
-if (comma) {
+if (comma strlen(comma) 1) {
/* let's assemble what we think is the correct name */
lname = comma - author;
fname = strlen(author) - lname - 2;
@@ -180,7 +188,6 @@ _thread_cleanup_author (notmuch_thread_t *thread,
/* we didn't identify this as part of the email address
* so let's punt and return the original author */
strcpy (clean_author, author);
-
}
return clean_author;
}
--
1.6.6.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] Update NEWS to reflect the SEGV bugfix
Signed-off-by: Dirk Hohndel hohn...@infradead.org --- NEWS |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index ce0ea45..035e25e 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,12 @@ Notmuch 0.3.1 (2010-04-27) == General bug fix --- +Fix a potential SEGV in notmuch search + + This bug could be triggered by an author name ending in a ','. + Admittedly - that's almost certainly a spam email. Still needs + to be handled correctly. + Fix an infinite loop in notmuch reply This bug could be triggered by replying to a message where the -- 1.6.6.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Allow the display of absolute dates in the header line.
On Wed, 19 May 2010 07:44:18 +0100, David Edmondson d...@dme.org wrote: Add `notmuch-show-relative-dates' to control whether the summary line in `notmuch-show' mode displays relative dates (e.g. '26 mins. ago') or the full date string from the message. Default to `t' for compatibility with the previous behaviour. Excellent - thanks for providing this (and all I did was mention it briefly on IRC... I love this project) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] remove message archiving from show-advance-and-archive
On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth cwo...@cworth.org wrote: On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins jroll...@finestructure.net wrote: The function to advance through threads with the space bar is useful. However, the current implementation also archives messages. The idea of archiving a message should not be intertwined with the processes of advancing through messages to read them. Archiving in general should be a separate operation that one does explicitly. This patch just renames the advance function notmuch-show-advance, and removes the archiving of a thread when the end of the thread is reached. The other piece of the magic space bar that people have complained about is that it intertwines advancing among messages within one thread with advancing from one thread to the next. (And only the first operation is reversible by backspace.) This has always confused me - I think I've complained about it before as well :) I think we'll probably want to change that at the same time. Meanwhile, I'm currently working on support for piping a whole thread of messages as an mbox to a process, (mostly getting bogged down in trying to fix mbox support in git). For that, I think I want the current '|' binding to pipe the current message and then a new binding (M-| ?) to pipe every (open) message in the thread. Which makes me think that other operations should work similarly. '+' and '-' should change tags on the current message (as they do currently) and then new M-+ and M-- could change tags on all (open) messages in the thread. That would highlight the current 'a' as out of place since it's currently archiving every message in the thread. So I'd then fix it to be 'a' for the current message and M-a for every (open) message in the thread. I really like this. It's consistent and I'm sure I'll get used to it quickly. The only question now is all messages in a thread or all open messages in a thread. I'd vote for all. Oh - and I really want a way to do surgery on threads. Merge threads to fix Blackberry users breaking threads. And split threads for hijackers... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: fix problem with notmuch-hello-nice-number
On Thu, 10 Jun 2010 08:05:13 +0100, David Edmondson d...@dme.org wrote: On Wed, 09 Jun 2010 07:49:01 -0700, Dirk Hohndel hohn...@infradead.org wrote: Without this little patch notmuch fails with current git if there's a saved search that has zero results How about: diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index a6e8a47..48bb6e3 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -115,6 +115,7 @@ Typically \,\ in the US and UK and \.\ in Europe. (while ( n 0) (push (% n 1000) result) (setq n (/ n 1000))) +(setq result (or result '(0))) (apply #'concat (number-to-string (car result)) (mapcar (lambda (elem) Much better. Mine made sense when you looked at it - this one has a much more emacs-y feel to it in that I need to stare at it for 30 seconds before I can grasp what it does :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/3] build fixes
On Mon, 14 Jun 2010 17:17:00 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, Is anything wrong with these patches? cworth - our fearless leader - is extremely busy with his day job right now. He tends to respond to all the patches on the mailing list as soon as he finds time; sometimes within minutes, sometimes it takes weeks... you appear to have hit one of the slow spots. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
thread sorting ideas
Here is a feature that I could really use some times... Instead of sorting the threads based on the date of the first message in the thread, sort them based on the newest message in the thread. So if I take a quick look at the bottom (I am an oldest first kinda person) of a search and I see all the threads that have the newest messages. My suggestion would be to turn 'o' into a two key command: o-o : oldest first, sort by oldest message in thread o-O : oldest first, sort by newest message in thread o-n : newest first, sort by oldest message in thread o-N : newest first, sort by newest message in thread o-s : sort by subject? o-z : unthreaded, sort by message size? you can come up with many more sort ideas... /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Maildir synchronization v2
On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: On Wed, 13 Oct 2010, Servilio Afre Puentes wrote: On 13 October 2010 08:13, Michal Sojka sojk...@fel.cvut.cz wrote: [...] THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of unread messages doesn't work. The reason is that when you view the message its unread tag is removed which causes the file to be renamed, but Emacs still uses the original name to access the attachment. You can workaround this by closing the message and opening it again. This issue will be fixed after we (I) implement notmuch cat command. With this command, emacs would not access the messages by the file name, but by running notmuch cat id:message-id which will always give the correct content. Wouldn't it be more efficient to query notmuch for the filename using the message ID we store in the DB? When network usage is implemented, tramp can give us transparent remote file access in emacs. Tramp would not be available in non-emacs GUIs. Also, when notmuch cat is implemented, emacs gui will be usable remotely by simply defining notmuch-command variable to contain the name of the script containing: ssh u...@host notmuch $@ That to me is certainly a very elegant solution... so what's stopping us from implementing notmuch cat? No one taken the time to do it? Or is there a design issue left to be resolved? /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuchsync: handling of the deleted tag
On Fri, 12 Nov 2010 08:30:36 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: On Thu, 11 Nov 2010 17:27:34 -0800, Carl Worth cwo...@cworth.org wrote: So, what we probably need here is for the user to be able to configure the mapping and in a fairly sophisticated way: 'R' on _any_ filename - replied tag gets added 'T' on _all_ filenames - deleted tag gets added 'S' on _any_ filename - unread tag gets removed So maybe something like that? Maybe, but that sounds like a horribly complex configuration, in which the user has to really think through what he wants (and can still make blunders). :) If notmuch gave me at least all filenames that are associated with a mail id, I could introduce a command line option --prune --safe which would Right, you pushed the ball in my court. The only problem is that -- with the arrival of maildir sync -- I lost my motivation to work on notmuchsync. Seriously, what does notmuchsync still provide that notmuch cannot do? I wonder if I shouldn't stick a deprecated warning on it. Please don't! I use it all the time: I use it to archive mail that I don't want on an imap server any more, but in a local maildir. Can't do that with notmuch. I use it to prune mail that has the deleted tag. Again not something that notmuch supports. So please don't stop supporting your very important (to me) tool! /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] add headers cc: bcc: and to: (as exactto:) to search index
On Wed, 1 Dec 2010 21:33:55 +0100, Joel Borggrén-Franck joel.borggren.fra...@gmail.com wrote: From: Joel Borggrén-Franck j...@codehouse.se Add headers cc: bcc: and to: to index. Real header to: is searched as exactto:f...@bar.baz and search term to: is kept as a union of cc:, bcc: and to: for backward compatibility. Use search term cc: resp. bcc: to search those headers respectively. cworth has been talking for a while about changing notmuch to index all of the headers - this is one of my key missing features at this point. Searching for Sender: or X-Mailing-List: or (PLEASE) X-Spam-Score: /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
On Sat, 21 May 2011 08:35:13 +0200, Matthias Guedemann matthias.guedem...@ovgu.de wrote: Hi all, I am using notmuch / emacs as my main mail client now for several months and loosely follow master. After an update yesterday I now have problems with some multipart/mixed mails from mailing lists which are displayed for example as follows (I could also provide the raw mail if needed): 8-- Subject: [Haskell-cafe] Can't access map value with key. To: haskell-c...@haskell.org haskell-c...@haskell.org Date: Sat, 21 May 2011 04:04:31 +0200 [ multipart/mixed ] [ text/html ] ___ Haskell-Cafe mailing list haskell-c...@haskell.org http:// www.haskell.org/mailman/listinfo/haskell-cafe [ ATT1.c: text/plain ] [ 4-line signature. Click/Enter to toggle visibility. ] 8-- i.e. the html part is not displayed. I'd like to have it displayed inline (using w3m), just as other html mails and just like it worked before (at least I think it worked). I probably just missed a simple configuration option. If you did then I'm in the same boat. Notmuch/emacs used to display both parts, text and html, and now only displays text with no way (that I could find) to display the html part as well. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
Hehe, as the reply below shows... there's still something screwy even with the latest git version... in multipart messages things just go wrong. Whether I reply (this below should have included your text/plain part as quote), or whether I try to see the html part of a text/plain + text/html multipart message... /D On Mon, 23 May 2011 14:38:05 -0700, Carl Worth cwo...@cworth.org wrote: Non-text part: multipart/signed ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: problems with multipart/mixed
Pulled the latest. Fixes the reply issue - but frequently gets emacs to dump core. Looking at the backtrace reminds me why I hate emace some times :-) - it appears to happen in a memmove - but everything else in the backtrave is useless Not an improvement. /D On Tue, 24 May 2011 12:50:20 -0700, Carl Worth cwo...@cworth.org wrote: Non-text part: multipart/signed On Mon, 23 May 2011 19:46:41 -0700, Dirk Hohndel hohn...@infradead.org wrote: Hehe, as the reply below shows... there's still something screwy even with the latest git version... in multipart messages things just go wrong. Whether I reply (this below should have included your text/plain part as quote) You caught me again, on two points: 1. Our multipart testing wasn't testing notmuch reply 2. I wasn't actually running the latest code in my own use I've addressed both of those problems, which made it easy to find and fix the segfault that was causing the missing data in the reply buffer. I will hopefully be in a good habit now of creating a Debian package and installing and using it locally as part of my testing of major changes. Meanwhile, I did just push Jameson's recent new-show-part branch (along with some updates from me). This should complete the big upheaval of changes to how multipart messages are handled. From here, Jameson will rebase his crypto branch so we can verify signatures and decrypt messages within emacs. or whether I try to see the html part of a text/plain + text/html multipart message... This is an area where there have been some recent feature changes---and again, sadly, there's still some missing testing of the emacs features. The change I am seeing is that previously whenever a message had both a text/plain part and a corresponding text/html part (withing multipart/alternative), emacs would render both of them. Instead, I'm now seeing the text/plain part followed by: [ text/html (not shown) ] As far as that goes, this hiding of the HTML by default is exactly what I want. (If people don't want this, there's a notmuch-show-all-multipart/alternative-parts variable that can be tweaked. Or just do M-x customize-group notmuch and find the setting there.) Meanwhile, I can imagine that some people might actually need to view the HTML part that's initially not shown. I just tried hitting 'V' on the (not shown) button and I got several image-viewer windows, each showing one of the contained images. That's not ideal---it would be better to get some web browser to display the entire message formatted correctly. Maybe that's just something I need to customize on my end, (though, if so, I think notmuch could do a better job arranging that for the user). So contributions would be welcome in this area, (both functional improvements to the emacs interface as well as additional testing of those emacs features). -Carl -- carl.d.wo...@intel.com Non-text part: application/pgp-signature -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
compile error of current git on F15
CC -O2 notmuch-reply.o notmuch-reply.c: In function ‘notmuch_reply_command’: notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’ notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default] /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’ make: *** [notmuch-reply.o] Error 1 This seems to have been introduced in Jameson's crypto patch series... ./configure shows: Checking for Xapian development files... Yes (1.2.4). Checking for GMime development files... Yes (gmime-2.6). Checking for Glib development files (= 2.14)... Yes. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: compile error of current git on F15
On Tue, 31 May 2011 12:29:28 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Non-text part: multipart/signed i'm CC'ing the upstream lead developer of gmime here to see if he has any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey! On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote: On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel hohn...@infradead.org wrote: CC -O2 notmuch-reply.o notmuch-reply.c: In function ‘notmuch_reply_command’: notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’ notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default] /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’ make: *** [notmuch-reply.o] Error 1 This seems to have been introduced in Jameson's crypto patch series... ./configure shows: Checking for Xapian development files... Yes (1.2.4). Checking for GMime development files... Yes (gmime-2.6). Checking for Glib development files (= 2.14)... Yes. Hey, Dirk. Looks like you're using gmime-2.6, which is something I've never looked at, and it looks like there are API changes. This of course doesn't help you, Dirk, but this probably means we should require libgmime-2.4, at least until we can figure out how to support both versions, which I'm not sure how to handle. Dirk, just out of curiosity, what system are you running that is provides gmime 2.6? F15 probably means Fedora 15. Correct gmime 2.6 has not been released yet; gmime 2.5 is the development version (which itself has an unstable API); the project uses the even=stable/odd=unstable version numbering scheme. As the dev version, gmime 2.5 identifies itself as 2.6. I'm not sure i can justify this decision. Jeffrey, can you explain? If F15 does not have gmime 2.4 available in it, it's possible that it may not be able to build notmuch :/ That's where I am right now. But here's the odd thing: gmime-2.6 support was explicitly added to the configure script last year: http://notmuch.198994.n3.nabble.com/PATCH-configure-Add-support-for-GMime-2-6-td722706.html And it's only a recent change to notmuch that broke the build on F15 (it's one of the patches for the crypto support). So in my book this is a regression for notmuch! I don't think that notmuch should attempt to target a library with an unstable API. But if anyone is interested in preparing for the gmime 2.6 release (maybe jeffrey can hint at the timeline for us) may want to prepare changesets that #ifdef the relevant code depending on the API version. Once gmime 2.6 is released, we'll need to decide if we want to remain compatible with the old API as well, or just require gmime 2.6; but i don't think we need to cross that bridge right now. Given what I wrote above you'll be unsurprised that I don't agree with this interpretation of the situation. This used to work and used to be supported and was broken in a recent notmuch patch. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] emacs mode performance issue
I'm in the search results window in Emacs, on an LKML thread with 140+ messages. I hit return to view this thread - Emacs consumes 100% CPU but even after waiting 3 minutes it doesn't display the result (this is on a fast system Lenovo x200s). C-g stops the process and gets me dumped into a clearly partially processed buffer. Is there a good way to collect more profiling information to figure out why this is so slow? /D -- Dirk Hohndel Intel Open Source Technology Center
[notmuch] reading with multiple MUAs from MailDir
While playing with notmuch I am still using evolution to read the email in the same MailDir that is being indexed / processed by notmuch. With the result that lots of emails can not be found in notmuch if they have been marked as read in evolution between processing in notmuch and trying to access them from the user interface. This makes notmuch /really/ hard to test for me at this point. Is there a workaround? /D -- Dirk Hohndel Intel Open Source Technology Center
[notmuch] reading with multiple MUAs from MailDir
On Fri, 2009-12-11 at 10:44 +0100, Marten Veldthuis wrote: > Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: > > Is there a workaround? > > For now, you can do > > notmuch dump somefile > mv Mail/.notmuch /tmp > notmuch new > notmuch restore somefile > > Which will re-index all your mail, and restore your tags, as far as the > messages are still called the same. Deleted messages will disappear from > the library, and moved messages remain in the inbox. > > Still a pain in the ass, but at least it gets rid of all those errors. With all due respect... Seriously? That doesn't even qualify as a crazy hack... this process takes something like 15 minutes for me. Carl, any idea how when an actual solution to this problem will arrive? /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH 1/2] fix notmuch_message_file_get_header
fix notmuch_message_file_get_header to always return the first instance
of the header you are looking for
Signed-off-by: Dirk Hohndel
---
lib/message-file.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/lib/message-file.c b/lib/message-file.c
index 3a1a681..0c152a3 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -318,9 +318,15 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
match = (strcasecmp (header, header_desired) == 0);
decoded_value = g_mime_utils_header_decode_text (message->value.str);
-
- g_hash_table_insert (message->headers, header, decoded_value);
-
+ if (g_hash_table_lookup (message->headers, header) == NULL) {
+ /* Only insert if we don't have a value for this header, yet.
+* This way we always return the FIRST instance of any header
+* we search for
+* FIXME: we should be returning ALL instances of a header
+*or at least provide a way to iterate over them
+*/
+ g_hash_table_insert (message->headers, header, decoded_value);
+ }
if (match)
return decoded_value;
}
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
[PATCH 2/2] guess From address from Received headers
When replying to a message notmuch tries to pick the correct From
address by looking which one of a user's configured email addresses
were included in To or Cc headers of the email that is being replied to.
If none of the users email addresses are in the To or Cc headers we now
try to guess from the first (chronologically, last) Received header
which domain this email was received in and therefore which of the
email addresses to use in a reply
If that fails we still use the primary email as From email
Signed-off-by: Dirk Hohndel
---
notmuch-reply.c | 73 --
1 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 6c15536..3c5b253 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -282,6 +282,69 @@ add_recipients_from_message (GMimeMessage *reply,
return from_addr;
}
+
+static const char *
+guess_from_received_header(notmuch_config_t *config, notmuch_message_t
*message)
+{
+const char *received,*primary;
+char **other;
+char *by,*mta,*ptr,*token;
+char *domain=NULL;
+char *tld=NULL;
+const char *delim=". \t";
+size_t i,other_len;
+
+received = notmuch_message_get_header (message, "received");
+by = strstr(received," by ");
+if (by && *(by+4)) {
+ /* we know that there are 4 characters after by - either the 4th one
+* is '\0' (broken header) or it is the first letter of the hostname
+* that last received this email - which we'll use to guess the right
+* from email address
+*/
+ mta = strdup(by+4);
+ if (mta == NULL)
+ return NULL;
+ /* After the MTA comes its IP address (or HELO response) in parenthesis.
+* so let's terminate the string there
+*/
+ if ((ptr = strchr(mta,'(')) == NULL) {
+ free (mta);
+ return NULL;
+ }
+ *ptr = '\0';
+ /* Now extract the last two components of the MTA host name
+* as domain and tld
+*/
+ token = mta;
+ while ((ptr = strsep(,delim)) != NULL) {
+ if (*ptr == '\0')
+ continue;
+ domain = tld;
+ tld = ptr;
+ }
+ if (domain) {
+ /* recombine domain and tld and look for it among the configured
+* email addresses
+*/
+ *(tld-1) = '.';
+ primary = notmuch_config_get_user_primary_email (config);
+ if (strcasestr (primary, domain)) {
+ free(mta);
+ return primary;
+ }
+ other = notmuch_config_get_user_other_email (config, _len);
+ for (i = 0; i < other_len; i++)
+ if (strcasestr (other[i], domain)) {
+ free(mta);
+ return other[i];
+ }
+ }
+ free(mta);
+}
+return NULL;
+}
+
static int
notmuch_reply_format_default(void *ctx, notmuch_config_t *config,
notmuch_query_t *query)
{
@@ -312,9 +375,13 @@ notmuch_reply_format_default(void *ctx, notmuch_config_t
*config, notmuch_query_
g_mime_message_set_subject (reply, subject);
from_addr = add_recipients_from_message (reply, config, message);
-
- if (from_addr == NULL)
- from_addr = notmuch_config_get_user_primary_email (config);
+
+ if (from_addr == NULL) {
+ from_addr = guess_from_received_header (config, message);
+ if (from_addr == NULL) {
+ from_addr = notmuch_config_get_user_primary_email (config);
+ }
+ }
from_addr = talloc_asprintf (ctx, "%s <%s>",
notmuch_config_get_user_name (config),
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
[PATCH] fix obvious cut and paste error
the wrong variable is checked for success of an allocation Signed-off-by: Dirk Hohndel --- lib/thread.cc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/thread.cc b/lib/thread.cc index 1c8b39d..48c070e 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -236,7 +236,7 @@ _notmuch_thread_create (void *ctx, return NULL; matched_query = notmuch_query_create (notmuch, matched_query_string); -if (unlikely (thread_id_query == NULL)) +if (unlikely (matched_query == NULL)) return NULL; thread = talloc (ctx, notmuch_thread_t); -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center
[RFC] reordering and cleanup of thread authors
This is based in part on some discussion on IRC today.
When a thread is displayed in the search results, previously the authors
were always displayed in chronological order. But if only part of the
thread matches the query, that may or may not be the intuitive thing to
do.
Imagine the default "+inbox" query. Those mails in the thread that
match the query are actually "new" (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread, the
author column in the search display will first show "Dirk Hohndel" - I
think it should first show the actual author(s) of the new mail(s).
The second cleanup that I've done in this context is to convert all
author names into the much easier to parse "Firstname Lastname"
format. Some broken mail systems (cough - Exchange - Cough) seem to
prefer "Lastname, Firstname" - which makes the comma separated list of
authors really hard to parse at one glance. Worse, it creates douplicate
entries if a person happens to show in both orders. So this does a
rather simplistic "look for a comma, if it's there, reorder" approach to
cleaning up the author name.
I don't think this is ready to be pulled. There was a strong request on
IRC to make the re-ordering of the author names configurable. I think
the cleanup of the names (First Last) should be configurable as well.
And of course I wonder about my implementation, given that I'm still
trying to wrap my mind around the current code base.
Thanks
/D
diff --git a/lib/message.cc b/lib/message.cc
index 721c9a6..ac0afd9 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -35,6 +35,7 @@ struct _notmuch_message {
char *thread_id;
char *in_reply_to;
char *filename;
+char *author;
notmuch_message_file_t *message_file;
notmuch_message_list_t *replies;
unsigned long flags;
@@ -110,6 +111,7 @@ _notmuch_message_create (const void *talloc_owner,
message->in_reply_to = NULL;
message->filename = NULL;
message->message_file = NULL;
+message->author = NULL;
message->replies = _notmuch_message_list_create (message);
if (unlikely (message->replies == NULL)) {
@@ -533,6 +535,20 @@ notmuch_message_get_tags (notmuch_message_t *message)
return _notmuch_convert_tags(message, i, end);
}
+const char *
+notmuch_message_get_author (notmuch_message_t *message)
+{
+return message->author;
+}
+
+void
+notmuch_message_set_author (notmuch_message_t *message,
+ const char *author)
+{
+message->author = talloc_strdup(message, author);
+return;
+}
+
void
_notmuch_message_set_date (notmuch_message_t *message,
const char *date)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 88da078..79638bb 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -771,6 +771,17 @@ notmuch_message_set_flag (notmuch_message_t *message,
time_t
notmuch_message_get_date (notmuch_message_t *message);
+/* Set the author member of 'message' - this is the representation used
+ * when displaying the message
+ */
+void
+notmuch_message_set_author (notmuch_message_t *message, const char *author);
+
+/* Get the author member of 'message'
+ */
+const char *
+notmuch_message_get_author (notmuch_message_t *message);
+
/* Get the value of the specified header from 'message'.
*
* The value will be read from the actual message file, not from the
diff --git a/lib/thread.cc b/lib/thread.cc
index 48c070e..c3c83a3 100644
--- a/lib/thread.cc
+++ b/lib/thread.cc
@@ -32,6 +32,7 @@ struct _notmuch_thread {
char *subject;
GHashTable *authors_hash;
char *authors;
+char *nonmatched_authors;
GHashTable *tags;
notmuch_message_list_t *message_list;
@@ -69,8 +70,95 @@ _thread_add_author (notmuch_thread_t *thread,
thread->authors = talloc_asprintf (thread, "%s, %s",
thread->authors,
author);
-else
+else {
thread->authors = talloc_strdup (thread, author);
+}
+}
+
+/*
+ * move authors of matched messages in the thread to
+ * the front of the authors list, but keep them in
+ * oldest first order within their group
+ */
+static void
+_thread_move_matched_author (notmuch_thread_t *thread,
+const char *author)
+{
+char *authorscopy;
+char *currentauthor;
+int idx,nmstart,author_len,authors_len;
+
+if (thread->authors == NULL)
+ return;
+if (thread->nonmatched_authors == NULL)
+ thread->nonmatched_authors = thread->authors;
+author_len = strlen(author);
+authors_len = strlen(thread->authors);
+if (autho
[notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code
On Wed, 27 Jan 2010 09:44:41 -0500, Jameson Rollins wrote: > Hey, folks. Following up on this thread about better fcc handling, > Jesse passed on a simple python script he wrote that uses the python > "mailbox" module to deliver a message on stdin to a specified maildir > directory. It's very a simple, elegant and general purpose script > (attached). > > I then put the following in my notmuch .emacs to use the new script in > message-mode to fcc sent mail to my ~/.mail/sent directory: > > ;; fcc handler > (defun maildir-deliver-region(destdir) > (shell-command-on-region >(point-min) (point-max) >(concat "maildir-deliver.py -c -s -d " destdir))) > (setq message-fcc-handler-function 'maildir-deliver-region) > (defun my-message-header-setup () > (message-add-header "Fcc: ~/.mail/sent")) > (add-hook 'message-send-hook 'my-message-header-setup) This is really nice - just what I needed. Well, almost. Instead of passing in destdir it would be even better if the lisp code figured out which MailDir to use. So we'd have a configuration variable that matched From addresses to MailDirs "dirk at hohndel.org" "~/MailDirHohndel" "dirk.hohndel at intel.com" "~/MailDirIntel" etc. And just for safety used the passed in destdir as fallback / default. Anyone willing / able to add this? I can't lisp to save my life... /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] Fix code extracting the MTA from Received: headers
The previous code made too many assumptions about the (sadly not
standardized) format of the Received headers. This version should
be more robust to deal with different variations.
Signed-off-by: Dirk Hohndel
---
notmuch-reply.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 8eb4754..39377e1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -296,28 +296,23 @@ guess_from_received_header (notmuch_config_t *config,
notmuch_message_t *message
received = notmuch_message_get_header (message, "received");
by = strstr (received, " by ");
if (by && *(by+4)) {
- /* we know that there are 4 characters after by - either the 4th one
-* is '\0' (broken header) or it is the first letter of the hostname
-* that last received this email - which we'll use to guess the right
-* from email address
+ /* sadly, the format of Received: headers is a bit inconsistent,
+* depending on the MTA used. So we try to extract just the MTA
+* here by removing leading whitespace and assuming that the MTA
+* name ends at the next whitespace
+* we test for *(by+4) to be non-'\0' to make sure there's something
+* there at all - and then assume that the first whitespace delimited
+* token that follows is the last receiving server
*/
mta = strdup (by+4);
if (mta == NULL)
return NULL;
-
- /* After the MTA comes its IP address (or HELO response) in parenthesis.
-* so let's terminate the string there
-*/
- if ((ptr = strchr (mta, '(')) == NULL) {
- free (mta);
+ token = strtok(mta," \t");
+ if (token == NULL)
return NULL;
- }
- *ptr = '\0';
-
/* Now extract the last two components of the MTA host name
* as domain and tld
*/
- token = mta;
while ((ptr = strsep (, delim)) != NULL) {
if (*ptr == '\0')
continue;
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:13:20 +0100, David Edmondson wrote: > On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth wrote: > > * The big batch of emacs-client improvements from David E.'s > > repository. David, do you have particular things to recommend here? > > It's necessary for me to merge with your latest batch of changes. That > won't happen until next week, when I can set aside a few hours. (The > merge is somewhat painful, as I have modified versions of some of the > recently applied patches in my tree.) I hope that this will be a less frequent thing to happen as Carl is quicker in picking up patches. I'm very eager to see the emacs client improvements, though. > I worry about committing the JSON based Emacs UI and then immediately > producing a release - it would be useful to have more people test it > from git HEAD before dropping it on an unsuspecting public. Not sure how much of an "unsuspecting public" we have at this point... but in general this is of course valid. The question is "what are releases". Or what does it mean to "release 0.2". I don't think we have the notion of a stable branch and a development cycle, yet. Everything is development (correct me if I'm wrong, Carl) /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 09:52:21 -0400, Jameson Rollins wrote: > > So keep the patches coming, and the pointers to patches that you want me > > to look at. > > I would really like to see the patch in spaetz/issue15-handle-fcc-bcc > applied soon. This is the lingering issue of bcc'ing the primary email > address in notmuch replies, which I think really needs to be removed. +1 The FCC solution is much more sane. Especially with the From address based path selection that I proposed (but haven't been able to implement for lack of Lisp skills) /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On Thu, 08 Apr 2010 10:03:15 -0400, Jameson Rollins wrote: > On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth wrote: > > For the upcoming 0.2 release, here are some things that I would like to > > have in place: > > > > * Changes to indexing, (addition of body:, folder:, list:, etc.). This > > is stuff that I'll work on. > > Also, fwiw, the folder: indexing is probably the new feature that I'm > most eagerly awaiting. I've got all these ideas for ways to handle sent > mail and drafts if we can get this working. Maybe I am missing some context here - what exactly does 'indexing' mean here? > Presumably others must be annoyed about having to manually "read" and > archive all their sent mail, unless there's some other way that people > having been dealing with this that I'm not aware of. my import/tagging script deals with +sent on emails that I've sent and removes -inbox -unread on them. The FCC logic gets them filed into a Sent folder (right now just one - see previous comment about making this >From address dependent) > And as for drafts, they could be easily indexed and managed by the UI if > the folder: search term is available. Hmm - haven't even thought about drafts, yet. How would the UI deal with those? /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] Fix code extracting the MTA from Received: headers
On Thu, 08 Apr 2010 09:59:14 +0200, "Sebastian Spaeth" wrote: > On 2010-04-07, Dirk Hohndel wrote: > > > > The previous code made too many assumptions about the (sadly not > > standardized) format of the Received headers. This version should > > be more robust to deal with different variations. > > This code might be useful for some, but I know it is not being useful > for me. I use e.g. dreamhost.com as my mail provider and I never have my > email domain name show up after the Received: by . > See my Received headers for your message below. That's the funny thing about heuristics - they are always based on the cases the author has access to. I run my own mail servers and they put in useful Received lines. Dreamhost doesn't appear to do that - I'm sure there are many other scenarios that I don't handle, yet. Please keep them coming. > On the other hand, it contains "for " stating the > intended email address explicitely. IMHO, we should use this before we > start some hand-wavy guessing. > > Also, I have the "X-Original-To: sebastian at sspaeth.de" header. Is that > something that we could make use of before starting to guess? It's complicated. Some MTAs put in bogux "for " or "for UID 1000" into Received headers. I haven't seen any incorrect "X-Original-To" headers, but wouldn't be surprised to see those be faked or wrong, either. Right now my plan is to do something like this: 1) look for my email address in To/Cc 2) look for my email in "for " in Received headers 3) look for my email in X-Original-To 4) look for the domain of my email in Received headers (not just 1st) 5) punt and use default email address Does that sound sane? (and thanks for sending the headers - this really helps... can others for whom the current code or the logic mentioned above wouldn't work send their headers, too, please?) /D -- Dirk Hohndel Intel Open Source Technology Center
RFC: User-Agent header
On Thu, 08 Apr 2010 10:26:01 +0200, "Sebastian Spaeth" wrote: > notmuch is (mostly) not responsible for sending email. However, people > using the emacs frontend use notmuch to create the reply. > > Am I the only one who is sometimes curious as to what mail agents others > use? Would it be useful to insert a header to notmuch reply analog to: > > User-Agent: Mutt/1.5.13 (2006-08-11) > > We could reuse the same version string that we use for the release (or > the git string that was used to build notmuch). I can use this to create > nice stats :). > > No patch yet, just asking if this is a good idea or not. I think it's a very good idea. But it should be something that includes the other components of how you send email... Like User-Aget: Emacs 23 Message-mode / notmuch-0.1.1 /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth" wrote: > On 2010-04-09, Michal Sojka wrote: > > "Decode headers in reply" > > (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another > > patch, which is quite essential to me. Am I the only one here, who needs > > to reply to messages with non-ASCII characters? > > Nope, and it looks currently very ugly. Having a good solution for that > problem would be nice indeed. > > Perhaps Carl should get more N?rw?g?a? friends, :-). Or G?rm?n or ?? Yes, I ran into that myself as my brother's first name is J?rgen and he complained about my emails to him suddenly being mangled... But then, Sebastian doesn't even spell his own last name correctly :-) /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] Have notmuch count default to showing the total.
On Fri, 09 Apr 2010 15:01:35 +0200, "Sebastian Spaeth" wrote: > On 2010-04-08, Mike Kelly wrote: > > If no parameters are given to notmuch-count, or just '' or '*' are > > given, return the total number of messages in the database. > > I know that cworth was concerned about this syntax on IRC as that would > mean that "notmuch show" would have to spew out all your emails in order > to remain consistent with the search term (he rather wanted to output a > help text if no search term was given). > > But let me express support (It's notmuch worth, I know (haha)) for this > patch. I think it makes lots of sense: > > 1) I often want to know how many mails are in my db. "notmuch count" or > "notmuch count *" is the intuitive syntax I would use for that. Right > now there is no way as far as I can see. I use "notmuch count To" - not very intuitive, though. > 2) Search terms filter out things. The empty search term stands > therefore for all my mails. It is consistent to have the search term '' > represent all my mail. Actually, I'd like to disagree. A search argument of '' should get you a help text. A search argument of '*' should give you all email. > 3) I don't expect a help text for "notmuch count" just as I don't expect > a help text for "notmuch log", we are very explicit about "notmuch help" > and "notmuch help count" in many parts of our documentation. My main concern here is that once you have a gazzillion emails, typing notmuch search with no argument over a slow link (or using it from within a gui by mistake) could really cause a lot of unnecessary compute / data transfer. So I'd rather have a special character be the one that triggers that behavior. /D -- Dirk Hohndel Intel Open Source Technology Center
