Re: [PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello

[Jani Nikula]

Hi Austin, id:1330811724-30901-1-git-send-email-j...@nikula.org :)

Mark had a valid point about ordering within groups, which I didn't
follow up on, but this is a necessary intermediate step in the right
direction no matter what. I don't care whose patches get merged, but
let's merge the change.

Jani.


On Sun, 15 Apr 2012 22:57:36 -0400, Austin Clements amdra...@mit.edu wrote:
 ---
  emacs/notmuch-hello.el |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 71d37b8..f10d98d 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -226,7 +226,7 @@ by an additional filter query. Similarly, the count of 
 messages
  displayed next to the buttons can be generated by applying a
  different filter to the tag query. These filters are also
  supported for \Customized queries section\ items.
 -  :group 'notmuch
 +  :group 'notmuch-hello
:type
'(repeat
  (choice (function-item notmuch-hello-insert-header)
 -- 
 1.7.9.1
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[Tomi Ollila]

On Mon, Apr 16 2012, Jameson Graef Rollins jroll...@finestructure.net wrote:

 On Sun, Apr 15 2012, Tomi Ollila tomi.oll...@iki.fi wrote:
 id:1326826969-23545-1-git-send-email-jroll...@finestructure.net

 Does just delete - deleted change: the only question I have left
 is that should that be left as is, this change made, or just drop
 the delete coloring altogether ?

 Sorry, yes, I suppose this patch should still be applied.  Excludes for
 deleted are the default, I believe, so if we are going to refer to it
 in documentation we should probably be consistent.

That said, the following change in nmbug repository

D1326826969-23545-1-git-send-email-jroll...@finestructure.net needs-review
A1326826969-23545-1-git-send-email-jroll...@finestructure.net trivial

pushed.

Tomi


 On Sun, Apr 15 2012, Jameson Graef Rollins jroll...@finestructure.net wrote:
 On Sun, Apr 15 2012, Mark Walters markwalters1...@gmail.com wrote:
 I think the rest of the series (which provides keybindings for
 adding/removing the delete tag to messages/threads) is worthwhile
 particularly now the exclude stuff is fairly complete (feedback at the
 time looked positive).

 Sorry, I wish I could have purged all of these series from the list.
 After a very protracted discussion on the topic it was decided that
 notmuch will not support any delete tagging operations.  Users who wish
 to do so can add support on their own:

 I think my reaction here was a little strong.  I'm not remembering how I
 got the impression that there was more opposition to adding delete
 keybindings than there was support.  I suppose now that excludes work so
 well one (not me) might consider revisiting the issue.

 jamie.
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello

[Mark Walters]

On Mon, 16 Apr 2012, Jani Nikula j...@nikula.org wrote:
 Hi Austin, id:1330811724-30901-1-git-send-email-j...@nikula.org :)

 Mark had a valid point about ordering within groups, which I didn't
 follow up on, but this is a necessary intermediate step in the right
 direction no matter what. I don't care whose patches get merged, but
 let's merge the change.

 Jani.

I complete agree: let's push one of these (and sorry for holding up your
original patch!)

Best wishes

Mark



 On Sun, 15 Apr 2012 22:57:36 -0400, Austin Clements amdra...@mit.edu wrote:
 ---
  emacs/notmuch-hello.el |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 71d37b8..f10d98d 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -226,7 +226,7 @@ by an additional filter query. Similarly, the count of 
 messages
  displayed next to the buttons can be generated by applying a
  different filter to the tag query. These filters are also
  supported for \Customized queries section\ items.
 -  :group 'notmuch
 +  :group 'notmuch-hello
:type
'(repeat
  (choice (function-item notmuch-hello-insert-header)
 -- 
 1.7.9.1
 
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: some stale patches dropped from the review queue

[Justus Winter]

Hi Jani,

thanks for your efforts.

id:1316999137-28257-8-git-send-email-4win...@informatik.uni-hamburg.de

That one is obsolete.

Justus
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

.. regarding opening the attached files ...

[David Belohrad]

Dear Experts, 
could someone give me a hint:

I receive an email with attachment. It says it is a pdf, e.g. like this:

 [ Ultra_Low_Noise_AC_Beam_Transformer2.pdf: application/pdf ]

when I click on it, I would assume, that it opens the file using
'default' application, which is - when looking into file associations -
okular.

Instead, it opens a dialog box to save the attachment first. This is not
really desired.

Is there any way how to change it? It seems that is does it will all
attachments, not only pdf. Regardless of whether correct file
association is made in the KDE.

thanks a lot


-- 
.david.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[Mark Walters]

On Mon, 16 Apr 2012, David Belohrad da...@belohrad.ch wrote:
 Dear Experts, 
 could someone give me a hint:

 I receive an email with attachment. It says it is a pdf, e.g. like this:

  [ Ultra_Low_Noise_AC_Beam_Transformer2.pdf: application/pdf ]

 when I click on it, I would assume, that it opens the file using
 'default' application, which is - when looking into file associations -
 okular.

 Instead, it opens a dialog box to save the attachment first. This is not
 really desired.

 Is there any way how to change it? It seems that is does it will all
 attachments, not only pdf. Regardless of whether correct file
 association is made in the KDE.

Hi

it is customizable under M-x customize-group notmuch - notmuch-show -
Notmuch Show Part Button Default Action:

The view option  uses the mailcap entry to open the attachment.

Best wishes

Mark

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] configure: test shell parameter substring processing and possibly exec one

[Tomi Ollila]

