Wrapping up the 0.3 release
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel wrote: > > * 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. This depends at least somewhat on the setting of `pop-up-windows'. Maybe we should: (let ((pop-up-windows nil)) ...) in the reply code? I think that notmuch window handling generally needs some consideration and improvement. > > Finally, any of the tweaks I suggested to notmuch-hello mode would be > > quite welcome. I might take a whack at some of these. Hopefully early next week for me. dme. -- David Edmondson, http://dme.org
Failing test cases
On Sun, 25 Apr 2010 10:17:44 +1000, Jason White wrote: > I just tried to build the Debian package from the latest Git master branch, > but this could not be completed due to failures of test cases 067, 068 and > 069. > > Are others seeing this, or is it a peculiarity of my system (Debian Sid, > x86-64)? No, this is the expected behavior right now. Carl has the habit of committing the tests before he commits the code that addresses the issue / feature that is tested for. And it turned out that there was a bug in the original version of that code. I have submitted a fixed version but that hasn't been pushed, yet. 0.3 with all the latest and greatest fixes and cleanups should be out, shortly. /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH 7/7] Integrate notmuch-fcc mechansim
On Fri, 23 Apr 2010 11:38:57 +0200, Sebastian Spaeth 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 " . "Work/sentbox") > ("full name2 " . "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
Wrapping up the 0.3 release
On Sat, 24 Apr 2010 15:05:55 -0700, Dirk Hohndel 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
Wrapping up the 0.3 release
On Sat, 24 Apr 2010 14:45:45 -0700, Carl Worth 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
Wrapping up the 0.3 release
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel wrote: > On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth wrote: > > 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? No, what you sent last night is perfect. That will be easier for me. > 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. 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. > 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. 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. Thanks, -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/19746ec2/attachment.pgp>
[notmuch] auto-tagging replied messages
-- carl.d.worth at intel.com On Sat, 24 Apr 2010 09:56:04 -0400, Jesse Rosenthal wrote: > I'd love to put this into shape to become part of notmuch proper. Great! > My question, for this and other things I've worked on, is where code > that targets message-mode should go. In notmuch-mua.el? Or a new > notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I > know where it would make the most sense to group these, I'll submit a > patch. You can call it notmuch-message.el if you'd like. I'm never a fan of something generic like -utils. Things like that seem to grow without bounds. > But just to clarify: you don't mind if removal is a customizable user > option, right? I don't mind at all. I was just happy to realize that we wouldn't have to do any tag removal to make the feature useful out-of-the-box. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/90699649/attachment.pgp>
[PATCH] Add NEWS updates for my last batch of patches
On Fri, 23 Apr 2010 10:42:31 -0700, Dirk Hohndel wrote: > +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 Strange sentence: "The script to be called can be customized with." I'd suggest an improvement, but I'm not sure what it should read. micah -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/d8151fd3/attachment.pgp>
improve from-header guessing
On Fri, 23 Apr 2010 11:47:04 -0700, Carl Worth wrote: > On Fri, 16 Apr 2010 13:51:40 -0700, Dirk Hohndel > 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
[PATCH 5/5] Simple attempt to display author names in a friendlier way
This patch only addresses the typical Outlook/Exchange case where we have "Last, First" or "Last, First MI" . In the future we should be more fexible as to the formats we recognize, but for now we address this one as it is the Exchange default setting and therefore the most common one. Signed-off-by: Dirk Hohndel --- lib/thread.cc | 51 +-- 1 files changed, 49 insertions(+), 2 deletions(-) diff --git a/lib/thread.cc b/lib/thread.cc index c80bb26..b8be3e1 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -147,6 +147,51 @@ _thread_move_matched_author (notmuch_thread_t *thread, return; } +/* 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" + * "Last, First MI" + */ +char * +_thread_cleanup_author (notmuch_thread_t *thread, + const char *author, const char *from) +{ +char *clean_author,*test_author; +const char *comma; +char *blank; +int fname,lname; + +clean_author = talloc_strdup(thread, author); +if (clean_author == NULL) + return NULL; +comma = strchr(author,','); +if (comma) { + /* let's assemble what we think is the correct name */ + lname = comma - author; + fname = strlen(author) - lname - 2; + strncpy(clean_author, comma + 2, fname); + *(clean_author+fname) = ' '; + strncpy(clean_author + fname + 1, author, lname); + *(clean_author+fname+1+lname) = '\0'; + /* make a temporary copy and see if it matches the email */ + test_author = talloc_strdup(thread,clean_author); + + blank=strchr(test_author,' '); + while (blank != NULL) { + *blank = '.'; + blank=strchr(test_author,' '); + } + if (strcasestr(from, test_author) == NULL) + /* 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; +} + /* Add 'message' as a message that belongs to 'thread'. * * The 'thread' will talloc_steal the 'message' and hold onto a @@ -161,6 +206,7 @@ _thread_add_message (notmuch_thread_t *thread, InternetAddressList *list = NULL; InternetAddress *address; const char *from, *author; +char *clean_author; _notmuch_message_list_add_message (thread->message_list, talloc_steal (thread, message)); @@ -183,8 +229,9 @@ _thread_add_message (notmuch_thread_t *thread, mailbox = INTERNET_ADDRESS_MAILBOX (address); author = internet_address_mailbox_get_addr (mailbox); } - _thread_add_author (thread, author); - notmuch_message_set_author (message, author); + clean_author = _thread_cleanup_author (thread, author, from); + _thread_add_author (thread, clean_author); + notmuch_message_set_author (message, clean_author); } g_object_unref (G_OBJECT (list)); } -- 1.6.6.1
[PATCH 4/5] Add tests for author name reordering in search results
This should be required for all patches :-) Signed-off-by: Dirk Hohndel --- test/notmuch-test | 28 +++- 1 files changed, 27 insertions(+), 1 deletions(-) diff --git a/test/notmuch-test b/test/notmuch-test index 7082344..f455232 100755 --- a/test/notmuch-test +++ b/test/notmuch-test @@ -867,6 +867,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 "' '[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]=\' [subject]=author-reorder-threadtest '[from]="User1 "' '[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]=\ ' [subject]=author-reorder-threadtest '[from]="User2 "' '[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)" + +printf "\nTesting From line heuristics;\n" printf " Magic from guessing (nothing to go on)...\t" add_message '[from]="Sender "' \ [to]=mailinglist at notmuchmail.org \ @@ -965,7 +992,6 @@ References: <${gen_msg_id}> On Tue, 05 Jan 2010 15:43:56 -0800, Sender wrote: > from guessing test" - echo "" echo "Notmuch test suite complete." -- 1.6.6.1
[PATCH 3/5] Add NEWS section for author reordering
This should be required in all patches Signed-off-by: Dirk Hohndel --- 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
[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 --- 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 --- 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
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
[PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.
On Thu, 31 Dec 2009 13:39:29 -0400, david at tethera.net wrote: > > The idea here is to be able to generate the online help and the man page from > one source. > > To generate a man page: > >pod2man notmuch.pod > notmuch.1 > > To generate help for a specific notmuch subcommand > >podselect -section 'Commands/subcommand.*' notmuch.pod | pod2text -c > As I'm faced with writing docs for output selection, I'd like to revisit this idea. I didn't get any feedback, positive or negative about the idea of keeping the docs in pod. I don't care much about the format, but I think it would be nice to avoid maintaining two copies of the documentation. Should I rebase/rebuild this against the current docs, or not bother? d
[PATCH] Reordering of thread authors to list matching authors first
On Fri, 23 Apr 2010 17:21:53 -0700, Carl Worth wrote: > On Wed, 21 Apr 2010 20:58:27 -0700, Dirk Hohndel > 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
[PATCH] emacs: Fix i-search to open up invisible citations as necessary
On Sat, 24 Apr 2010 07:42:48 -0700, Carl Worth wrote: > On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson 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
[PATCH] Clean up author display for some "Last, First" cases
On Sat, 24 Apr 2010 08:30:22 -0700, Carl Worth wrote: > On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel > 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" > > + * "Last, First MI" > > 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_worth at 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 "cworth at 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] auto-tagging replied messages
On Sat, 24 Apr 2010 05:38:36 -0700, Carl Worth wrote: > So here's my vote for someone cleaning this up into a patch that could > be applied directly to notmuch rather than just being a snippet of code > to shove into .emacs. I'd love to put this into shape to become part of notmuch proper. My question, for this and other things I've worked on, is where code that targets message-mode should go. In notmuch-mua.el? Or a new notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I know where it would make the most sense to group these, I'll submit a patch. > Supporting the removal of a tag as well is clever, but I wouldn't > suggest doing that by default (the patch doesn't anyway). And instead, > people could do things like searches for "tag:reply-required and not > tag:replied". But just to clarify: you don't mind if removal is a customizable user option, right? Best, Jesse
Wrapping up the 0.3 release
On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth 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
[PATCH] removed unused variables
On Fri, 23 Apr 2010 17:55:09 -0700, Carl Worth wrote: > On Thu, 22 Apr 2010 20:26:46 -0700, Dirk Hohndel > 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
[PATCH 3/3] notmuch-show.c: control which headers are show for json output.
From: David BremnerThis commit adds argument handling from and callbacks to notmuch-output.c to determine what headers to show in json output. This requires passing a pointer to a struct containing the output parameters into several functions, and in particular changes the type of the function pointers in the show_format structure. --- notmuch-show.c | 81 ++-- 1 files changed, 55 insertions(+), 26 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index 6aa9072..29e2819 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -19,6 +19,7 @@ */ #include "notmuch-client.h" +#include "notmuch-output.h" typedef struct show_format { const char *message_set_start; @@ -28,6 +29,7 @@ typedef struct show_format { int indent); const char *header_start; void (*header) (const void *ctx, + notmuch_output_options_t *output_opts, notmuch_message_t *message); const char *header_end; const char *body_start; @@ -45,6 +47,7 @@ format_message_text (unused (const void *ctx), int indent); static void format_headers_text (const void *ctx, +notmuch_output_options_t *opts, notmuch_message_t *message); static void format_part_text (GMimeObject *part, @@ -64,6 +67,7 @@ format_message_json (const void *ctx, unused (int indent)); static void format_headers_json (const void *ctx, +unused (notmuch_output_options_t *opts), notmuch_message_t *message); static void format_part_json (GMimeObject *part, @@ -164,7 +168,9 @@ format_message_json (const void *ctx, notmuch_message_t *message, unused (int in } static void -format_headers_text (const void *ctx, notmuch_message_t *message) +format_headers_text (const void *ctx, +unused (notmuch_output_options_t *opts), +notmuch_message_t *message) { const char *headers[] = { "Subject", "From", "To", "Cc", "Bcc", "Date" @@ -183,28 +189,38 @@ format_headers_text (const void *ctx, notmuch_message_t *message) } static void -format_headers_json (const void *ctx, notmuch_message_t *message) +format_headers_json (const void *ctx, +notmuch_output_options_t *output_opts, +notmuch_message_t *message) { -const char *headers[] = { - "Subject", "From", "To", "Cc", "Bcc", "Date" +const struct { const char *name; notmuch_output_t key; } headers[] = { + { "Subject", NOTMUCH_OUTPUT_SUBJECT}, + { "From", NOTMUCH_OUTPUT_FROM}, + { "To", NOTMUCH_OUTPUT_TO}, + { "Cc", NOTMUCH_OUTPUT_TO}, + { "Bcc", NOTMUCH_OUTPUT_BCC }, + { "Date", NOTMUCH_OUTPUT_DATE} }; + const char *name, *value; unsigned int i; int first_header = 1; void *ctx_quote = talloc_new (ctx); for (i = 0; i < ARRAY_SIZE (headers); i++) { - name = headers[i]; - value = notmuch_message_get_header (message, name); - if (value) - { - if (!first_header) - fputs (", ", stdout); - first_header = 0; - - printf ("%s: %s", - json_quote_str (ctx_quote, name), - json_quote_str (ctx_quote, value)); + if (output_get_flag(output_opts,headers[i].key)) { + name = headers[i].name; + value = notmuch_message_get_header (message, name); + if (value) + { + if (!first_header) + fputs (", ", stdout); + first_header = 0; + + printf ("%s: %s", + json_quote_str (ctx_quote, name), + json_quote_str (ctx_quote, value)); + } } } @@ -337,7 +353,9 @@ format_part_json (GMimeObject *part, int *part_count) } static void -show_message (void *ctx, const show_format_t *format, notmuch_message_t *message, int indent) +show_message (void *ctx, const show_format_t *format, + notmuch_output_options_t *output_options, + notmuch_message_t *message, int indent) { fputs (format->message_start, stdout); if (format->message) @@ -345,20 +363,24 @@ show_message (void *ctx, const show_format_t *format, notmuch_message_t *message fputs (format->header_start, stdout); if (format->header) - format->header(ctx, message); + format->header(ctx, output_options, message); fputs (format->header_end, stdout); -fputs (format->body_start, stdout); -if (format->part) - show_message_body (notmuch_message_get_filename (message), format->part); -fputs (format->body_end, stdout); +if (output_get_flag(output_options, NOTMUCH_OUTPUT_BODY)){ + fputs (format->body_start, stdout); + if (format->part) + show_message_body (notmuch_message_get_filename (message),
[PATCH 2/3] notmuch-output.[ch]: initial implementation of output selection argument handling.
From: David BremnerThese two files provide a more or less "object oriented" approach to parsing output selection arguments. The use of a struct to track which output pieces are selected is intended to hide the implementation, which currently uses bitmasks. --- Makefile.local |1 + notmuch-output.c | 95 ++ notmuch-output.h | 49 3 files changed, 145 insertions(+), 0 deletions(-) create mode 100644 notmuch-output.c create mode 100644 notmuch-output.h diff --git a/Makefile.local b/Makefile.local index 5bb570b..eb78679 100644 --- a/Makefile.local +++ b/Makefile.local @@ -240,6 +240,7 @@ notmuch_client_srcs = \ notmuch-count.c \ notmuch-dump.c \ notmuch-new.c \ + notmuch-output.c\ notmuch-reply.c \ notmuch-restore.c \ notmuch-search.c\ diff --git a/notmuch-output.c b/notmuch-output.c new file mode 100644 index 000..a84bbe1 --- /dev/null +++ b/notmuch-output.c @@ -0,0 +1,95 @@ +/* notmuch-output.h --- encapsulate handling of output selection. + * + * Copyright 2010 ?? David Bremner + * + * This file is part of Notmuch. + * + * Notmuch is free software: you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation, either version 3 of the License, or (at + * your option) any later version. + * + * Notmuch 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 Notmuch. If not, see . + * + * Authors: David Bremner + */ + +#include "notmuch-client.h" +#include "notmuch-output.h" + +notmuch_output_options_t * +output_init(void *ctx){ +notmuch_output_options_t *output_opts; + +output_opts = talloc (ctx, notmuch_output_options_t); +output_opts->output_all=TRUE; +output_opts->mask=0; +return output_opts; +} + +int +output_parse_arg(notmuch_output_options_t *output_opts, const char *arg){ + +char *opt; + +struct { const char *name; notmuch_output_t key; } parse_try[]={ + {"bcc", NOTMUCH_OUTPUT_BCC}, + {"body", NOTMUCH_OUTPUT_BODY}, + {"cc", NOTMUCH_OUTPUT_CC}, + {"date",NOTMUCH_OUTPUT_DATE}, + {"from",NOTMUCH_OUTPUT_FROM}, + {"message-id",NOTMUCH_OUTPUT_MESSAGE_ID}, + {"subject",NOTMUCH_OUTPUT_SUBJECT}, + {"to", NOTMUCH_OUTPUT_TO}, +}; + +opt = strchr(arg, '='); +if (!opt) + return 1; + +opt++; + +output_opts->output_all=FALSE; + +while(opt) { + unsigned int i; + notmuch_bool_t found = FALSE; + notmuch_output_t key = 0; + + for (i = 0; i mask |= (1< output_all) + return 1; + +return (opts->mask & (1<
[PATCH 1/3] remove stale "unused" from around argv and argc in notmuch_show_command.
From: David BremnerIn fact argc and argv are used in this function. --- notmuch-show.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index 26449fa..6aa9072 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -403,7 +403,7 @@ show_messages (void *ctx, const show_format_t *format, notmuch_messages_t *messa } int -notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) +notmuch_show_command (void *ctx, int argc, char *argv[]) { notmuch_config_t *config; notmuch_database_t *notmuch; -- 1.7.0
Initial support for selecting what is output
These are some preliminary patches to add a --output argument to notmuch show. notmuch show --format=json --output=from,subject ${query} or notmuch show --format=json --output=to,body ${query} I'd like to implement a bit finer control (to get message-id's only is not possible right now), and it needs documentation and a test, but I thought I'd toss this out there to see what people think.
Wrapping up the 0.3 release
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 * 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! 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? * Composing a new message with 'm' brings up headers in a scrambled order. A minor point, but it would be nice to fix this. 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. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/a861fa0a/attachment.pgp>
[PATCH] Clean up author display for some "Last, First" cases
On Wed, 21 Apr 2010 22:04:39 -0700, Dirk Hohndel 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" > + * "Last, First MI" 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_worth at example.com?) > +char *cleanauthor,*testauthor; I'd much rather see an underscore separating two words in a single identifier, (so clean_author, test_author). > + /* 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." */ 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? > + /* 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. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/3d341245/attachment-0001.pgp>
[PATCH] emacs: Add more functions to clean up text/plain parts
On Thu, 22 Apr 2010 13:26:06 +0100, David Edmondson wrote: > This is a small variant on the previous version of the patch. The > wrapping of long lines is not enabled by default - it's simply an > option in the customise interface. This is really close now. I especially like that the various wash options are as simple as just checkboxes in the customize interface. (That might not even be new in this case, but I at least didn't find it before.) And that again goes to my point. I don't think we should enable this washing by default since it can appear as silent corruption to the user, without any indication that it happened nor how to turn it off. Notmuch has always done some modification of the message with things like hiding long citations, etc. But those at least provide self-documenting buttons on how to make them disappear. Here's what I see in the customize buffer with the latest patch, along with some review. Some of this review applies to documentation already in notmuch---I'm just getting pickier as things appear in customize because I think we need to hold our documentation there to a higher standard. (Previously, one would practically have to dive into the source to find the documentation, and that suggests the reader has more experience and definitely means the user gsts a lot more context). Here, I'm trying to review these options from the point of view of a new user who just started using notmuch, wants to tweak a few things, and is looking at the customize buffer to figure out what tweaks are possible. Notmuch Show Hook: [X] notmuch-show-pretty-hook [ ] notmuch-show-turn-off-word-wrap INS State: STANDARD. A list of functions called after populating a More What does "pretty hook" mean? What information would a user need to determine whether to turn this on or off? With "turn off word wrap", we have on option to disable wrapping here, and another option later to turn some wrapping on again. How is a user expected to figure out which combination of options does what they want? Notmuch Show Insert Text/Plain Hook: Hide Value [ ] notmuch-wash-wrap-long-lines Wrap text in the region whilst maintaining the correct prefix. [X] notmuch-wash-tidy-citations Clean up citations. [X] notmuch-wash-compress-blanks Compress successive blank lines into one blank line. Remove More [X] notmuch-wash-markup-citations Markup citations, and up to one signature in the buffer. "Tidy", "Clean up", and "Markup" citations are all too vague. What do each of these actually do? Also, think about line breaks so that something like "Remove more" doesn't appear there by default. Thanks, -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/4209ef48/attachment.pgp>
[PATCH] emacs: Fix i-search to open up invisible citations as necessary
On Fri, 23 Apr 2010 18:39:33 +0100, David Edmondson 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? -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/660c87f3/attachment.pgp>
Unhandled Xapian exception
On Fri, 23 Apr 2010 13:21:56 +0200, "Sebastian Spaeth" wrote: > I propose to try..catch this code block and rather than returning VOID > it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION. > Not sure how "notmuch_database_find_message" would notify the caller of > such an exception situation though. The only possible failure value is > NULL (which also means did not find such a message). We haven't been doing fine-grained exception handling in the library so far. Mostly because the assumption was that there was nothing we could do---when I first wrote the code I assumed that Xapian exceptions would be entirely exceptional. So I just fixed the top-level entry point here to handle this exception in our standard way, (print the message, then return NULL or NOTMUCH_STATUS_XAPIAN_EXCEPTION). While at this, I audited all notmuch_database calls to ensure they follow this scheme. (I have not yet audited all libnotmuch entry points.) Meanwhile, we've recently discovered that there is a Xapian exception that is not all that exceptional. Since database readers don't lock the database, it's not hard to have one or more readers accessing the database when a writer comes along and modifies the database. This triggers the readers to subsequently fail with a DatabaseModified exception. I don't know how conceivable it would be to fix that at the Xapian level. It might be quite nice if opening a database in read-only mode gave access to a snapshot of the database as it exists at that time. But that might be a feature that's entirely unreasonable to implement. Otherwise, we might want to start supporting more clever handling of the exception. For example, the high-level application might want to retry an operation if it fails due to a DatabaseModified exception. To support this, you would want your python bindings to have a layer that would catch the C++ exception and re-throw a python exception. And to support that, we would need a different scheme in the library. Basically to just document that all calls might throw an exception and then not catch and print anything. That would at least be much simpler in the library. Then the top-level "notmuch" application could just have a C++ wrapper for main() that would catch and print the exception message. What do you think? -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/cdaf2ca8/attachment.pgp>
notmuch segfault
On Fri, 23 Apr 2010 15:26:51 +0200, "Sebastian Spaeth" wrote: > It happened again. Both times I had pressed "G" which calls offlineimap > and which removed messages that the notmuch database still thought are there. Thanks for the report, Sebastian. I've just audited all calls to notmuch_message_get_header and tried to handle NULL in all cases. Of course, I haven't tested this thoroughly, but we'll hope that things are better at least. And perhaps someday someone will hook up some exhaustive fault-injection-based testing to catch things like this. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/01d989a9/attachment.pgp>
[PATCH] emacs: Re-arrange message sending code
On Fri, 23 Apr 2010 13:25:22 -0700, Carl Worth wrote: > And I'm hoping that this new support makes it easier for people to hook > in the Fcc code. Does this mean there's now a single place to add that > that will make it work for messages composed from 'm', 'f', or 'r'? Yes. > The one unpleasantry I've noticed is that in the case of 'm' the headers > are being put into the buffer in the following order: > > User-Agent: > To: > Subject: > From: > > where I would prefer them in the following order: > > From: > To: > Subject: > User-Agent: I have: (setq message-hidden-headers '("^References:" "^Face:" "^X-Face:" "^X-Draft-From:" "^User-Agent:")) so the User-Agent is not even visible. dme. -- David Edmondson, http://dme.org
[PATCH] emacs: Allow headers to be shown by default in show mode
On Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth wrote: > I think I'll accept the patch, change the default, then remove From from > the list of headers inserted. I've done this now. I've also exported the list of headers to display as another nice customizable option in "M-x customize-group" "notmuch". For myself, I removed "Date" from that list too. That gives me a very compact display without hiding too much information. I didn't do that by default because several people recently said they'd prefer to see the actual date rather than the relative date that's in the summary line. I suppose another possibility would be to remove the Date header by default and provide an option to display the actual date in the summary-line instead of the relative date. Someone that wants that could do that to get one more line of message content per message displayed. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/dbe20364/attachment.pgp>
[PATCH] emacs: Allow headers to be shown by default in show mode
On Fri, 23 Apr 2010 21:08:48 +0100, David Edmondson 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? I think that I would personally like to have the To and Cc headers visible always. But having From and Date visible as separate rows is redundant with our current summary bar, (well, Date isn't precisely redundant). I think I'll accept the patch, change the default, then remove From from the list of headers inserted. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/6e42e031/attachment.pgp>
[notmuch] auto-tagging replied messages
On Thu, 22 Apr 2010 12:35:16 +0200, "Sebastian Spaeth" wrote: > On 2010-03-05, Jesse Rosenthal wrote: > > One element of traditional clients that I've missed in notmuch is the > > ability to easily see which messages have been replied to. A look at the > > thread structure will often make that clear, but for both searching and > > syncing, an "answered" tag would be nice. > > This patch has been working great so far and is very useful. Can I > persuade someone to take this into the notmuch code and have a defcustom > as to which tag a reply should get (or disable if nil)? I'd like to see the in as well. Since we name the action of responding to a message "reply" in the documentation already, my vote for a default tag to add would be "replied". Supporting the removal of a tag as well is clever, but I wouldn't suggest doing that by default (the patch doesn't anyway). And instead, people could do things like searches for "tag:reply-required and not tag:replied". So here's my vote for someone cleaning this up into a patch that could be applied directly to notmuch rather than just being a snippet of code to shove into .emacs. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100424/a31113da/attachment-0001.pgp>
Ideas for making notmuch-hello easier to navigate
On Fri, 23 Apr 2010 13:13:01 -0700, Carl Worth wrote: > That's the feedback I have from a very quick, first look. I'm sure I'll > have more later. In order to give notmuch-hello some good testing, I switched over to using it exclusively instead of notmuch-folder. The biggest frustration I'm having is easily picking the desired saved search with only the keyboard, (I tend to be the kind of person that prefers the keyboard over any mouse/trackpad/pointer-stick-thingy).
Re: [PATCH] emacs: Re-arrange message sending code
On Fri, 23 Apr 2010 13:25:22 -0700, Carl Worth cwo...@cworth.org wrote: And I'm hoping that this new support makes it easier for people to hook in the Fcc code. Does this mean there's now a single place to add that that will make it work for messages composed from 'm', 'f', or 'r'? Yes. The one unpleasantry I've noticed is that in the case of 'm' the headers are being put into the buffer in the following order: User-Agent: To: Subject: From: where I would prefer them in the following order: From: To: Subject: User-Agent: I have: (setq message-hidden-headers '(^References: ^Face: ^X-Face: ^X-Draft-From: ^User-Agent:)) so the User-Agent is not even visible. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] remove stale unused from around argv and argc in notmuch_show_command.
From: David Bremner brem...@unb.ca In fact argc and argv are used in this function. --- notmuch-show.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index 26449fa..6aa9072 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -403,7 +403,7 @@ show_messages (void *ctx, const show_format_t *format, notmuch_messages_t *messa } int -notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) +notmuch_show_command (void *ctx, int argc, char *argv[]) { notmuch_config_t *config; notmuch_database_t *notmuch; -- 1.7.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3] notmuch-output.[ch]: initial implementation of output selection argument handling.
From: David Bremner brem...@unb.ca These two files provide a more or less object oriented approach to parsing output selection arguments. The use of a struct to track which output pieces are selected is intended to hide the implementation, which currently uses bitmasks. --- Makefile.local |1 + notmuch-output.c | 95 ++ notmuch-output.h | 49 3 files changed, 145 insertions(+), 0 deletions(-) create mode 100644 notmuch-output.c create mode 100644 notmuch-output.h diff --git a/Makefile.local b/Makefile.local index 5bb570b..eb78679 100644 --- a/Makefile.local +++ b/Makefile.local @@ -240,6 +240,7 @@ notmuch_client_srcs = \ notmuch-count.c \ notmuch-dump.c \ notmuch-new.c \ + notmuch-output.c\ notmuch-reply.c \ notmuch-restore.c \ notmuch-search.c\ diff --git a/notmuch-output.c b/notmuch-output.c new file mode 100644 index 000..a84bbe1 --- /dev/null +++ b/notmuch-output.c @@ -0,0 +1,95 @@ +/* notmuch-output.h --- encapsulate handling of output selection. + * + * Copyright 2010 © David Bremner + * + * This file is part of Notmuch. + * + * Notmuch is free software: you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation, either version 3 of the License, or (at + * your option) any later version. + * + * Notmuch 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 Notmuch. If not, see http:www.gnu.org/licenses/. + * + * Authors: David Bremner da...@tethera.net + */ + +#include notmuch-client.h +#include notmuch-output.h + +notmuch_output_options_t * +output_init(void *ctx){ +notmuch_output_options_t *output_opts; + +output_opts = talloc (ctx, notmuch_output_options_t); +output_opts-output_all=TRUE; +output_opts-mask=0; +return output_opts; +} + +int +output_parse_arg(notmuch_output_options_t *output_opts, const char *arg){ + +char *opt; + +struct { const char *name; notmuch_output_t key; } parse_try[]={ + {bcc, NOTMUCH_OUTPUT_BCC}, + {body, NOTMUCH_OUTPUT_BODY}, + {cc, NOTMUCH_OUTPUT_CC}, + {date,NOTMUCH_OUTPUT_DATE}, + {from,NOTMUCH_OUTPUT_FROM}, + {message-id,NOTMUCH_OUTPUT_MESSAGE_ID}, + {subject,NOTMUCH_OUTPUT_SUBJECT}, + {to, NOTMUCH_OUTPUT_TO}, +}; + +opt = strchr(arg, '='); +if (!opt) + return 1; + +opt++; + +output_opts-output_all=FALSE; + +while(opt) { + unsigned int i; + notmuch_bool_t found = FALSE; + notmuch_output_t key = 0; + + for (i = 0; iARRAY_SIZE(parse_try) ; i++){ + if (strncmp(opt, parse_try[i].name, + strlen(parse_try[i].name)) == 0){ + key = parse_try[i].key; + found = TRUE; + } + } + + if (!found) { + fprintf (stderr, Unrecognized output selection: %s\n, opt); + return 1; + } + + output_opts-mask |= (1key); + + opt = strchr(opt, ','); + if (opt) opt++; +} + +return 0; +} + +notmuch_bool_t +output_get_flag(notmuch_output_options_t *opts, + notmuch_output_t flag){ + +if (opts-output_all) + return 1; + +return (opts-mask (1flag)); +} diff --git a/notmuch-output.h b/notmuch-output.h new file mode 100644 index 000..1216499 --- /dev/null +++ b/notmuch-output.h @@ -0,0 +1,49 @@ +/* notmuch-output.h --- encapsulate handling of output selection. + * + * Copyright 2010 © David Bremner + * + * This file is part of Notmuch. + * + * Notmuch is free software: you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation, either version 3 of the License, or (at + * your option) any later version. + * + * Notmuch 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 Notmuch. If not, see http:www.gnu.org/licenses/. + * + * Authors: David Bremner da...@tethera.net + */ + +#ifndef NOTMUCH_OUTPUT_H +#define NOTMUCH_OUTPUT_H + +typedef struct notmuch_output_struct { +notmuch_bool_t output_all; +int mask; +} notmuch_output_options_t; + +typedef enum notmuch_output_enum { +NOTMUCH_OUTPUT_BCC, +NOTMUCH_OUTPUT_BODY, +NOTMUCH_OUTPUT_CC, +NOTMUCH_OUTPUT_DATE, +NOTMUCH_OUTPUT_FROM, +
Ideas for making notmuch-hello easier to navigate
On Fri, 23 Apr 2010 13:13:01 -0700, Carl Worth cwo...@cworth.org wrote: That's the feedback I have from a very quick, first look. I'm sure I'll have more later. In order to give notmuch-hello some good testing, I switched over to using it exclusively instead of notmuch-folder. The biggest frustration I'm having is easily picking the desired saved search with only the keyboard, (I tend to be the kind of person that prefers the keyboard over any mouse/trackpad/pointer-stick-thingy). From the initial screen, (with point at the upper-left corner), it takes several keypresses of TAB before I get to the first saved search. It might be even more natural to just use C-n to get to the line of interest, but then I end up in the first column where the saved search isn't active for RET. Here are a few different ideas to simplify things: * Provide a target column from the beginning so that C-n moves point to an active location. * Consider a single-column layout for saved searches so that C-n is sufficient for selecting one. * Consider moving the name of the saved search to before the count so that the initial column is active. Otherwise considering making a larger active target, (name and count, maybe more). With a single-column layout the whole row could be active. * Consider moving saved searches to above the big search bar. This way the become the primary thing to access, which is what I want at least. Then recent searches could stay just below the search bar, which also makes sense. And for a new user, the big search bar would be at the top which gives a good introduction to the system. * Provide keypbindings for next (and previous) saved search which would move point to the next or previous saved-search name in the buffer. * Provide a keypress for easily typing a name of a saved search. I think I'd like this to work like i-search, but would only match saved-search names, and a single press of RET would both terminate the isearch and activate the saved search. Any/all of those would help for selecting a single group. Then the other feature that I would find essential, (and that notmuch-folder had): * Make it so that when quitting from a search and returning to notmuch-hello, that point is at the same position it was before, (so that q followed by RET returns the the same search view). This would make it so that selecting the next search of interest would be much easier than now. Just throwing those ideas out in case anyone wants to try implementing some and experimenting. I'm busy enough merging code now that I don't have time to write any of the above yet, but I hope to have time to start coding again soon. -Carl pgplnzjhrHEUm.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] auto-tagging replied messages
On Thu, 22 Apr 2010 12:35:16 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-03-05, Jesse Rosenthal wrote: One element of traditional clients that I've missed in notmuch is the ability to easily see which messages have been replied to. A look at the thread structure will often make that clear, but for both searching and syncing, an answered tag would be nice. This patch has been working great so far and is very useful. Can I persuade someone to take this into the notmuch code and have a defcustom as to which tag a reply should get (or disable if nil)? I'd like to see the in as well. Since we name the action of responding to a message reply in the documentation already, my vote for a default tag to add would be replied. Supporting the removal of a tag as well is clever, but I wouldn't suggest doing that by default (the patch doesn't anyway). And instead, people could do things like searches for tag:reply-required and not tag:replied. So here's my vote for someone cleaning this up into a patch that could be applied directly to notmuch rather than just being a snippet of code to shove into .emacs. -Carl pgp3DDQZf0XXT.pgp Description: PGP signature ___ 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 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? I think that I would personally like to have the To and Cc headers visible always. But having From and Date visible as separate rows is redundant with our current summary bar, (well, Date isn't precisely redundant). I think I'll accept the patch, change the default, then remove From from the list of headers inserted. -Carl pgpjPZaOr5ja2.pgp Description: PGP signature ___ 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 Sat, 24 Apr 2010 05:42:54 -0700, Carl Worth cwo...@cworth.org wrote: I think I'll accept the patch, change the default, then remove From from the list of headers inserted. I've done this now. I've also exported the list of headers to display as another nice customizable option in M-x customize-group notmuch. For myself, I removed Date from that list too. That gives me a very compact display without hiding too much information. I didn't do that by default because several people recently said they'd prefer to see the actual date rather than the relative date that's in the summary line. I suppose another possibility would be to remove the Date header by default and provide an option to display the actual date in the summary-line instead of the relative date. Someone that wants that could do that to get one more line of message content per message displayed. -Carl pgpK7KCiKWPf0.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch segfault
On Fri, 23 Apr 2010 15:26:51 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: It happened again. Both times I had pressed G which calls offlineimap and which removed messages that the notmuch database still thought are there. Thanks for the report, Sebastian. I've just audited all calls to notmuch_message_get_header and tried to handle NULL in all cases. Of course, I haven't tested this thoroughly, but we'll hope that things are better at least. And perhaps someday someone will hook up some exhaustive fault-injection-based testing to catch things like this. -Carl pgpKlA9oPp9JV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] auto-tagging replied messages
On Sat, 24 Apr 2010 05:38:36 -0700, Carl Worth cwo...@cworth.org wrote: So here's my vote for someone cleaning this up into a patch that could be applied directly to notmuch rather than just being a snippet of code to shove into .emacs. I'd love to put this into shape to become part of notmuch proper. My question, for this and other things I've worked on, is where code that targets message-mode should go. In notmuch-mua.el? Or a new notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I know where it would make the most sense to group these, I'll submit a patch. Supporting the removal of a tag as well is clever, but I wouldn't suggest doing that by default (the patch doesn't anyway). And instead, people could do things like searches for tag:reply-required and not tag:replied. But just to clarify: you don't mind if removal is a customizable user option, right? Best, Jesse ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.
On Thu, 31 Dec 2009 13:39:29 -0400, da...@tethera.net wrote: The idea here is to be able to generate the online help and the man page from one source. To generate a man page: pod2man notmuch.pod notmuch.1 To generate help for a specific notmuch subcommand podselect -section 'Commands/subcommand.*' notmuch.pod | pod2text -c As I'm faced with writing docs for output selection, I'd like to revisit this idea. I didn't get any feedback, positive or negative about the idea of keeping the docs in pod. I don't care much about the format, but I think it would be nice to avoid maintaining two copies of the documentation. Should I rebase/rebuild this against the current docs, or not bother? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Unhandled Xapian exception
On Fri, 23 Apr 2010 13:21:56 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: I propose to try..catch this code block and rather than returning VOID it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION. Not sure how notmuch_database_find_message would notify the caller of such an exception situation though. The only possible failure value is NULL (which also means did not find such a message). We haven't been doing fine-grained exception handling in the library so far. Mostly because the assumption was that there was nothing we could do---when I first wrote the code I assumed that Xapian exceptions would be entirely exceptional. So I just fixed the top-level entry point here to handle this exception in our standard way, (print the message, then return NULL or NOTMUCH_STATUS_XAPIAN_EXCEPTION). While at this, I audited all notmuch_database calls to ensure they follow this scheme. (I have not yet audited all libnotmuch entry points.) Meanwhile, we've recently discovered that there is a Xapian exception that is not all that exceptional. Since database readers don't lock the database, it's not hard to have one or more readers accessing the database when a writer comes along and modifies the database. This triggers the readers to subsequently fail with a DatabaseModified exception. I don't know how conceivable it would be to fix that at the Xapian level. It might be quite nice if opening a database in read-only mode gave access to a snapshot of the database as it exists at that time. But that might be a feature that's entirely unreasonable to implement. Otherwise, we might want to start supporting more clever handling of the exception. For example, the high-level application might want to retry an operation if it fails due to a DatabaseModified exception. To support this, you would want your python bindings to have a layer that would catch the C++ exception and re-throw a python exception. And to support that, we would need a different scheme in the library. Basically to just document that all calls might throw an exception and then not catch and print anything. That would at least be much simpler in the library. Then the top-level notmuch application could just have a C++ wrapper for main() that would catch and print the exception message. What do you think? -Carl pgp0CF9M6Lomx.pgp Description: PGP signature ___ 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 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? -Carl pgp8R9mtCafKN.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add more functions to clean up text/plain parts
On Thu, 22 Apr 2010 13:26:06 +0100, David Edmondson d...@dme.org wrote: This is a small variant on the previous version of the patch. The wrapping of long lines is not enabled by default - it's simply an option in the customise interface. This is really close now. I especially like that the various wash options are as simple as just checkboxes in the customize interface. (That might not even be new in this case, but I at least didn't find it before.) And that again goes to my point. I don't think we should enable this washing by default since it can appear as silent corruption to the user, without any indication that it happened nor how to turn it off. Notmuch has always done some modification of the message with things like hiding long citations, etc. But those at least provide self-documenting buttons on how to make them disappear. Here's what I see in the customize buffer with the latest patch, along with some review. Some of this review applies to documentation already in notmuch---I'm just getting pickier as things appear in customize because I think we need to hold our documentation there to a higher standard. (Previously, one would practically have to dive into the source to find the documentation, and that suggests the reader has more experience and definitely means the user gsts a lot more context). Here, I'm trying to review these options from the point of view of a new user who just started using notmuch, wants to tweak a few things, and is looking at the customize buffer to figure out what tweaks are possible. Notmuch Show Hook: [X] notmuch-show-pretty-hook [ ] notmuch-show-turn-off-word-wrap INS State: STANDARD. A list of functions called after populating a More What does pretty hook mean? What information would a user need to determine whether to turn this on or off? With turn off word wrap, we have on option to disable wrapping here, and another option later to turn some wrapping on again. How is a user expected to figure out which combination of options does what they want? Notmuch Show Insert Text/Plain Hook: Hide Value [ ] notmuch-wash-wrap-long-lines Wrap text in the region whilst maintaining the correct prefix. [X] notmuch-wash-tidy-citations Clean up citations. [X] notmuch-wash-compress-blanks Compress successive blank lines into one blank line. Remove More [X] notmuch-wash-markup-citations Markup citations, and up to one signature in the buffer. Tidy, Clean up, and Markup citations are all too vague. What do each of these actually do? Also, think about line breaks so that something like Remove more doesn't appear there by default. Thanks, -Carl pgp9VyhafG8xj.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Clean up author display for some Last, First cases
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?) +char *cleanauthor,*testauthor; I'd much rather see an underscore separating two words in a single identifier, (so clean_author, test_author). + /* 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. */ 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? + /* 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. -Carl pgpmhhsdbp2An.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Wrapping up the 0.3 release
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 * 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! 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? * Composing a new message with 'm' brings up headers in a scrambled order. A minor point, but it would be nice to fix this. 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. -Carl pgp9kQqOqzLl2.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
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] Add NEWS updates for my last batch of patches
On Fri, 23 Apr 2010 10:42:31 -0700, Dirk Hohndel hohn...@infradead.org wrote: +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 Strange sentence: The script to be called can be customized with. I'd suggest an improvement, but I'm not sure what it should read. micah pgpHRFND5fRMS.pgp Description: PGP signature ___ 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: Wrapping up the 0.3 release
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel hohn...@infradead.org wrote: * 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. This depends at least somewhat on the setting of `pop-up-windows'. Maybe we should: (let ((pop-up-windows nil)) ...) in the reply code? I think that notmuch window handling generally needs some consideration and improvement. Finally, any of the tweaks I suggested to notmuch-hello mode would be quite welcome. I might take a whack at some of these. Hopefully early next week for me. dme. -- David Edmondson, http://dme.org ___ 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: [notmuch] auto-tagging replied messages
-- carl.d.wo...@intel.com On Sat, 24 Apr 2010 09:56:04 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: I'd love to put this into shape to become part of notmuch proper. Great! My question, for this and other things I've worked on, is where code that targets message-mode should go. In notmuch-mua.el? Or a new notmuch-message-utils.el? Or just a catch-all notmuch-utils.el? Once I know where it would make the most sense to group these, I'll submit a patch. You can call it notmuch-message.el if you'd like. I'm never a fan of something generic like -utils. Things like that seem to grow without bounds. But just to clarify: you don't mind if removal is a customizable user option, right? I don't mind at all. I was just happy to realize that we wouldn't have to do any tag removal to make the feature useful out-of-the-box. -Carl pgpT9hGwmHKYk.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Wrapping up the 0.3 release
On Sat, 24 Apr 2010 09:53:17 -0700, Dirk Hohndel hohn...@infradead.org wrote: On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth cwo...@cworth.org wrote: 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? No, what you sent last night is perfect. That will be easier for me. 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. 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. 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. 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. Thanks, -Carl -- carl.d.wo...@intel.com pgpb7ymAi5uPb.pgp Description: PGP signature ___ 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
[PATCH] configure: add ignored options for compatibility.
gentoo's ebuild script expects 2 more options for configure: --host (same format as --build) --datadir --- configure | 20 1 files changed, 20 insertions(+), 0 deletions(-) diff --git a/configure b/configure index ec8c3fd..c522ad8 100755 --- a/configure +++ b/configure @@ -77,7 +77,9 @@ Additional options are accepted for compatibility with other configure-script calling conventions, but don't do anything yet: --build=cpu-vendor-os Currently ignored + --host=cpu-vendor-os Currently ignored --infodir=DIR Currently ignored + --datadir=DIR Currently ignored --localstatedir=DIR Currently ignored --libexecdir=DIRCurrently ignored --disable-maintainer-mode Currently ignored @@ -119,8 +121,26 @@ for option; do build_option=${build_option#*-} build_vendor=${build_option%%-*} build_os=${build_option#*-} +elif [ ${option%%=*} = '--host' ] ; then + host_option=${option#*=} + case ${host_option} in + *-*-*) ;; + *) + echo Unrecognized value for --host option: ${host_option} + echo Should be: cpu-vendor-os + echo See: + echo $0 --help + echo + exit 1 + esac + host_cpu=${host_option%%-*} + host_option=${host_option#*-} + host_vendor=${host_option%%-*} + host_os=${host_option#*-} elif [ ${option%%=*} = '--infodir' ] ; then true +elif [ ${option%%=*} = '--datadir' ] ; then + true elif [ ${option%%=*} = '--localstatedir' ] ; then true elif [ ${option%%=*} = '--libexecdir' ] ; then -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch