[RFC PATCH 3/9] lib: fix messages.c build warn

I don't have much opinion on the other patches in this series (the C99 variadic macro stuff is unfortunate), but this one should go in. Quoth Jani Nikula on Jan 08 at 1:26 am: > lib/messages.c: In function ?notmuch_messages_move_to_next?: > lib/messages.c:131:2: warning: ISO C forbids ?return?

[PATCH 4/4] emacs: use pop-at-end functionality in archive/delete-message functions

This provides a smoother message processing flow by reducing the number of key presses needed for these common operations. --- emacs/notmuch-show.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 4c2b507..7103c23

[PATCH 3/4] emacs: modify the default show-mode key bindings for archiving/deleting

This changes the default key bindings for the 'a' and 'd' keys in notmuch-show mode. Instead of archiving/deleting the entire thread, they now just archive/delete the current message, and then advance to the next open message. 'A' and 'D' are rebound to the previous archive/delete-thread

[PATCH 2/4] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

This will allow for keybindings that achieve a smoother message processing flow by reducing the number of key presses needed for most common operations. --- emacs/notmuch-show.el | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-show.el

[PATCH 1/4] emacs: add show-mode functions to archive/delete only current message

This adds two new function, notmuch-show-{archive,delete}-message, that archive/delete the current message, and then move to the next open one. --- emacs/notmuch-show.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el

change to default archive/delete key bindings

While working on the delete message handling patches, I was reminded how much I really dislike the default show-mode key bindings. Why can't I just archive/delete the current message, without archiving the entire thread? It doesn't make any sense. Here we add two new functions to archive and

[PATCH 4/4] emacs: modify help message for notmuch-search-line-faces to reflect preferred "deleted" tag name.

No functional change here. The help message previously referred to the "delete" tag, but "deleted" is now preferred, so hopefully this will reduce any potential confusion. --- emacs/notmuch.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch.el

[PATCH 3/4] emacs: add ability to "delete" messages and threads

This completely mimics the behavior of archiving, but instead of remove the inbox tag it add the "deleted" tag. The functionality is bound to the 'd' key in both search and show mode. Note: this does *not* actually delete any messages. That is still left entirely up to the user to figure out

[PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

Instead of having a function that is only used for archiving a thread, we instead make it useful for any tagging operation. The new function, notmuch-show-tag-thread-internal, now takes two more arguments, for the "sign" of the tagging operation ("-" or "+"), and the tag to be added or removed.

[PATCH 1/4] emacs: new customization variable to exclude "deleted" messages from search

The new customization variable, notmuch-search-exclude-deleted, when set to t, will exclude any messages with the "deleted" tag from searches. Additionally, specifying "tag:deleted" in the search directly will override the exclusion and will included deleted messages in the search results. ---

another attempt to add delete functionality in emacs

So, after many stabs at adding the ability to "delete" messages in emacs [0], and the corresponding heated discussions, I'm throwing another attempt into the fray. I try to address the concerns that have come up in previous attempts. In particular, I include a patch that creates a new

Info about notmuch database

On Thu, Jan 05, 2012 at 05:35:55PM +0100, Thomas Jost wrote: > On Thu, 5 Jan 2012 16:38:07 +0100, boyska wrote: > > > There's a description of the DB "schema" in lib/database.cc in the > > > notmuch source code. But you may also consider just using libnotmuch > > > instead, if that's enough for

[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"

Hello I do not get the failure with just 1/4 applied but do with all 4 applied. The trivial patch below fixes it, but it might not be the best solution. The failure occurs because Jani's patch changes the behavior of a couple of emacs/notmuch internal functions: the function

[PATCH 0/4] notmuch reply bugfix & reply to sender only

Jameson Graef Rollins writes: > On Thu, 5 Jan 2012 22:25:11 +0200, Jani Nikula wrote: >> Bikeshedding topic #1: How about making replying to just the sender the >> default >> in "notmuch reply", and having --reply-all option (instead of >> --no-reply-all)? >> >> Bikeshedding topic #2: How

[PATCH] restore: Be more liberal in which data to accept.

rrible message ids we can dream up. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120107/617c21c1/attachment.pgp>

[PATCH] restore: Be more liberal in which data to accept.

On Sat, 29 Oct 2011 12:40:07 +0200, Thomas Schwinge wrote: > From: Thomas Schwinge > > There are ``Message-ID''s out in the wild that contain spaces. > > Spammers are quite inventive for creating ``interesting Messages-ID''s. > Apparently, notmuch handles these fine internally, but it breaks

[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"

: user at example.com >+To: > Subject: Re: Testing message sent via SMTP > In-Reply-To: > Fcc: /tmp/notmuch-dev-bremner/test/tmp.emacs/mail/sent > > d -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120107/84f28439/attachment.html>

[PATCH 1/4] cli: fix use of uninitialized variable in "notmuch reply"

On Sat, 7 Jan 2012 09:31:35 +0200, Jani Nikula wrote: > On Jan 7, 2012 5:52 AM, "David Bremner" wrote: > > > > On Thu, 5 Jan 2012 22:25:12 +0200, Jani Nikula wrote: > > > notmuch_show_params_t params is only initialized partially in > > > notmuch_reply_command(). The only field that is used

[PATCH v2] emacs: Helpers for notmuch developers.

On Fri, 6 Jan 2012 10:03:19 +, David Edmondson wrote: > --- > > - Prefix the branch name with 'review/' > - Avoid `shell-command', which also results in better error reporting > when 'git-am' fails. > One thing I noticed is that reviewing a patch for the second time fails because the

[PATCH] emacs: Helpers for notmuch developers.

On Wed, 4 Jan 2012 14:01:18 +, David Edmondson wrote: > --- > > I've been using this for a few days and decided to share it to get > feedback. Reviewing patches can be tedious, so I tried to make things > a little simpler. > > To use this, load the file and then from `notmuch-show-mode'

[PATCH 2/2] lib: add 'safe' setting for flags

On Sat, 16 Jul 2011 23:56:13 -0400, Antoine Beaupr? wrote: > the 'safe' setting needs to be 'true' for flags to be manipulated by > notmuch new/tag/restore. > > for now, only the (T)rash tag is configurable and set to false (by > default) but this could be extended to allow the user to

[PATCH 1/2] lib: Add back the synchronization of 'T' flag with deleted tag.

On Sat, 16 Jul 2011 23:56:12 -0400, Antoine Beaupr? wrote: > This adds a special configuration, off by default, that allows notmuch > to synchronize the T flag again. The configuration is named > maildir_reckless_trash and quite clearly indicates that it could be > dangerous to use in the

[PATCH 0/4] notmuch reply bugfix & reply to sender only

On Thu, 5 Jan 2012 17:01:44 -0700, Adam Wolfe Gordon wrote: > On Thu, Jan 5, 2012 at 13:25, Jani Nikula wrote: > > Bikeshedding topic #1: How about making replying to just the sender the > > default > > in "notmuch reply", and having --reply-all option (instead of > >

Re: Info about notmuch database

On Thu, Jan 05, 2012 at 05:35:55PM +0100, Thomas Jost wrote: On Thu, 5 Jan 2012 16:38:07 +0100, boyska piutto...@logorroici.org wrote: There's a description of the DB schema in lib/database.cc in the notmuch source code. But you may also consider just using libnotmuch instead, if that's

Re: [PATCH 1/4] cli: fix use of uninitialized variable in notmuch reply

Hello I do not get the failure with just 1/4 applied but do with all 4 applied. The trivial patch below fixes it, but it might not be the best solution. The failure occurs because Jani's patch changes the behavior of a couple of emacs/notmuch internal functions: the function

Re: [PATCH 1/4] cli: fix use of uninitialized variable in notmuch reply

On Sat, 7 Jan 2012 09:31:35 +0200, Jani Nikula j...@nikula.org wrote: On Jan 7, 2012 5:52 AM, David Bremner da...@tethera.net wrote: On Thu, 5 Jan 2012 22:25:12 +0200, Jani Nikula j...@nikula.org wrote: notmuch_show_params_t params is only initialized partially in

Re: [PATCH] restore: Be more liberal in which data to accept.

On Sat, 29 Oct 2011 12:40:07 +0200, Thomas Schwinge tho...@schwinge.name wrote: From: Thomas Schwinge tho...@schwinge.name There are ``Message-ID''s out in the wild that contain spaces. Spammers are quite inventive for creating ``interesting Messages-ID''s. Apparently, notmuch handles

Re: [PATCH] restore: Be more liberal in which data to accept.

On Sat, 07 Jan 2012 09:37:20 -0400, David Bremner da...@tethera.net wrote: 2) can you share (by private email is a fine) a few of those really problematic messages so I can use them to test the new dump/restore code? I think the better option would be to create a test that runs through all

Re: [PATCH 0/4] notmuch reply bugfix reply to sender only

Jameson Graef Rollins jroll...@finestructure.net writes: On Thu, 5 Jan 2012 22:25:11 +0200, Jani Nikula j...@nikula.org wrote: Bikeshedding topic #1: How about making replying to just the sender the default in notmuch reply, and having --reply-all option (instead of --no-reply-all)?

another attempt to add delete functionality in emacs

So, after many stabs at adding the ability to delete messages in emacs [0], and the corresponding heated discussions, I'm throwing another attempt into the fray. I try to address the concerns that have come up in previous attempts. In particular, I include a patch that creates a new customization

[PATCH 4/4] emacs: modify help message for notmuch-search-line-faces to reflect preferred deleted tag name.

No functional change here. The help message previously referred to the delete tag, but deleted is now preferred, so hopefully this will reduce any potential confusion. --- emacs/notmuch.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch.el

[PATCH 2/4] emacs: repurpose notmuch-show-archive-thread-internal function for general thread tagging

Instead of having a function that is only used for archiving a thread, we instead make it useful for any tagging operation. The new function, notmuch-show-tag-thread-internal, now takes two more arguments, for the sign of the tagging operation (- or +), and the tag to be added or removed. This

[PATCH 3/4] emacs: add ability to delete messages and threads

This completely mimics the behavior of archiving, but instead of remove the inbox tag it add the deleted tag. The functionality is bound to the 'd' key in both search and show mode. Note: this does *not* actually delete any messages. That is still left entirely up to the user to figure out how

[PATCH 1/4] emacs: new customization variable to exclude deleted messages from search

The new customization variable, notmuch-search-exclude-deleted, when set to t, will exclude any messages with the deleted tag from searches. Additionally, specifying tag:deleted in the search directly will override the exclusion and will included deleted messages in the search results. ---

[RFC PATCH 0/9] -std=c99 / -std=c++0x -pedantic

Hi all, this series was borne of curiousity about compiling the notmuch codebase using -std=c99 / -std=c++0x -pedantic options. The C part is split into separate patches to make it easier to see each warning and fix; with C++ I didn't bother so much. Turns out there are a few specific issues, but

[RFC PATCH 2/9] xutil: #define _POSIX_C_SOURCE to get strdup()

strdup() is not standard C99. #define _POSIX_C_SOURCE 200809L to use it. This fixes -std=c99 -pedantic warning: util/xutil.c: In function ‘xstrdup’: util/xutil.c:74:5: warning: implicit declaration of function ‘strdup’ [-Wimplicit-function-declaration] util/xutil.c:74:9: warning: assignment

[RFC PATCH 3/9] lib: fix messages.c build warn

lib/messages.c: In function ‘notmuch_messages_move_to_next’: lib/messages.c:131:2: warning: ISO C forbids ‘return’ with expression, in function returning void [-pedantic] Signed-off-by: Jani Nikula j...@nikula.org --- lib/messages.c |6 -- 1 files changed, 4 insertions(+), 2

[RFC PATCH 5/9] cli: fix warning about variadic macros

notmuch-restore.c: In function ‘notmuch_restore_command’: notmuch-restore.c:87:54: warning: ISO C99 requires rest arguments to be used [enabled by default] and elsewhere. ##__VA_ARGS__ is a GCC CPP extension. Signed-off-by: Jani Nikula j...@nikula.org --- notmuch-client.h |9 ++--- 1

[RFC PATCH 6/9] cli: fix another warning about variadic macros

notmuch-setup.c: In function ‘notmuch_setup_command’: notmuch-setup.c:144:62: warning: ISO C99 requires rest arguments to be used [enabled by default] notmuch-setup.c:174:18: warning: ISO C99 requires rest arguments to be used [enabled by default] Signed-off-by: Jani Nikula j...@nikula.org ---

[RFC PATCH 7/9] util: fix warning about variadic macros

lib/string-list.c: In function ‘_notmuch_string_list_sort’: lib/string-list.c:81:59: warning: ISO C99 requires rest arguments to be used [enabled by default] lib/message-file.c: In function ‘notmuch_message_file_restrict_headersv’: lib/message-file.c:147:90: warning: ISO C99 requires rest

[RFC PATCH 9/9] test: smtp-dummy: fixes for -std=c99 -pedantic

Signed-off-by: Jani Nikula j...@nikula.org --- test/smtp-dummy.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/test/smtp-dummy.c b/test/smtp-dummy.c index 3801a5e..1c29a7d 100644 --- a/test/smtp-dummy.c +++ b/test/smtp-dummy.c @@ -33,6 +33,8 @@ * have been warned.

[RFC PATCH 8/9] lib: use -std=c++0x -pedantic

Introduces warnings such as: In file included from /usr/include/gmime-2.4/gmime/gmime.h:39:0, from lib/database.cc:31: /usr/include/gmime-2.4/gmime/gmime-message.h:57:26: warning: comma at end of enumerator list [-pedantic] Signed-off-by: Jani Nikula j...@nikula.org ---

Re: [RFC PATCH 3/9] lib: fix messages.c build warn

I don't have much opinion on the other patches in this series (the C99 variadic macro stuff is unfortunate), but this one should go in. Quoth Jani Nikula on Jan 08 at 1:26 am: lib/messages.c: In function ‘notmuch_messages_move_to_next’: lib/messages.c:131:2: warning: ISO C forbids ‘return’

[PATCH 2/4] emacs: add option to notmuch-show-next-open-message to pop out to parent buffer if at end

This will allow for keybindings that achieve a smoother message processing flow by reducing the number of key presses needed for most common operations. --- emacs/notmuch-show.el | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-show.el

[PATCH 3/4] emacs: modify the default show-mode key bindings for archiving/deleting

This changes the default key bindings for the 'a' and 'd' keys in notmuch-show mode. Instead of archiving/deleting the entire thread, they now just archive/delete the current message, and then advance to the next open message. 'A' and 'D' are rebound to the previous archive/delete-thread

[PATCH 4/4] emacs: use pop-at-end functionality in archive/delete-message functions

This provides a smoother message processing flow by reducing the number of key presses needed for these common operations. --- emacs/notmuch-show.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 4c2b507..7103c23

change to default archive/delete key bindings

While working on the delete message handling patches, I was reminded how much I really dislike the default show-mode key bindings. Why can't I just archive/delete the current message, without archiving the entire thread? It doesn't make any sense. Here we add two new functions to archive and

[PATCH 1/4] emacs: add show-mode functions to archive/delete only current message

This adds two new function, notmuch-show-{archive,delete}-message, that archive/delete the current message, and then move to the next open one. --- emacs/notmuch-show.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el

[PATCH 0/4] Quoting HTML-only emails in replies redux

From: Adam Wolfe Gordon a...@xvx.ca Hi everyone, This is a rework of my previous patch series adding support for replying to HTML email in the emacs interface (id:1322671241-23438-1-git-send-email-awg+notm...@xvx.ca). It was suggested on IRC that a more general solution would be to add a JSON

[PATCH 1/4] test: Add broken test for the new JSON reply format.

From: Adam Wolfe Gordon a...@xvx.ca --- test/multipart |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/test/multipart b/test/multipart index f83526b..f5ebf04 100755 --- a/test/multipart +++ b/test/multipart @@ -589,6 +589,13 @@ Non-text part: text/html EOF

[PATCH 3/4] man: Update notmuch-reply man page for JSON format.

From: Adam Wolfe Gordon a...@xvx.ca --- man/man1/notmuch-reply.1 |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/man/man1/notmuch-reply.1 b/man/man1/notmuch-reply.1 index 099d808..240dfed 100644 --- a/man/man1/notmuch-reply.1 +++ b/man/man1/notmuch-reply.1 @@ -41,6

[PATCH 2/4] reply: Add a JSON reply format.

From: Adam Wolfe Gordon a...@xvx.ca This new JSON format for replies includes headers generated for a reply message as well as the headers and all text parts of the original message. Using this data, a client can intelligently create a reply. For example, the emacs client will be able to create

[PATCH 4/4] emacs: Use the new JSON reply format.

From: Adam Wolfe Gordon a...@xvx.ca Using the new JSON reply format allows emacs to quote HTML parts nicely by first parsing them with w3m, then quoting them. This is very useful for users who regularly receive HTML-only email. The behavior for messages that contain plain text parts should be