configure script uses parameter substring extensively. It is Posix shell
feature. Original Bourne shell does not have such features. Some systems
still ships such shells as /bin/sh (for compatibility reasons -- shell
scripts written on those platforms are expected to work in 1990's systems...)

To tackle this situation the beginning of configure attemts to do a silent
parameter substitution in a subshell; in case this fails the subshell exits
with nonzero value which is easy to detect.

The || constructs are used twice. The first one is used as Bourne shell
chokes on 'if ! ... ' construct (and if ...; then :; else do_things; fi
looks stupid). The second one(liner) takes care of the possible future
'set -eu' in the beginning of this script.
---

This patch obsoletes 
id:133395-10469-2-git-send-email-vladimir.ma...@oracle.com

 configure |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 71981b7..06fbeff 100755
--- a/configure
+++ b/configure
@@ -1,5 +1,19 @@
 #! /bin/sh
 
+# Test whether this sh is capable of parameter substring processing.
+# If not, attempt to locate and launch one which probably can.
+( option=option=value; : ${option#*=} ) 2/dev/null || {
+if test x${_NOTMUCH_CONFIGURE-} = x ; then
+   NOTMUCH_CONFIGURE=1; export _NOTMUCH_CONFIGURE
+   for x in /bin/ksh /bin/bash /usr/bin/bash
+   do test ! -x $x || exec $x $0 $@
+   done
+fi
+echo Cannot find compatible shell to execute '$0' 2
+exit 1
+}
+unset _NOTMUCH_CONFIGURE
+
 # Store original IFS value so it can be changed (and restored) in many places.
 readonly DEFAULT_IFS=$IFS
 
-- 
1.7.8.2

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[Jameson Graef Rollins]

On Mon, Apr 16 2012, Mark Walters markwalters1...@gmail.com wrote:
 On Mon, 16 Apr 2012, David Belohrad da...@belohrad.ch wrote:
 I receive an email with attachment. It says it is a pdf, e.g. like this:

  [ Ultra_Low_Noise_AC_Beam_Transformer2.pdf: application/pdf ]

 when I click on it, I would assume, that it opens the file using
 'default' application, which is - when looking into file associations -
 okular.
...
 it is customizable under M-x customize-group notmuch - notmuch-show -
 Notmuch Show Part Button Default Action:

 The view option  uses the mailcap entry to open the attachment.

Also, when the cursor is on the button you can hit 'o' to open with
default mailcap app, 's' to save, and 'v' to view with a specified app.

jamie.


pgpktKgRPOF9Q.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Add a new.filename_tags option

[Neil Roberts]

This option is similar to the existing new.tags option except that it
is instead used when a new filename is encountered for an existing
message.

This can be used to do post-processing based on the filenames that a
message has. For example, in my setup I use maildrop to filter the
messages in to maildirs and then I have an extra script that runs to
add the tags based on which folders maildrop put the message in. The
script only looks at messages that have the 'inbox' tag and then
removes the tag after processing. This works fine except sometimes I
will get a message twice for example if I am CC'd in a message from a
mailing list. In that case I want the message to be tagged twice, once
to indicate it was sent directly to me and once to indicate it was
sent to the mailing list. If one of these messages is delayed then I
can end up processing the message once and removing the inbox tag.
When the second message is finally received it would previously not
get processed again so I would lose the second tag. With this patch I
can configure it to re-add the inbox tag in this case to force it to
reconsider the tags.
---
 man/man1/notmuch-config.1 |8 
 notmuch-client.h  |9 +
 notmuch-config.c  |   34 ++
 notmuch-new.c |7 +++
 4 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/man/man1/notmuch-config.1 b/man/man1/notmuch-config.1
index 395cb9c..caf20b4 100644
--- a/man/man1/notmuch-config.1
+++ b/man/man1/notmuch-config.1
@@ -74,6 +74,14 @@ A list of tags that will be added to all messages 
incorporated by
 
 .RS 4
 .TP 4
+.B new.filename_tags
+A list of tags that will be added to any message when a new filename
+is encountered for it during
+.BR notmuch new.
+.RE
+
+.RS 4
+.TP 4
 .B new.ignore
 A list of file and directory names, without path, that will not be
 searched for messages by
diff --git a/notmuch-client.h b/notmuch-client.h
index 19b7f01..55bcef4 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -238,6 +238,15 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 size_t length);
 
 const char **
+notmuch_config_get_new_filename_tags (notmuch_config_t *config,
+ size_t *length);
+
+void
+notmuch_config_set_new_filename_tags (notmuch_config_t *config,
+ const char *new_tags[],
+ size_t length);
+
+const char **
 notmuch_config_get_new_ignore (notmuch_config_t *config,
   size_t *length);
 
diff --git a/notmuch-config.c b/notmuch-config.c
index e9b2750..acbc08d 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -111,6 +111,8 @@ struct _notmuch_config {
 size_t user_other_email_length;
 const char **new_tags;
 size_t new_tags_length;
+const char **new_filename_tags;
+size_t new_filename_tags_length;
 const char **new_ignore;
 size_t new_ignore_length;
 notmuch_bool_t maildir_synchronize_flags;
@@ -272,6 +274,8 @@ notmuch_config_open (void *ctx,
 config-user_other_email_length = 0;
 config-new_tags = NULL;
 config-new_tags_length = 0;
+config-new_filename_tags = NULL;
+config-new_filename_tags_length = 0;
 config-new_ignore = NULL;
 config-new_ignore_length = 0;
 config-maildir_synchronize_flags = TRUE;
@@ -371,6 +375,10 @@ notmuch_config_open (void *ctx,
notmuch_config_set_new_tags (config, tags, 2);
 }
 
+if (notmuch_config_get_new_filename_tags (config, tmp) == NULL) {
+   notmuch_config_set_new_filename_tags (config, NULL, 0);
+}
+
 if (notmuch_config_get_new_ignore (config, tmp) == NULL) {
notmuch_config_set_new_ignore (config, NULL, 0);
 }
@@ -624,6 +632,16 @@ notmuch_config_get_new_tags (notmuch_config_t *config,   
size_t *length)
 }
 
 const char **
+notmuch_config_get_new_filename_tags (notmuch_config_t *config,
+ size_t *length)
+{
+return _config_get_list (config, new, filename_tags,
+(config-new_filename_tags),
+(config-new_filename_tags_length),
+length);
+}
+
+const char **
 notmuch_config_get_new_ignore (notmuch_config_t *config, size_t *length)
 {
 return _config_get_list (config, new, ignore,
@@ -650,6 +668,15 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 }
 
 void
+notmuch_config_set_new_filename_tags (notmuch_config_t *config,
+ const char *list[],
+ size_t length)
+{
+_config_set_list (config, new, filename_tags, list, length,
+ (config-new_filename_tags));
+}
+
+void
 notmuch_config_set_new_ignore (notmuch_config_t *config,
   const char *list[],
   size_t length)
@@ -731,6 +758,13 @@ notmuch_config_command_get (void 

Re: [PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello

[Austin Clements]

Quoth Jani Nikula on Apr 16 at  6:58 am:
 Hi Austin, id:1330811724-30901-1-git-send-email-j...@nikula.org :)
 
 Mark had a valid point about ordering within groups, which I didn't
 follow up on, but this is a necessary intermediate step in the right
 direction no matter what. I don't care whose patches get merged, but
 let's merge the change.

Ah, indeed!  If only I had an MUA that let me easily search my mail...

The order of the customs is just the order they're listed in defgroup
(currently we don't pass any to defgroup) followed by the order Emacs
evaluates the defcustoms in (defcustom - custom-handle-keyword -
custom-add-to-group).  We could use defgroup is put really important
ones at the top if we want.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/3] new: Consistently treat fatal errors as fatal

[Mark Walters]

On Mon, 27 Feb 2012, Austin Clements amdra...@mit.edu wrote:
 Previously, fatal errors in add_files_recursive were not treated as
 fatal by its callers (including itself!) and add_files_recursive
 sometimes returned errors on non-fatal conditions.  This makes
 add_files_recursive errors consistently fatal and updates all callers
 to treat them as fatal.

Hi I have attempted to review this but am feeling a little out of my
depth. This patch seems fine except for one thing I am unsure about:

 ---
  notmuch-new.c |   13 -
  1 files changed, 8 insertions(+), 5 deletions(-)

 diff --git a/notmuch-new.c b/notmuch-new.c
 index 4f13535..bd9786a 100644
 --- a/notmuch-new.c
 +++ b/notmuch-new.c
 @@ -308,7 +308,6 @@ add_files_recursive (notmuch_database_t *notmuch,
  if (num_fs_entries == -1) {
   fprintf (stderr, Error opening directory %s: %s\n,
path, strerror (errno));
 - ret = NOTMUCH_STATUS_FILE_ERROR;
   goto DONE;
  }
  

If I understand this, then this change makes a failure to open a
directory non-fatal. In the comment before the function it says

 * Also, we don't immediately act on file/directory removal since we
 * must ensure that in the case of a rename that the new filename is
 * added before the old filename is removed, (so that no information
 * is lost from the database).
 
I am  worried that we could fail to find some files because of the
file error above, and then we delete them from the database. Maybe this
could only happen if those emails have just been moved to this
file-error directory?

Best wishes

Mark

 @@ -351,8 +350,10 @@ add_files_recursive (notmuch_database_t *notmuch,
  
   next = talloc_asprintf (notmuch, %s/%s, path, entry-d_name);
   status = add_files_recursive (notmuch, next, state);
 - if (status  ret == NOTMUCH_STATUS_SUCCESS)
 + if (status) {
   ret = status;
 + goto DONE;
 + }
   talloc_free (next);
   next = NULL;
  }
 @@ -933,6 +934,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
  }
  
  ret = add_files (notmuch, db_path, add_files_state);
 +if (ret)
 + goto DONE;
  
  gettimeofday (tv_start, NULL);
  for (f = add_files_state.removed_files-head; f  !interrupted; f = 
 f-next) {
 @@ -965,6 +968,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
   }
  }
  
 +  DONE:
  talloc_free (add_files_state.removed_files);
  talloc_free (add_files_state.removed_directories);
  talloc_free (add_files_state.directory_mtimes);
 @@ -1012,10 +1016,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
  
  printf (\n);
  
 -if (ret) {
 - printf (\nNote: At least one error was encountered: %s\n,
 +if (ret)
 + printf (\nNote: A fatal error was encountered: %s\n,
   notmuch_status_to_string (ret));
 -}
  
  notmuch_database_close (notmuch);
  
 -- 
 1.7.7.3

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 2/3] new: Handle fatal errors in remove_filename and _remove_directory

[Mark Walters]

On Mon, 27 Feb 2012, Austin Clements amdra...@mit.edu wrote:
 Previously such errors were simply ignored.  Now they cause an
 immediate cleanup and abort.

This one looks fine except for a minor query.

 ---
  notmuch-new.c |   24 ++--
  1 files changed, 18 insertions(+), 6 deletions(-)

 diff --git a/notmuch-new.c b/notmuch-new.c
 index bd9786a..0cbd479 100644
 --- a/notmuch-new.c
 +++ b/notmuch-new.c
 @@ -780,8 +780,10 @@ remove_filename (notmuch_database_t *notmuch,
   add_files_state-renamed_messages++;
   if (add_files_state-synchronize_flags == TRUE)
   notmuch_message_maildir_flags_to_tags (message);
 -} else
 + status = NOTMUCH_STATUS_SUCCESS;
 +} else if (status == NOTMUCH_STATUS_SUCCESS) {
   add_files_state-removed_messages++;
 +}
  notmuch_message_destroy (message);
  notmuch_database_end_atomic (notmuch);
  return status;
 @@ -789,12 +791,13 @@ remove_filename (notmuch_database_t *notmuch,
  
  /* Recursively remove all filenames from the database referring to
   * 'path' (or to any of its children). */
 -static void
 +static notmuch_status_t
  _remove_directory (void *ctx,
  notmuch_database_t *notmuch,
  const char *path,
  add_files_state_t *add_files_state)
  {
 +notmuch_status_t status;
  notmuch_directory_t *directory;
  notmuch_filenames_t *files, *subdirs;
  char *absolute;
 @@ -807,8 +810,10 @@ _remove_directory (void *ctx,
  {
   absolute = talloc_asprintf (ctx, %s/%s, path,
   notmuch_filenames_get (files));
 - remove_filename (notmuch, absolute, add_files_state);
 + status = remove_filename (notmuch, absolute, add_files_state);
   talloc_free (absolute);
 + if (status)
 + return status;
  }
  
  for (subdirs = notmuch_directory_get_child_directories (directory);
 @@ -817,11 +822,14 @@ _remove_directory (void *ctx,
  {
   absolute = talloc_asprintf (ctx, %s/%s, path,
   notmuch_filenames_get (subdirs));
 - _remove_directory (ctx, notmuch, absolute, add_files_state);
 + status = _remove_directory (ctx, notmuch, absolute, add_files_state);
   talloc_free (absolute);
 + if (status)
 + return status;
  }
  
  notmuch_directory_destroy (directory);
 +return NOTMUCH_STATUS_SUCCESS;
  }

In the two return status lines above seem to mean we don't call
notmuch_directory_destroy. Does that matter?

The other query is not actually about this patch: just something that
came up when reading it. Should notmuch_database_begin_atomic and
notmuch_database_end_atomic always be paired? One of the (existing)
error cases in remove_filename seems to return without calling end.

Best wishes

Mark

  int
 @@ -939,7 +947,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
  
  gettimeofday (tv_start, NULL);
  for (f = add_files_state.removed_files-head; f  !interrupted; f = 
 f-next) {
 - remove_filename (notmuch, f-filename, add_files_state);
 + ret = remove_filename (notmuch, f-filename, add_files_state);
 + if (ret)
 + goto DONE;
   if (do_print_progress) {
   do_print_progress = 0;
   generic_print_progress (Cleaned up, messages,
 @@ -950,7 +960,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
  
  gettimeofday (tv_start, NULL);
  for (f = add_files_state.removed_directories-head, i = 0; f  
 !interrupted; f = f-next, i++) {
 - _remove_directory (ctx, notmuch, f-filename, add_files_state);
 + ret = _remove_directory (ctx, notmuch, f-filename, add_files_state);
 + if (ret)
 + goto DONE;
   if (do_print_progress) {
   do_print_progress = 0;
   generic_print_progress (Cleaned up, directories,
 -- 
 1.7.7.3

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[Jeremy Nickurak]

On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[David Belohrad]

Does kde use the same database as gnome? 

Jeremy Nickurak not-m...@trk.nickurak.canapsal/a:

On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[Jeremy Nickurak]

No idea. I expect they don't use mailcap though... any KDE users here?

On Mon, Apr 16, 2012 at 10:54, David Belohrad da...@belohrad.ch wrote:
 Does kde use the same database as gnome?

 Jeremy Nickurak not-m...@trk.nickurak.canapsal/a:

On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[Jameson Graef Rollins]

On Mon, Apr 16 2012, Jeremy Nickurak not-m...@trk.nickurak.ca wrote:
 On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
 jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

 Is there any way of just getting it to ignore mailcap, and send
 everything to xdg-open? It's always bothered me that there are 2
 databases for file associations: mailcap (used only by Emacs, afaict),
 and the xdg/gnome configuration (used by everything else).

Yes, gnome is very obnoxious that way.  mailcap has been around *much*
longer than gnome.  There was really no reason for them to reinvent the
wheel.

Right now 'view part' command runs notmuch-show-view-part function,
which calls mm-display-part.  You might check in mm- config settings to
see if there's anything there you can tweak.

jamie.




pgpFegzNkLaVH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: .. regarding opening the attached files ...

[David Belohrad]

Well that's why I'm asking. I'm kde user.  kde has its own handling of file 
associations. I assume that it is different solution than gnome has. Hence one 
might conclude that there is no standard how to provide associations and thus 
emacs one is as good as all the others 



Jeremy Nickurak jer...@nickurak.canapsal/a:

No idea. I expect they don't use mailcap though... any KDE users here?

On Mon, Apr 16, 2012 at 10:54, David Belohrad da...@belohrad.ch wrote:
 Does kde use the same database as gnome?

 Jeremy Nickurak not-m...@trk.nickurak.canapsal/a:

On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).



-- 
Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =-
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [RFC] Split notmuch_database_close into two functions

[Tomi Ollila]

On Tue, Apr 17 2012, Justus Winter 4win...@informatik.uni-hamburg.de wrote:

 Hi everyone,

 Quoting Patrick Totzke (2012-04-13 10:33:58)
 Quoting Austin Clements (2012-04-01 04:23:23)
 Maybe you could describe your use case in more detail?
 
 Quoting Austin Clements (2012-04-12 17:57:44)
 Quoth Justus Winter on Apr 12 at 11:05 am:
 ...
 I see.  TL;DR
 
 .. which should pretty much settle Austins opinion on
 libnotmuch users being second class citizens.

 Na, I think you misinterpreted Austin here, I think he summarized his
 position. Looking back at my mail I think I came across a lot harsher
 than necessary, I'm sorry for that. Let's get back to the issue at
 hand, shall we?

 Both Austin and Mark seem to support the split, any other opinions?

I support it too (as did earlyer). Do we already have pushable series
or is there a need for a new one ? It would be good to have this done
so that application writers can start relying this being available
in official notmuch (in 0.13 -- SONAME updated -- any other patches
pending requiring SONAME bump to be reviewed ?).


 Cheers,
 Justus

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

some stale patches dropped from the review queue

[Jani Nikula]

On Sun, 15 Apr 2012, Jani Nikula  wrote:
> I have tagged the following patches notmuch::stale, removing them from
> the review queue [1], purely based on they not applying to master
> anymore (see [2] for tag definitions). Please rebase your patches
> against master and resubmit if you think they're still relevant. If you
> think this is in error, please complain.
>
> BR,
> Jani.
>
> [1] http://nmbug.tethera.net/status/
> [2] http://notmuchmail.org/nmbug/

2nd batch, with some notmuch::obsolete tagged patches listed separately
at the end.

There are still plenty of patches in the review queue that need to be
decided on. This was a simple technical clean up based on whether the
patches still apply or not.

Also, only the stale patches and patches from the stale patch on in each
series were tagged, sometimes leaving behind half a series that does
apply. They are still in the queue.


id:1326591624-15493-10-git-send-email-david at tethera.net
id:1326591624-15493-11-git-send-email-david at tethera.net
id:1326591624-15493-4-git-send-email-david at tethera.net
id:1326591624-15493-5-git-send-email-david at tethera.net
id:1326591624-15493-6-git-send-email-david at tethera.net
id:1326591624-15493-7-git-send-email-david at tethera.net
id:1326591624-15493-8-git-send-email-david at tethera.net
id:1326591624-15493-9-git-send-email-david at tethera.net

id:1330122640-18895-6-git-send-email-pieter at praet.org
id:1330122640-18895-7-git-send-email-pieter at praet.org

id:1325986015-22510-3-git-send-email-jrollins at finestructure.net
id:1325986015-22510-4-git-send-email-jrollins at finestructure.net
id:1325986015-22510-5-git-send-email-jrollins at finestructure.net

id:1334077496-9172-2-git-send-email-markwalters1009 at gmail.com
id:1334077496-9172-3-git-send-email-markwalters1009 at gmail.com

id:1332171061-27983-3-git-send-email-markwalters1009 at gmail.com

id:1331149792-17192-1-git-send-email-pieter at praet.org

id:1329936214-30959-4-git-send-email-pieter at praet.org
id:1329936214-30959-5-git-send-email-pieter at praet.org
id:1329936214-30959-6-git-send-email-pieter at praet.org
id:1329936214-30959-7-git-send-email-pieter at praet.org

id:1329319688-16056-1-git-send-email-awg+notmuch at xvx.ca

id:1328688139-3865-3-git-send-email-dme at dme.org

id:1328604377-20121-2-git-send-email-dme at dme.org

id:1328568490-18473-1-git-send-email-dme at dme.org

id:1328542748-19530-3-git-send-email-dme at dme.org
id:1328542748-19530-4-git-send-email-dme at dme.org
id:1328542748-19530-5-git-send-email-dme at dme.org

id:1323796305-28789-4-git-send-email-schnouki at schnouki.net
id:1323796305-28789-5-git-send-email-schnouki at schnouki.net
id:1323796305-28789-6-git-send-email-schnouki at schnouki.net


Obsolete - AFAICT there was a more recent version of each of these
posted:

id:1333149350-22616-2-git-send-email-novalazy at gmail.com
id:1333149350-22616-3-git-send-email-novalazy at gmail.com
id:1333149350-22616-4-git-send-email-novalazy at gmail.com
id:1333149350-22616-5-git-send-email-novalazy at gmail.com
id:1333149350-22616-6-git-send-email-novalazy at gmail.com

id:1333845338-22960-2-git-send-email-jrollins at finestructure.net
id:1333845338-22960-3-git-send-email-jrollins at finestructure.net
id:1333845338-22960-4-git-send-email-jrollins at finestructure.net
id:1333845338-22960-5-git-send-email-jrollins at finestructure.net
id:1333845338-22960-6-git-send-email-jrollins at finestructure.net
id:1333845338-22960-7-git-send-email-jrollins at finestructure.net
id:1333845338-22960-8-git-send-email-jrollins at finestructure.net
id:1333845338-22960-9-git-send-email-jrollins at finestructure.net

id:1332635232-15269-2-git-send-email-awg+notmuch at xvx.ca
id:1332635232-15269-3-git-send-email-awg+notmuch at xvx.ca

[PATCH 4/4] Explicitly type void* pointers

[Jani Nikula]

I tagged this patch notmuch::obsolete (see [1]) as the template
workaround was pushed to master (commit
de0557477d908be26615e8fda9f5eb62bed68b65).

Jani.


[1] http://nmbug.tethera.net/status/


On Mon, 09 Apr 2012, Vladimir.Marek at oracle.com wrote:
> From: Vladimir Marek 
>
>
> Signed-off-by: Vladimir Marek 
> ---
>  lib/database.cc |2 +-
>  lib/message.cc  |2 +-
>  lib/thread.cc   |2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/database.cc b/lib/database.cc
> index 16c4354..3c82632 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1361,7 +1361,7 @@ _resolve_message_id_to_thread_id (notmuch_database_t 
> *notmuch,
>   return status;
>  
>  if (message) {
> - *thread_id_ret = talloc_steal (ctx,
> + *thread_id_ret = (const char*)talloc_steal (ctx,
>  notmuch_message_get_thread_id (message));
>  
>   notmuch_message_destroy (message);
> diff --git a/lib/message.cc b/lib/message.cc
> index 0075425..d56d442 100644
> --- a/lib/message.cc
> +++ b/lib/message.cc
> @@ -220,7 +220,7 @@ _notmuch_message_create_for_message_id 
> (notmuch_database_t *notmuch,
>   
> message_id,
>   
> );
>  if (message)
> - return talloc_steal (notmuch, message);
> + return (notmuch_message_t*) talloc_steal (notmuch, message);
>  else if (*status_ret)
>   return NULL;
>  
> diff --git a/lib/thread.cc b/lib/thread.cc
> index e976d64..d41ff3e 100644
> --- a/lib/thread.cc
> +++ b/lib/thread.cc
> @@ -225,7 +225,7 @@ _thread_add_message (notmuch_thread_t *thread,
>  char *clean_author;
>  
>  _notmuch_message_list_add_message (thread->message_list,
> -talloc_steal (thread, message));
> +(_notmuch_message*)talloc_steal (thread, 
> message));
>  thread->total_messages++;
>  
>  g_hash_table_insert (thread->message_hash,
> -- 
> 1.7.3.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

incrontab?

[David Belohrad]

Hi Adam,

interestingly, your 'G' short-cut hint works out of the box! What
happens is, that when one presses 'G', this invokes
notmuch-hello-poll-and-update. This function calls 'notmuch-poll',
which does exactly what I want. I.e. it runs 'notmuch new' if no polling
script is specified. In my case however this invokes 'remote-notmuch
new' which asks notmuch installed at the server to tag new
emails. Lovely. (footnote: It suits me excellently because I'm not
seeking for 'mail push' service and rather read my emails whenever I
decide to do and not whenever an email arrives - this is why I consider
not calling notmuch-poll before every invocation of (notmuch) not as a
bug, but just minor annoyance which can be tweaked away if desired)


There is just one slightly weird thing. This is when 'notmuch' is
opened, the focus goes directly to search button instead of 'inbox'
messages (or something else), which is imho more interesting than going into 
search. Because
at first what one wants to do is to look into new emails. Another
disadvantage of going directly into search box is, that all shortcuts
get inhibited. Is there any way how to set default focus to something
else? 

thanks a lot

david


Adam Wolfe Gordon  writes:

> Hi David,
>
> On Thu, Apr 12, 2012 at 02:25, David Belohrad  wrote:
>> is somebody using incrontab to issue 'notmuch new'? I've tried but with
>> only partial success. I have setup incrotab to run 'notmuch new' when
>> something changes in my Maildir. However it is not
>> reliable. E.g. sometimes it works out of the box, sometimes it seems
>> that 'notmuch new' is simply not invoked at all even if I see in
>> /var/log/mail.log, that a new mail was delivered correctly to the
>> folder. Anyone really uses this setup?
>
> I don't use incrontab, but I do use my own inotify-based script for
> updating notmuch: https://gist.github.com/1952483 . I haven't had any
> trouble with it.
>
>> I have reverted back to crontab to issue 'notmuch new' every 5
>> minutes. And frankly speaking, I'm rather thinking to run this command
>> from emacs directly everytime I either start notmuch, or refresh view
>> using '=' on notmuch-hello buffer.
>
> You could probably do this with notmuch-hello-refresh-hook, but it
> will be a bit tricky: the hook is executed after the notmuch-hello
> buffer is refreshed, so you'd have to have it refresh after notmuch
> new completes, without running the hook infinitely.
>
> A better approach might be to use advice. Something like (completely 
> untested):
>
> (defadvice notmuch-hello-update (before notmuch-new) (call-process
> "notmuch" nil nil nil "new"))
>
> Hope that helps,
> -- Adam

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

[Tomi Ollila]

On Sun, Apr 15 2012, Jameson Graef Rollins  
wrote:

> On Sun, Apr 15 2012, Mark Walters  wrote:
>> This patch is trivially correct regardless of the rest of the
>> series. 
>>
>> I think the rest of the series (which provides keybindings for
>> adding/removing the delete tag to messages/threads) is worthwhile
>> particularly now the exclude stuff is fairly complete (feedback at the
>> time looked positive).
>
> Sorry, I wish I could have purged all of these series from the list.
> After a very protracted discussion on the topic it was decided that
> notmuch will not support any delete tagging operations.  Users who wish
> to do so can add support on their own:
>
>   id:"87sjgk2xzf.fsf at servo.finestructure.net"
>   http://notmuchmail.org/excluding/  
>
> I highly recommend *not* re-starting this discussion.  There is no
> solution that will satisfy everyone.  Just let it be.  Move on.  Nothing
> to see here.  These are not the tags you're looking for...

id:"1326826969-23545-1-git-send-email-jrollins at finestructure.net"

Does just "delete" -> "deleted" change: the only question I have left
is that should that be left as is, this change made, or just drop
the "delete" coloring altogether ?

>
> jamie.

Tomi

[PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello

[Jani Nikula]

Hi Austin, id:"1330811724-30901-1-git-send-email-jani at nikula.org" :)

Mark had a valid point about ordering within groups, which I didn't
follow up on, but this is a necessary intermediate step in the right
direction no matter what. I don't care whose patches get merged, but
let's merge the change.

Jani.


On Sun, 15 Apr 2012 22:57:36 -0400, Austin Clements  wrote:
> ---
>  emacs/notmuch-hello.el |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 71d37b8..f10d98d 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -226,7 +226,7 @@ by an additional filter query. Similarly, the count of 
> messages
>  displayed next to the buttons can be generated by applying a
>  different filter to the tag query. These filters are also
>  supported for \"Customized queries section\" items."
> -  :group 'notmuch
> +  :group 'notmuch-hello
>:type
>'(repeat
>  (choice (function-item notmuch-hello-insert-header)
> -- 
> 1.7.9.1
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

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

[Tomi Ollila]

On Mon, Apr 16 2012, Jameson Graef Rollins  
wrote:

> On Sun, Apr 15 2012, Tomi Ollila  wrote:
>> id:"1326826969-23545-1-git-send-email-jrollins at finestructure.net"
>>
>> Does just "delete" -> "deleted" change: the only question I have left
>> is that should that be left as is, this change made, or just drop
>> the "delete" coloring altogether ?
>
> Sorry, yes, I suppose this patch should still be applied.  Excludes for
> "deleted" are the default, I believe, so if we are going to refer to it
> in documentation we should probably be consistent.

That said, the following change in nmbug repository

D1326826969-23545-1-git-send-email-jrollins at finestructure.net 
needs-review
A1326826969-23545-1-git-send-email-jrollins at finestructure.net trivial

pushed.

Tomi

>
> On Sun, Apr 15 2012, Jameson Graef Rollins  
> wrote:
>> On Sun, Apr 15 2012, Mark Walters  wrote:
>>> I think the rest of the series (which provides keybindings for
>>> adding/removing the delete tag to messages/threads) is worthwhile
>>> particularly now the exclude stuff is fairly complete (feedback at the
>>> time looked positive).
>>
>> Sorry, I wish I could have purged all of these series from the list.
>> After a very protracted discussion on the topic it was decided that
>> notmuch will not support any delete tagging operations.  Users who wish
>> to do so can add support on their own:
>
> I think my reaction here was a little strong.  I'm not remembering how I
> got the impression that there was more opposition to adding delete
> keybindings than there was support.  I suppose now that excludes work so
> well one (not me) might consider revisiting the issue.
>
> jamie.
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello

[Mark Walters]

On Mon, 16 Apr 2012, Jani Nikula  wrote:
> Hi Austin, id:"1330811724-30901-1-git-send-email-jani at nikula.org" :)
>
> Mark had a valid point about ordering within groups, which I didn't
> follow up on, but this is a necessary intermediate step in the right
> direction no matter what. I don't care whose patches get merged, but
> let's merge the change.
>
> Jani.

I complete agree: let's push one of these (and sorry for holding up your
original patch!)

Best wishes

Mark

>
>
> On Sun, 15 Apr 2012 22:57:36 -0400, Austin Clements  
> wrote:
>> ---
>>  emacs/notmuch-hello.el |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
>> index 71d37b8..f10d98d 100644
>> --- a/emacs/notmuch-hello.el
>> +++ b/emacs/notmuch-hello.el
>> @@ -226,7 +226,7 @@ by an additional filter query. Similarly, the count of 
>> messages
>>  displayed next to the buttons can be generated by applying a
>>  different filter to the tag query. These filters are also
>>  supported for \"Customized queries section\" items."
>> -  :group 'notmuch
>> +  :group 'notmuch-hello
>>:type
>>'(repeat
>>  (choice (function-item notmuch-hello-insert-header)
>> -- 
>> 1.7.9.1
>> 
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

.. regarding opening the attached files ...

[David Belohrad]

Dear Experts, 
could someone give me a hint:

I receive an email with attachment. It says it is a pdf, e.g. like this:

 [ Ultra_Low_Noise_AC_Beam_Transformer2.pdf: application/pdf ]

when I click on it, I would assume, that it opens the file using
'default' application, which is - when looking into file associations -
okular.

Instead, it opens a dialog box to save the attachment first. This is not
really desired.

Is there any way how to change it? It seems that is does it will all
attachments, not only pdf. Regardless of whether correct file
association is made in the KDE.

thanks a lot


-- 
.david.

.. regarding opening the attached files ...

[Mark Walters]

On Mon, 16 Apr 2012, David Belohrad  wrote:
> Dear Experts, 
> could someone give me a hint:
>
> I receive an email with attachment. It says it is a pdf, e.g. like this:
>
>  [ Ultra_Low_Noise_AC_Beam_Transformer2.pdf: application/pdf ]
>
> when I click on it, I would assume, that it opens the file using
> 'default' application, which is - when looking into file associations -
> okular.
>
> Instead, it opens a dialog box to save the attachment first. This is not
> really desired.
>
> Is there any way how to change it? It seems that is does it will all
> attachments, not only pdf. Regardless of whether correct file
> association is made in the KDE.

Hi

it is customizable under M-x customize-group notmuch -> notmuch-show ->
Notmuch Show Part Button Default Action:

The "view" option  uses the mailcap entry to open the attachment.

Best wishes

Mark

[PATCH] configure: test shell parameter substring processing and possibly exec one

[Tomi Ollila]

configure script uses parameter substring extensively. It is Posix shell
feature. Original Bourne shell does not have such features. Some systems
still ships such shells as /bin/sh (for compatibility reasons -- shell
scripts written on those platforms are expected to work in 1990's systems...)

To tackle this situation the beginning of configure attemts to do a silent
parameter substitution in a subshell; in case this fails the subshell exits
with nonzero value which is easy to detect.

The || constructs are used twice. The first one is used as Bourne shell
chokes on 'if ! ... ' construct (and if ...; then :; else do_things; fi
looks stupid). The second one(liner) takes care of the possible future
'set -eu' in the beginning of this script.
---

This patch obsoletes id:"133395-10469-2-git-send-email-Vladimir.Marek at 
oracle.com"

 configure |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 71981b7..06fbeff 100755
--- a/configure
+++ b/configure
@@ -1,5 +1,19 @@
 #! /bin/sh

+# Test whether this sh is capable of parameter substring processing.
+# If not, attempt to locate and launch one which probably can.
+( option=option=value; : ${option#*=} ) 2>/dev/null || {
+if test x"${_NOTMUCH_CONFIGURE-}" = x ; then
+   NOTMUCH_CONFIGURE=1; export _NOTMUCH_CONFIGURE
+   for x in /bin/ksh /bin/bash /usr/bin/bash
+   do test ! -x "$x" || exec "$x" "$0" "$@"
+   done
+fi
+echo "Cannot find compatible shell to execute '$0'" >&2
+exit 1
+}
+unset _NOTMUCH_CONFIGURE
+
 # Store original IFS value so it can be changed (and restored) in many places.
 readonly DEFAULT_IFS=$IFS

-- 
1.7.8.2

.. regarding opening the attached files ...

[Jameson Graef Rollins]

On Mon, Apr 16 2012, Mark Walters  wrote:
> On Mon, 16 Apr 2012, David Belohrad  wrote:
>> I receive an email with attachment. It says it is a pdf, e.g. like this:
>>
>>  [ Ultra_Low_Noise_AC_Beam_Transformer2.pdf: application/pdf ]
>>
>> when I click on it, I would assume, that it opens the file using
>> 'default' application, which is - when looking into file associations -
>> okular.
...
> it is customizable under M-x customize-group notmuch -> notmuch-show ->
> Notmuch Show Part Button Default Action:
>
> The "view" option  uses the mailcap entry to open the attachment.

Also, when the cursor is on the button you can hit 'o' to open with
default mailcap app, 's' to save, and 'v' to view with a specified app.

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/20120416/03755d38/attachment.pgp>

[PATCH] Add a new.filename_tags option

[Neil Roberts]

This option is similar to the existing new.tags option except that it
is instead used when a new filename is encountered for an existing
message.

This can be used to do post-processing based on the filenames that a
message has. For example, in my setup I use maildrop to filter the
messages in to maildirs and then I have an extra script that runs to
add the tags based on which folders maildrop put the message in. The
script only looks at messages that have the 'inbox' tag and then
removes the tag after processing. This works fine except sometimes I
will get a message twice for example if I am CC'd in a message from a
mailing list. In that case I want the message to be tagged twice, once
to indicate it was sent directly to me and once to indicate it was
sent to the mailing list. If one of these messages is delayed then I
can end up processing the message once and removing the inbox tag.
When the second message is finally received it would previously not
get processed again so I would lose the second tag. With this patch I
can configure it to re-add the inbox tag in this case to force it to
reconsider the tags.
---
 man/man1/notmuch-config.1 |8 
 notmuch-client.h  |9 +
 notmuch-config.c  |   34 ++
 notmuch-new.c |7 +++
 4 files changed, 58 insertions(+), 0 deletions(-)

diff --git a/man/man1/notmuch-config.1 b/man/man1/notmuch-config.1
index 395cb9c..caf20b4 100644
--- a/man/man1/notmuch-config.1
+++ b/man/man1/notmuch-config.1
@@ -74,6 +74,14 @@ A list of tags that will be added to all messages 
incorporated by

 .RS 4
 .TP 4
+.B new.filename_tags
+A list of tags that will be added to any message when a new filename
+is encountered for it during
+.BR "notmuch new".
+.RE
+
+.RS 4
+.TP 4
 .B new.ignore
 A list of file and directory names, without path, that will not be
 searched for messages by
diff --git a/notmuch-client.h b/notmuch-client.h
index 19b7f01..55bcef4 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -238,6 +238,15 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 size_t length);

 const char **
+notmuch_config_get_new_filename_tags (notmuch_config_t *config,
+ size_t *length);
+
+void
+notmuch_config_set_new_filename_tags (notmuch_config_t *config,
+ const char *new_tags[],
+ size_t length);
+
+const char **
 notmuch_config_get_new_ignore (notmuch_config_t *config,
   size_t *length);

diff --git a/notmuch-config.c b/notmuch-config.c
index e9b2750..acbc08d 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -111,6 +111,8 @@ struct _notmuch_config {
 size_t user_other_email_length;
 const char **new_tags;
 size_t new_tags_length;
+const char **new_filename_tags;
+size_t new_filename_tags_length;
 const char **new_ignore;
 size_t new_ignore_length;
 notmuch_bool_t maildir_synchronize_flags;
@@ -272,6 +274,8 @@ notmuch_config_open (void *ctx,
 config->user_other_email_length = 0;
 config->new_tags = NULL;
 config->new_tags_length = 0;
+config->new_filename_tags = NULL;
+config->new_filename_tags_length = 0;
 config->new_ignore = NULL;
 config->new_ignore_length = 0;
 config->maildir_synchronize_flags = TRUE;
@@ -371,6 +375,10 @@ notmuch_config_open (void *ctx,
notmuch_config_set_new_tags (config, tags, 2);
 }

+if (notmuch_config_get_new_filename_tags (config, ) == NULL) {
+   notmuch_config_set_new_filename_tags (config, NULL, 0);
+}
+
 if (notmuch_config_get_new_ignore (config, ) == NULL) {
notmuch_config_set_new_ignore (config, NULL, 0);
 }
@@ -624,6 +632,16 @@ notmuch_config_get_new_tags (notmuch_config_t *config,   
size_t *length)
 }

 const char **
+notmuch_config_get_new_filename_tags (notmuch_config_t *config,
+ size_t *length)
+{
+return _config_get_list (config, "new", "filename_tags",
+&(config->new_filename_tags),
+&(config->new_filename_tags_length),
+length);
+}
+
+const char **
 notmuch_config_get_new_ignore (notmuch_config_t *config, size_t *length)
 {
 return _config_get_list (config, "new", "ignore",
@@ -650,6 +668,15 @@ notmuch_config_set_new_tags (notmuch_config_t *config,
 }

 void
+notmuch_config_set_new_filename_tags (notmuch_config_t *config,
+ const char *list[],
+ size_t length)
+{
+_config_set_list (config, "new", "filename_tags", list, length,
+ &(config->new_filename_tags));
+}
+
+void
 notmuch_config_set_new_ignore (notmuch_config_t *config,
   const char *list[],
   size_t length)
@@ -731,6 +758,13 @@ 

[PATCH] emacs: Put notmuch-hello-sections in custom group notmuch-hello

[Austin Clements]

Quoth Jani Nikula on Apr 16 at  6:58 am:
> Hi Austin, id:"1330811724-30901-1-git-send-email-jani at nikula.org" :)
> 
> Mark had a valid point about ordering within groups, which I didn't
> follow up on, but this is a necessary intermediate step in the right
> direction no matter what. I don't care whose patches get merged, but
> let's merge the change.

Ah, indeed!  If only I had an MUA that let me easily search my mail...

The order of the customs is just the order they're listed in defgroup
(currently we don't pass any to defgroup) followed by the order Emacs
evaluates the defcustoms in (defcustom -> custom-handle-keyword ->
custom-add-to-group).  We could use defgroup is put really important
ones at the top if we want.

[PATCH 1/3] new: Consistently treat fatal errors as fatal

[Mark Walters]

On Mon, 27 Feb 2012, Austin Clements  wrote:
> Previously, fatal errors in add_files_recursive were not treated as
> fatal by its callers (including itself!) and add_files_recursive
> sometimes returned errors on non-fatal conditions.  This makes
> add_files_recursive errors consistently fatal and updates all callers
> to treat them as fatal.

Hi I have attempted to review this but am feeling a little out of my
depth. This patch seems fine except for one thing I am unsure about:

> ---
>  notmuch-new.c |   13 -
>  1 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/notmuch-new.c b/notmuch-new.c
> index 4f13535..bd9786a 100644
> --- a/notmuch-new.c
> +++ b/notmuch-new.c
> @@ -308,7 +308,6 @@ add_files_recursive (notmuch_database_t *notmuch,
>  if (num_fs_entries == -1) {
>   fprintf (stderr, "Error opening directory %s: %s\n",
>path, strerror (errno));
> - ret = NOTMUCH_STATUS_FILE_ERROR;
>   goto DONE;
>  }
>  

If I understand this, then this change makes a failure to open a
directory non-fatal. In the comment before the function it says

 * Also, we don't immediately act on file/directory removal since we
 * must ensure that in the case of a rename that the new filename is
 * added before the old filename is removed, (so that no information
 * is lost from the database).

I am  worried that we could fail to find some files because of the
file error above, and then we delete them from the database. Maybe this
could only happen if those emails have just been moved to this
file-error directory?

Best wishes

Mark

> @@ -351,8 +350,10 @@ add_files_recursive (notmuch_database_t *notmuch,
>  
>   next = talloc_asprintf (notmuch, "%s/%s", path, entry->d_name);
>   status = add_files_recursive (notmuch, next, state);
> - if (status && ret == NOTMUCH_STATUS_SUCCESS)
> + if (status) {
>   ret = status;
> + goto DONE;
> + }
>   talloc_free (next);
>   next = NULL;
>  }
> @@ -933,6 +934,8 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
>  }
>  
>  ret = add_files (notmuch, db_path, _files_state);
> +if (ret)
> + goto DONE;
>  
>  gettimeofday (_start, NULL);
>  for (f = add_files_state.removed_files->head; f && !interrupted; f = 
> f->next) {
> @@ -965,6 +968,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
>   }
>  }
>  
> +  DONE:
>  talloc_free (add_files_state.removed_files);
>  talloc_free (add_files_state.removed_directories);
>  talloc_free (add_files_state.directory_mtimes);
> @@ -1012,10 +1016,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
>  
>  printf ("\n");
>  
> -if (ret) {
> - printf ("\nNote: At least one error was encountered: %s\n",
> +if (ret)
> + printf ("\nNote: A fatal error was encountered: %s\n",
>   notmuch_status_to_string (ret));
> -}
>  
>  notmuch_database_close (notmuch);
>  
> -- 
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 2/3] new: Handle fatal errors in remove_filename and _remove_directory

[Mark Walters]

On Mon, 27 Feb 2012, Austin Clements  wrote:
> Previously such errors were simply ignored.  Now they cause an
> immediate cleanup and abort.

This one looks fine except for a minor query.

> ---
>  notmuch-new.c |   24 ++--
>  1 files changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/notmuch-new.c b/notmuch-new.c
> index bd9786a..0cbd479 100644
> --- a/notmuch-new.c
> +++ b/notmuch-new.c
> @@ -780,8 +780,10 @@ remove_filename (notmuch_database_t *notmuch,
>   add_files_state->renamed_messages++;
>   if (add_files_state->synchronize_flags == TRUE)
>   notmuch_message_maildir_flags_to_tags (message);
> -} else
> + status = NOTMUCH_STATUS_SUCCESS;
> +} else if (status == NOTMUCH_STATUS_SUCCESS) {
>   add_files_state->removed_messages++;
> +}
>  notmuch_message_destroy (message);
>  notmuch_database_end_atomic (notmuch);
>  return status;
> @@ -789,12 +791,13 @@ remove_filename (notmuch_database_t *notmuch,
>  
>  /* Recursively remove all filenames from the database referring to
>   * 'path' (or to any of its children). */
> -static void
> +static notmuch_status_t
>  _remove_directory (void *ctx,
>  notmuch_database_t *notmuch,
>  const char *path,
>  add_files_state_t *add_files_state)
>  {
> +notmuch_status_t status;
>  notmuch_directory_t *directory;
>  notmuch_filenames_t *files, *subdirs;
>  char *absolute;
> @@ -807,8 +810,10 @@ _remove_directory (void *ctx,
>  {
>   absolute = talloc_asprintf (ctx, "%s/%s", path,
>   notmuch_filenames_get (files));
> - remove_filename (notmuch, absolute, add_files_state);
> + status = remove_filename (notmuch, absolute, add_files_state);
>   talloc_free (absolute);
> + if (status)
> + return status;
>  }
>  
>  for (subdirs = notmuch_directory_get_child_directories (directory);
> @@ -817,11 +822,14 @@ _remove_directory (void *ctx,
>  {
>   absolute = talloc_asprintf (ctx, "%s/%s", path,
>   notmuch_filenames_get (subdirs));
> - _remove_directory (ctx, notmuch, absolute, add_files_state);
> + status = _remove_directory (ctx, notmuch, absolute, add_files_state);
>   talloc_free (absolute);
> + if (status)
> + return status;
>  }
>  
>  notmuch_directory_destroy (directory);
> +return NOTMUCH_STATUS_SUCCESS;
>  }

In the two "return status" lines above seem to mean we don't call
notmuch_directory_destroy. Does that matter?

The other query is not actually about this patch: just something that
came up when reading it. Should notmuch_database_begin_atomic and
notmuch_database_end_atomic always be paired? One of the (existing)
error cases in remove_filename seems to return without calling end.

Best wishes

Mark

>  int
> @@ -939,7 +947,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
>  
>  gettimeofday (_start, NULL);
>  for (f = add_files_state.removed_files->head; f && !interrupted; f = 
> f->next) {
> - remove_filename (notmuch, f->filename, _files_state);
> + ret = remove_filename (notmuch, f->filename, _files_state);
> + if (ret)
> + goto DONE;
>   if (do_print_progress) {
>   do_print_progress = 0;
>   generic_print_progress ("Cleaned up", "messages",
> @@ -950,7 +960,9 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
>  
>  gettimeofday (_start, NULL);
>  for (f = add_files_state.removed_directories->head, i = 0; f && 
> !interrupted; f = f->next, i++) {
> - _remove_directory (ctx, notmuch, f->filename, _files_state);
> + ret = _remove_directory (ctx, notmuch, f->filename, _files_state);
> + if (ret)
> + goto DONE;
>   if (do_print_progress) {
>   do_print_progress = 0;
>   generic_print_progress ("Cleaned up", "directories",
> -- 
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Add a new.filename_tags option

[Austin Clements]

Quoth Neil Roberts on Apr 16 at  4:01 pm:
> This option is similar to the existing new.tags option except that it
> is instead used when a new filename is encountered for an existing
> message.
> 
> This can be used to do post-processing based on the filenames that a
> message has. For example, in my setup I use maildrop to filter the
> messages in to maildirs and then I have an extra script that runs to
> add the tags based on which folders maildrop put the message in. The
> script only looks at messages that have the 'inbox' tag and then
> removes the tag after processing. This works fine except sometimes I
> will get a message twice for example if I am CC'd in a message from a
> mailing list. In that case I want the message to be tagged twice, once
> to indicate it was sent directly to me and once to indicate it was
> sent to the mailing list. If one of these messages is delayed then I
> can end up processing the message once and removing the inbox tag.
> When the second message is finally received it would previously not
> get processed again so I would lose the second tag. With this patch I
> can configure it to re-add the inbox tag in this case to force it to
> reconsider the tags.

This is an interesting idea.  Unfortunately, the duplicate message-ID
code path you've modified is also used for rename detection.  Hence,
if the user modifies the maildir from another MUA, new.filename_tags
will be applied if the message gets moved to another folder, or even
if they simply change the maildir flags (e.g., marking the message
read).

I'm not sure exactly how your mail flow works, but would it be
possible to use folder-based tagging in your post-new hook to
accomplish this?  E.g.,
  notmuch tag +debian folder:debian
Since this isn't filtered by any delivery tags, it will apply to any
message that winds up in folder:debian, regardless of when it gets
there.

.. regarding opening the attached files ...

[Jeremy Nickurak]

On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
 wrote:
> Also, when the cursor is on the button you can hit 'o' to open with
> default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).

.. regarding opening the attached files ...

[David Belohrad]

Does kde use the same database as gnome? 

Jeremy Nickurak napsal/a:

>On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
> wrote:
>> Also, when the cursor is on the button you can hit 'o' to open with
>> default mailcap app, 's' to save, and 'v' to view with a specified app.
>
>Is there any way of just getting it to ignore mailcap, and send
>everything to xdg-open? It's always bothered me that there are 2
>databases for file associations: mailcap (used only by Emacs, afaict),
>and the xdg/gnome configuration (used by everything else).

.. regarding opening the attached files ...

[Jeremy Nickurak]

No idea. I expect they don't use mailcap though... any KDE users here?

On Mon, Apr 16, 2012 at 10:54, David Belohrad  wrote:
> Does kde use the same database as gnome?
>
> Jeremy Nickurak napsal/a:
>
>>On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
>> wrote:
>>> Also, when the cursor is on the button you can hit 'o' to open with
>>> default mailcap app, 's' to save, and 'v' to view with a specified app.
>>
>>Is there any way of just getting it to ignore mailcap, and send
>>everything to xdg-open? It's always bothered me that there are 2
>>databases for file associations: mailcap (used only by Emacs, afaict),
>>and the xdg/gnome configuration (used by everything else).

.. regarding opening the attached files ...

[Jameson Graef Rollins]

On Mon, Apr 16 2012, Jeremy Nickurak  wrote:
> On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
>  wrote:
>> Also, when the cursor is on the button you can hit 'o' to open with
>> default mailcap app, 's' to save, and 'v' to view with a specified app.
>
> Is there any way of just getting it to ignore mailcap, and send
> everything to xdg-open? It's always bothered me that there are 2
> databases for file associations: mailcap (used only by Emacs, afaict),
> and the xdg/gnome configuration (used by everything else).

Yes, gnome is very obnoxious that way.  mailcap has been around *much*
longer than gnome.  There was really no reason for them to reinvent the
wheel.

Right now 'view part' command runs notmuch-show-view-part function,
which calls mm-display-part.  You might check in mm- config settings to
see if there's anything there you can tweak.

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/20120416/54ccb850/attachment.pgp>

.. regarding opening the attached files ...

[David Belohrad]

Well that's why I'm asking. I'm kde user.  kde has its own handling of file 
associations. I assume that it is different solution than gnome has. Hence one 
might conclude that there is no standard how to provide associations and thus 
emacs one is as good as all the others 



Jeremy Nickurak napsal/a:

>No idea. I expect they don't use mailcap though... any KDE users here?
>
>On Mon, Apr 16, 2012 at 10:54, David Belohrad  wrote:
>> Does kde use the same database as gnome?
>>
>> Jeremy Nickurak napsal/a:
>>
>>>On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
>>> wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.
>>>
>>>Is there any way of just getting it to ignore mailcap, and send
>>>everything to xdg-open? It's always bothered me that there are 2
>>>databases for file associations: mailcap (used only by Emacs, afaict),
>>>and the xdg/gnome configuration (used by everything else).
>
>
>
>-- 
>Jeremy Nickurak -= Email/XMPP: -=?jeremy at nickurak.ca?=-

.. regarding opening the attached files ...

[Justus Winter]

Hi David,

Quoting David Belohrad (2012-04-16 19:38:03)
>[...]

Your mail client is not including any in-reply-to or reference headers
which is *very* annoying for all notmuch users. You can see your mail
thread breaking apart at your replies in the mailing list archive
[0]. And please don't TOFU post to mailing lists.

Thanks,
Justus

0: http://notmuchmail.org/pipermail/notmuch/2012/thread.html#10673

[PATCH] emacs: correct `notmuch-search-mode's docstring wrt `notmuch-search-tag-all'

[Mark Walters]

On Wed, 22 Feb 2012, Pieter Praet  wrote:
> * emacs/notmuch.el (notmuch-search-mode):
>   `notmuch-search-tag-all' currently uses the current query string
>   instead of `notmuch-search-find-thread-id-region-search', which
>   might cause a race condition.

This looks correct and is a significant improvement in wording as it
also correct the fact that * in search view (tag-all) operates on
matching messages not matching threads.

+1

Best wishes

Mark

> ---
>  emacs/notmuch.el |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index f851c6f..0a9fffd 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -435,8 +435,9 @@ (defun notmuch-search-mode ()
>  Pressing \\[notmuch-search-show-thread] on any line displays that thread. 
> The '\\[notmuch-search-add-tag]' and '\\[notmuch-search-remove-tag]'
>  keys can be used to add or remove tags from a thread. The 
> '\\[notmuch-search-archive-thread]' key
>  is a convenience for archiving a thread (removing the \"inbox\"
> -tag). The '\\[notmuch-search-tag-all]' key can be used to add or remove a 
> tag from all
> -threads in the current buffer.
> +tag). The '\\[notmuch-search-tag-all]' key can be used to add and/or remove 
> tags from all
> +messages (as opposed to threads) that match the current query.  Use with 
> caution, as this
> +will also tag matching messages that arrived *after* constructing the buffer.
>  
>  Other useful commands are '\\[notmuch-search-filter]' for filtering the 
> current search
>  based on an additional query string, '\\[notmuch-search-filter-by-tag]' for 
> filtering to include
> -- 
> 1.7.8.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch