Questions from a user new to notmuch
I've been playing with notmuch for a couple days and am impressed so far. The virtual folder concept is taking some getting accustomed to but I see the inherent flexibility. Now, some new user questions. :) 1. Using offlineimap to store mail into a Maildir, is it safe to move an already indexed message to a different folder from some other client? 2. I received a message that was addressed to a distribution group and tried to reply. Because the TO: address is not my address, notmuch fails to guess the proper FROM: address to set. Is there a way to handle this use case? This is with the emacs notmuch client. 3. The emacs news Gnus client supports Gravatar images for contacts, is that something that can be done w/ the emacs notmuch reader? Thanks in advance! -- Kyle Sexton
[PATCH] NEWS: consistent 2-space indentation in new content
Some 0.12 NEWS items descriptions were indented with 3 spaces whereas all other lines are indented with 2 spaces. Brought those escaped lines back in line with others. --- NEWS | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index ed5e3c5..26c775c 100644 --- a/NEWS +++ b/NEWS @@ -67,18 +67,18 @@ Reply to sender Mail store folder/file ignore - A new configuration option, `new.ignore`, lets users specify a - ;-separated list of file and directory names that will not be - searched for messages by "notmuch new". + A new configuration option, `new.ignore`, lets users specify a + ;-separated list of file and directory names that will not be + searched for messages by "notmuch new". - NOTE: *Every* file/directory that goes by one of those names will - be ignored, independent of its depth/location in the mail store. + NOTE: *Every* file/directory that goes by one of those names will + be ignored, independent of its depth/location in the mail store. Unified help and manual pages - The notmuch help command now runs man for the appropriate page. If - you install notmuch somewhere "unusual", you may need to update - MANPATH. + The notmuch help command now runs man for the appropriate page. If + you install notmuch somewhere "unusual", you may need to update + MANPATH. Manual page for notmuch configuration options -- 1.7.8.2
[PATCH] vim: fix regex after "notmuch show" output change
The new field "excluded" was added to the output and made this regex fail.
---
vim/plugin/notmuch.vim |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 21985c7..92e1b50 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -48,7 +48,7 @@ let s:notmuch_defaults = {
\ 'g:notmuch_show_part_end_regexp': ' part}'
,
\ 'g:notmuch_show_marker_regexp':'
\\(message\\|header\\|body\\|attachment\\|part\\)[{}].*$',
\
-\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\)
depth:\([0-9]*\) match:\([0-9]*\) filename:\(.*\)$',
+\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\)
depth:\([0-9]*\) match:\([0-9]*\) excluded:\([[0-9]*\) filename:\(.*\)$',
\ 'g:notmuch_show_tags_regexp': '(\([^)]*\))$'
,
\
\ 'g:notmuch_show_signature_regexp': '^\(-- \?\|_\+\)$'
,
@@ -870,7 +870,8 @@ function! s:NM_cmd_show_parse(inlines)
let msg['id'] = m[1]
let msg['depth'] = m[2]
let msg['match'] = m[3]
-let msg['filename'] = m[4]
+let msg['excluded'] = m[4]
+let msg['filename'] = m[5]
endif
let in_message = 1
--
1.7.9.1
[PATCH 2b/2] configure: print info about required gmime 2.4 or 2.6 versions
In case required gmime (2.4 or 2.6) version if not found print information
about both alternatives (and currently minimal 2.6 version that is needed).
---
This replaces id:"1332281811-24710-2-git-send-email-tomi.ollila at iki.fi"
(having itself id:"1332281811-24710-2b-git-send-email-tomi.ollila at iki.fi")
IMHO this is better and more robust that the other one. trailing space
in $GMIME_24_VERSION causes no problems (that could have been avoided
but the code looks slighty clearer this way.
configure | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 393f859..ace465b 100755
--- a/configure
+++ b/configure
@@ -48,8 +48,13 @@ WITH_EMACS=1
WITH_BASH=1
WITH_ZSH=1
-GMIME_24_VERSION='gmime-2.4'
-GMIME_26_VERSION='gmime-2.6 >= 2.6.7'
+# Compatible GMime versions (with constraints).
+# If using GMime 2.6, we need to have a version >= 2.6.5 to avoid a
+# crypto bug. We need 2.6.7 for permissive "From " header handling.
+GMIME_24_VERSION_CTR=''
+GMIME_24_VERSION="gmime-2.4 $GMIME_24_VERSION_CTR"
+GMIME_26_VERSION_CTR='>= 2.6.7'
+GMIME_26_VERSION="gmime-2.6 $GMIME_26_VERSION_CTR"
WITH_GMIME_VERSIONS="$GMIME_26_VERSION;$GMIME_24_VERSION"
@@ -259,8 +264,6 @@ if [ ${have_xapian} = "0" ]; then
errors=$((errors + 1))
fi
-# If using GMime 2.6, we need to have a version >= 2.6.5 to avoid a
-# crypto bug. We need 2.6.7 for permissive "From " header handling.
printf "Checking for GMime development files... "
have_gmime=0
IFS=';'
@@ -402,7 +405,8 @@ EOF
echo " http://xapian.org/;
fi
if [ $have_gmime -eq 0 ]; then
- echo " GMime 2.4 library (including development files such as headers)"
+ echo " Either GMime 2.4 library" $GMIME_24_VERSION_CTR "or GMime 2.6
library" $GMIME_26_VERSION_CTR
+ echo " (including development files such as headers)"
echo " http://spruce.sourceforge.net/gmime/;
echo
fi
--
1.7.8.2
[PATCH 2b/2] configure: print info about required gmime 2.4 or 2.6 versions
In case required gmime (2.4 or 2.6) version if not found print information
about both alternatives (and currently minimal 2.6 version that is needed).
---
This replaces id:"1332281811-24710-2-git-send-email-tomi.ollila at iki.fi"
(having itself id:"1332281811-24710-2b-git-send-email-tomi.ollila at iki.fi")
IMHO this is better and more robust that the other one. trailing space
in $GMIME_24_VERSION causes no problems (that could have been avoided
but the code looks slighty clearer this way.
configure | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 393f859..ace465b 100755
--- a/configure
+++ b/configure
@@ -48,8 +48,13 @@ WITH_EMACS=1
WITH_BASH=1
WITH_ZSH=1
-GMIME_24_VERSION='gmime-2.4'
-GMIME_26_VERSION='gmime-2.6 >= 2.6.7'
+# Compatible GMime versions (with constraints).
+# If using GMime 2.6, we need to have a version >= 2.6.5 to avoid a
+# crypto bug. We need 2.6.7 for permissive "From " header handling.
+GMIME_24_VERSION_CTR=''
+GMIME_24_VERSION="gmime-2.4 $GMIME_24_VERSION_CTR"
+GMIME_26_VERSION_CTR='>= 2.6.7'
+GMIME_26_VERSION="gmime-2.6 $GMIME_26_VERSION_CTR"
WITH_GMIME_VERSIONS="$GMIME_26_VERSION;$GMIME_24_VERSION"
@@ -259,8 +264,6 @@ if [ ${have_xapian} = "0" ]; then
errors=$((errors + 1))
fi
-# If using GMime 2.6, we need to have a version >= 2.6.5 to avoid a
-# crypto bug. We need 2.6.7 for permissive "From " header handling.
printf "Checking for GMime development files... "
have_gmime=0
IFS=';'
@@ -402,7 +405,8 @@ EOF
echo " http://xapian.org/;
fi
if [ $have_gmime -eq 0 ]; then
- echo " GMime 2.4 library (including development files such as headers)"
+ echo " Either GMime 2.4 library" $GMIME_24_VERSION_CTR "or GMime 2.6
library" $GMIME_26_VERSION_CTR
+ echo " (including development files such as headers)"
echo " http://spruce.sourceforge.net/gmime/;
echo
fi
--
1.7.8.2
[PATCH 1/2] config: Add 'config list' command
On Wed, 21 Mar 2012 09:31:37 +1100, Peter Wang wrote: > Add a command to list all keys in a given configuration section. > > One use is as follows: a MUA may prefer to store data in a central > notmuch configuration file so that the data is accessible across > different machines, e.g. an addressbook. The list command helps > to implement features such as tab completion on the keys. Before getting deeper into implementation it is good to remember that 'notmuch config' is loosely modeled after 'git config'. git config --list outputs somewhat different output. Maybe this command should be like 'notmuch config list-section-keys' > --- > notmuch-config.c | 27 +++ > 1 files changed, 27 insertions(+), 0 deletions(-) Tomi
[PATCH 2/2] man: Document 'config list' command
Document the 'config list' command and its output. --- man/man1/notmuch-config.1 | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/man/man1/notmuch-config.1 b/man/man1/notmuch-config.1 index 395cb9c..b9f81a5 100644 --- a/man/man1/notmuch-config.1 +++ b/man/man1/notmuch-config.1 @@ -9,6 +9,9 @@ notmuch-config \- Access notmuch configuration file. .B notmuch config set .RI "<" section ">.<" item "> [" value " ...]" +.B notmuch config list +.RI "<" section "> + .SH DESCRIPTION The @@ -35,6 +38,15 @@ If no values are provided, the specified configuration item will be removed from the configuration file. .RE +.RS 4 +.TP 4 +.B list +The name of each configuration item in the specified section is +printed to stdout, without the section name prefix. Each is terminated +by a newline character. The output is empty if the section does not +exist. +.RE + The available configuration items are described below. .RS 4 -- 1.7.4.4
[PATCH 1/2] config: Add 'config list' command
Add a command to list all keys in a given configuration section.
One use is as follows: a MUA may prefer to store data in a central
notmuch configuration file so that the data is accessible across
different machines, e.g. an addressbook. The list command helps
to implement features such as tab completion on the keys.
---
notmuch-config.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/notmuch-config.c b/notmuch-config.c
index e9b2750..595cf54 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -799,6 +799,31 @@ notmuch_config_command_set (void *ctx, char *item, int
argc, char *argv[])
return ret;
}
+static int
+notmuch_config_command_list (void *ctx, char *group)
+{
+notmuch_config_t *config;
+char **keys;
+size_t i, length;
+
+config = notmuch_config_open (ctx, NULL, NULL);
+if (config == NULL)
+ return 1;
+
+keys = g_key_file_get_keys (config->key_file,
+ group, , NULL);
+if (keys != NULL) {
+ for (i = 0; i < length; i++)
+ printf ("%s\n", keys[i]);
+
+ free (keys);
+}
+
+notmuch_config_close (config);
+
+return 0;
+}
+
int
notmuch_config_command (void *ctx, int argc, char *argv[])
{
@@ -813,6 +838,8 @@ notmuch_config_command (void *ctx, int argc, char *argv[])
return notmuch_config_command_get (ctx, argv[1]);
else if (strcmp (argv[0], "set") == 0)
return notmuch_config_command_set (ctx, argv[1], argc - 2, argv + 2);
+else if (strcmp (argv[0], "list") == 0)
+ return notmuch_config_command_list (ctx, argv[1]);
fprintf (stderr, "Unrecognized argument for notmuch config: %s\n",
argv[0]);
--
1.7.4.4
[RFC][alot] design decisions
Hi all, with alot 0.3 released, I started thinking seriously about proper? MIME-display and gnupg integration for alot. I have to make a few design decisions here and could really use some informed opinions from more experienced UI developers. My question in particular is: How do I best integrate calls to external mime-handlers into my MVC event driven code? I mostly know how to implement the individual parts but I struggle coming up with a consistent way of organizing it all without compromising my current layout. Background -- Model. Alot uses an abstraction layer over notmuch's thread, message and database objects to make them less fragile and generally behave more OOP-y: You can e.g. directly call message.add_tags(['foo','bar']) and so on. This is made possible by a "DatabaseManager" that maintains centralized and queued access to the notmuch index and deals with notmuch exceptions like a locked index [0]. View/Controler. We use an event-driven interface (urwid.TwistedEventLoop, [1]) that handles user input and maintains a tree of widgets that knows how to render itself. Twisted offers a neat concept of "Deferreds" to organize call- and errbacks that we already make use of [2]. Alot has a "MessageWidget" that displays a single message. We can easily access and parse email messages into MIME-trees (msg.get_email() returns a email.message object; pythons email module allows extensive and RFC compliant dealing with this [3]). We already offer full compatibility with the mailcap protocol to constuct shell commands of external MIME handlers. We know how to call external commands asynchronously; `alot.helper.call_cmd_async` does this and returns a Deferred to which we can connect callback functions. Objective - We want to turn a email.message into nicely rendered text and display it as a widget. Calls to renderers should be done asynchronously, so that displaying large threads does not block the interface unnecessarily. The text representation should be stored in a way that can be incrementally updated for use with message parts decrypted at a later point. Bad Solutions - 1. Current solution: walk the MIME-tree depth-first, use blocking calls to handlers and create a fixed "body" string that is displayed in the widget. A silly and hackish solution that we want to get rid of for obvious reasons. 2. Use a "PartWidget" that is able to display a node in the MIME-tree: Its constructor creates the representation in a RFC compliant way, that is, it decodes 'text/plain' parts, stacks other widgets of the same kind on top of each other for multipart parts or calls external renderer to get a text representation. Cons: * widgets should not be clever and contain/construct any kind of additional info * its hard to update these widgets when a part gets decrypted; * decrypted parts are not available outside the displaying widget, widgets get replaced completely when one rebuilds the buffer (refresh cmd) Pros: * we can use Deferreds relatively painlessly in the ui (as opposed to the db-wrapper) 3. Accumulate rendered text in a tree structure *inside* message-objects and let that massage update the widget that displays it. One could let the widget register some update-callback with the widget that rebuilds the widgets content. These callbacks are called after the external handler has finished and the message- internal text-representation has been updated. Pros: * rendered text/decrypted message parts end up in the message and are available to process and redisplay at will Cons: * the calls to MIME-handlers are dealt with as Deferreds which depend on the twisted event loop and indirectly on urwid. This is exactly the kind of tight coupling I'm trying to avoid: Messages should be independent of the interface. * Messages with multiple externally rendered parts will rebuild their widgets more than once * references to old widgets (replaced e.g. after a buffer rebuild) will be kept, which keeps them from being garbage-collected I'm surely missing an easy and elegant solution here. Any pointers or comments are much appreciated. Thanks, /p [0]: http://alot.readthedocs.org/en/latest/api/database.html [1]: http://excess.org/urwid/ [2]: http://twistedmatrix.com/documents/current/core/howto/defer.html [3]: http://docs.python.org/library/email
[RFC] Split notmuch_database_close into two functions
Hi all, I can confirm that this fixes a rather nasty core dump in a branch of alot that closes and re-opens the database more frequently. /p
[PATCH 7/7] python: wrap and use notmuch_database_destroy as destructor
Adapt the go bindings to the notmuch_database_close split. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- bindings/python/notmuch/database.py | 17 +++-- 1 files changed, 15 insertions(+), 2 deletions(-) diff --git a/bindings/python/notmuch/database.py b/bindings/python/notmuch/database.py index 44d40fd..9a1896b 100644 --- a/bindings/python/notmuch/database.py +++ b/bindings/python/notmuch/database.py @@ -218,9 +218,22 @@ class Database(object): _close.restype = None def close(self): -"""Close and free the notmuch database if needed""" -if self._db is not None: +''' +Closes the notmuch database. +''' +if self._db: self._close(self._db) + +_destroy = nmlib.notmuch_database_destroy +_destroy.argtypes = [NotmuchDatabaseP] +_destroy.restype = None + +def destroy(self): +''' +Destroys the notmuch database. +''' +if self._db: +self._destroy(self._db) self._db = None def __enter__(self): -- 1.7.9.1
[PATCH 6/7] ruby: Use notmuch_database_destroy instead of notmuch_database_close
Adapt the ruby bindings to the notmuch_database_close split. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- bindings/ruby/database.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bindings/ruby/database.c b/bindings/ruby/database.c index 982fd59..ba9a139 100644 --- a/bindings/ruby/database.c +++ b/bindings/ruby/database.c @@ -110,7 +110,7 @@ notmuch_rb_database_close (VALUE self) notmuch_database_t *db; Data_Get_Notmuch_Database (self, db); -notmuch_database_close (db); +notmuch_database_destroy (db); DATA_PTR (self) = NULL; return Qnil; -- 1.7.9.1
[PATCH 5/7] go: Use notmuch_database_destroy instead of notmuch_database_close
Adapt the go bindings to the notmuch_database_close split.
Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de>
---
bindings/go/pkg/notmuch.go |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/bindings/go/pkg/notmuch.go b/bindings/go/pkg/notmuch.go
index c6844ef..d32901d 100644
--- a/bindings/go/pkg/notmuch.go
+++ b/bindings/go/pkg/notmuch.go
@@ -114,7 +114,7 @@ func NewDatabase(path string) *Database {
* An existing notmuch database can be identified by the presence of a
* directory named ".notmuch" below 'path'.
*
- * The caller should call notmuch_database_close when finished with
+ * The caller should call notmuch_database_destroy when finished with
* this database.
*
* In case of any failure, this function returns NULL, (after printing
@@ -140,7 +140,7 @@ func OpenDatabase(path string, mode DatabaseMode) *Database
{
/* Close the given notmuch database, freeing all associated
* resources. See notmuch_database_open. */
func (self *Database) Close() {
- C.notmuch_database_close(self.db)
+ C.notmuch_database_destroy(self.db)
}
/* Return the database path of the given database.
--
1.7.9.1
[PATCH 4/7] Use notmuch_database_destroy instead of notmuch_database_close
Adapt notmuch-deliver to the notmuch_database_close split. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- contrib/notmuch-deliver/src/main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/contrib/notmuch-deliver/src/main.c b/contrib/notmuch-deliver/src/main.c index 6f32f73..37d2919 100644 --- a/contrib/notmuch-deliver/src/main.c +++ b/contrib/notmuch-deliver/src/main.c @@ -455,7 +455,7 @@ main(int argc, char **argv) g_strfreev(opt_rtags); g_free(mail); - notmuch_database_close(db); + notmuch_database_destroy(db); return 0; } -- 1.7.9.1
[PATCH 3/7] Use notmuch_database_destroy instead of notmuch_database_close
Adapt the notmuch binaries source to the notmuch_database_close split. Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- notmuch-count.c |2 +- notmuch-dump.c|2 +- notmuch-new.c |2 +- notmuch-reply.c |2 +- notmuch-restore.c |2 +- notmuch-search.c |2 +- notmuch-show.c|2 +- notmuch-tag.c |2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/notmuch-count.c b/notmuch-count.c index 46b76ae..ade9138 100644 --- a/notmuch-count.c +++ b/notmuch-count.c @@ -100,7 +100,7 @@ notmuch_count_command (void *ctx, int argc, char *argv[]) } notmuch_query_destroy (query); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); return 0; } diff --git a/notmuch-dump.c b/notmuch-dump.c index a735875..71ab0ea 100644 --- a/notmuch-dump.c +++ b/notmuch-dump.c @@ -116,7 +116,7 @@ notmuch_dump_command (unused (void *ctx), int argc, char *argv[]) fclose (output); notmuch_query_destroy (query); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); return 0; } diff --git a/notmuch-new.c b/notmuch-new.c index 4f13535..f078753 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -1017,7 +1017,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[]) notmuch_status_to_string (ret)); } -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); if (run_hooks && !ret && !interrupted) ret = notmuch_run_hook (db_path, "post-new"); diff --git a/notmuch-reply.c b/notmuch-reply.c index e2b6c25..1684b20 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -804,7 +804,7 @@ notmuch_reply_command (void *ctx, int argc, char *argv[]) return 1; notmuch_query_destroy (query); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); if (params.cryptoctx) g_object_unref(params.cryptoctx); diff --git a/notmuch-restore.c b/notmuch-restore.c index 87d9772..60efc52 100644 --- a/notmuch-restore.c +++ b/notmuch-restore.c @@ -184,7 +184,7 @@ notmuch_restore_command (unused (void *ctx), int argc, char *argv[]) if (line) free (line); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); if (input != stdin) fclose (input); diff --git a/notmuch-search.c b/notmuch-search.c index f6061e4..0b41573 100644 --- a/notmuch-search.c +++ b/notmuch-search.c @@ -531,7 +531,7 @@ notmuch_search_command (void *ctx, int argc, char *argv[]) } notmuch_query_destroy (query); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); return ret; } diff --git a/notmuch-show.c b/notmuch-show.c index ff9d427..c2eaa44 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -1119,7 +1119,7 @@ notmuch_show_command (void *ctx, unused (int argc), unused (char *argv[])) notmuch_query_destroy (query); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); if (params.cryptoctx) g_object_unref(params.cryptoctx); diff --git a/notmuch-tag.c b/notmuch-tag.c index 36b9b09..142005c 100644 --- a/notmuch-tag.c +++ b/notmuch-tag.c @@ -227,7 +227,7 @@ notmuch_tag_command (void *ctx, int argc, char *argv[]) } notmuch_query_destroy (query); -notmuch_database_close (notmuch); +notmuch_database_destroy (notmuch); return interrupted; } -- 1.7.9.1
[PATCH 2/7] NEWS: Document the notmuch_database_close split
Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de> --- NEWS | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index ed5e3c5..26fce67 100644 --- a/NEWS +++ b/NEWS @@ -52,6 +52,18 @@ Reply improvement using the JSON format reply body, and it will quote HTML parts if no text/plain parts are available. +Library changes +--- + +API changes + + The function notmuch_database_close has been split into + notmuch_database_close and notmuch_database_destroy. + + This makes it possible for long running programs to close the xapian + database and thus release the lock associated with it without + destroying the data structures obtained from it. + Notmuch 0.12 (2012-03-20) = -- 1.7.9.1
[PATCH 1/7] Split notmuch_database_close into two functions
Formerly notmuch_database_close closed the xapian database and
destroyed the talloc structure associated with the notmuch database
object. Split notmuch_database_close into notmuch_database_close and
notmuch_database_destroy.
This makes it possible for long running programs to close the xapian
database and thus release the lock associated with it without
destroying the data structures obtained from it.
This also makes the api more consistent since every other data
structure has a destructor function.
Signed-off-by: Justus Winter <4winter at informatik.uni-hamburg.de>
---
lib/database.cc | 14 --
lib/notmuch.h | 15 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index 16c4354..2fefcad 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -642,7 +642,7 @@ notmuch_database_open (const char *path,
" read-write mode.\n",
notmuch_path, version, NOTMUCH_DATABASE_VERSION);
notmuch->mode = NOTMUCH_DATABASE_MODE_READ_ONLY;
- notmuch_database_close (notmuch);
+ notmuch_database_destroy (notmuch);
notmuch = NULL;
goto DONE;
}
@@ -702,7 +702,7 @@ notmuch_database_open (const char *path,
} catch (const Xapian::Error ) {
fprintf (stderr, "A Xapian exception occurred opening database: %s\n",
error.get_msg().c_str());
- notmuch_database_close (notmuch);
+ notmuch_database_destroy (notmuch);
notmuch = NULL;
}
@@ -738,9 +738,19 @@ notmuch_database_close (notmuch_database_t *notmuch)
}
delete notmuch->term_gen;
+notmuch->term_gen = NULL;
delete notmuch->query_parser;
+notmuch->query_parser = NULL;
delete notmuch->xapian_db;
+notmuch->xapian_db = NULL;
delete notmuch->value_range_processor;
+notmuch->value_range_processor = NULL;
+}
+
+void
+notmuch_database_destroy (notmuch_database_t *notmuch)
+{
+notmuch_database_close (notmuch);
talloc_free (notmuch);
}
diff --git a/lib/notmuch.h b/lib/notmuch.h
index babd208..6114f36 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -133,7 +133,7 @@ typedef struct _notmuch_filenames notmuch_filenames_t;
*
* After a successful call to notmuch_database_create, the returned
* database will be open so the caller should call
- * notmuch_database_close when finished with it.
+ * notmuch_database_destroy when finished with it.
*
* The database will not yet have any data in it
* (notmuch_database_create itself is a very cheap function). Messages
@@ -165,7 +165,7 @@ typedef enum {
* An existing notmuch database can be identified by the presence of a
* directory named ".notmuch" below 'path'.
*
- * The caller should call notmuch_database_close when finished with
+ * The caller should call notmuch_database_destroy when finished with
* this database.
*
* In case of any failure, this function returns NULL, (after printing
@@ -175,11 +175,18 @@ notmuch_database_t *
notmuch_database_open (const char *path,
notmuch_database_mode_t mode);
-/* Close the given notmuch database, freeing all associated
- * resources. See notmuch_database_open. */
+/* Close the given notmuch database.
+ *
+ * This function is called by notmuch_database_destroyed and can be
+ * called multiple times. */
void
notmuch_database_close (notmuch_database_t *database);
+/* Destroy the notmuch database freeing all associated
+ * resources */
+void
+notmuch_database_destroy (notmuch_database_t *database);
+
/* Return the database path of the given database.
*
* The return value is a string owned by notmuch so should not be
--
1.7.9.1
[RFC] Split notmuch_database_close into two functions
I propose to split the function notmuch_database_close into notmuch_database_close and notmuch_database_destroy so that long running processes like alot can close the database while still using data obtained from queries to that database. I've updated the tools, the go, ruby and python bindings to use notmuch_database_destroy instead of notmuch_database_close to destroy database objects. Cheers, Justus
[PATCH v2 5/6] emacs: simplify `notmuch-show-get-messages-ids{, -search}'
On Fri, 24 Feb 2012 23:30:39 +0100, Pieter Praet wrote: > * emacs/notmuch-show.el > > (notmuch-show-get-messages-ids): > If provided with optional arg SEPARATOR, return a string consisting > of all Message-Id's, separated by SEPARATOR. Also improve original > docstring wrt default return value. > > (notmuch-show-get-messages-ids-search): > Removed, as its functionality is now in `notmuch-show-get-messages-ids'. > > (notmuch-show-tag-all): > Call `notmuch-show-get-messages-ids' with SEPARATOR arg instead of > `notmuch-show-get-messages-ids-search'. > --- > emacs/notmuch-show.el | 18 +- > 1 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el > index 6adbdc0..05606fc 100644 > --- a/emacs/notmuch-show.el > +++ b/emacs/notmuch-show.el > @@ -1339,17 +1339,17 @@ (defun notmuch-show-get-message-id () >"Return the message id of the current message." >(concat "id:\"" (notmuch-show-get-prop :id) "\"")) > > -(defun notmuch-show-get-messages-ids () > - "Return all message ids of messages in the current thread." > +(defun notmuch-show-get-messages-ids ( separator) > + "Return a list of Message-Id's of all messages in the current buffer. > + > +If provided with optional argument SEPARATOR, return a string > +instead, consisting of all Message-Id's separated by SEPARATOR." >(let ((message-ids)) > (notmuch-show-mapc > (lambda () (push (notmuch-show-get-message-id) message-ids))) > -message-ids)) > - > -(defun notmuch-show-get-messages-ids-search () > - "Return a search string for all message ids of messages in the > -current thread." > - (mapconcat 'identity (notmuch-show-get-messages-ids) " or ")) > +(if separator > + (mapconcat 'identity message-ids separator) > + message-ids))) > > ;; dme: Would it make sense to use a macro for many of these? > > @@ -1638,7 +1638,7 @@ (defun notmuch-show-tag-all ( tag-changes) > > TAG-CHANGES is a list of tag operations for `notmuch-tag'." >(interactive (notmuch-read-tag-changes nil notmuch-show-thread-id)) > - (apply 'notmuch-tag (notmuch-show-get-messages-ids-search) tag-changes) > + (apply 'notmuch-tag (notmuch-show-get-messages-ids " or ") tag-changes) >(notmuch-show-mapc > (lambda () > (let* ((current-tags (notmuch-show-get-tags)) Oh and I forgot to add that this patch doesn't seem to apply anymore. MW
[PATCH v2 5/6] emacs: simplify `notmuch-show-get-messages-ids{, -search}'
On Fri, 24 Feb 2012 23:30:39 +0100, Pieter Praet wrote: > * emacs/notmuch-show.el > > (notmuch-show-get-messages-ids): > If provided with optional arg SEPARATOR, return a string consisting > of all Message-Id's, separated by SEPARATOR. Also improve original > docstring wrt default return value. > > (notmuch-show-get-messages-ids-search): > Removed, as its functionality is now in `notmuch-show-get-messages-ids'. > > (notmuch-show-tag-all): > Call `notmuch-show-get-messages-ids' with SEPARATOR arg instead of > `notmuch-show-get-messages-ids-search'. > --- > emacs/notmuch-show.el | 18 +- > 1 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el > index 6adbdc0..05606fc 100644 > --- a/emacs/notmuch-show.el > +++ b/emacs/notmuch-show.el > @@ -1339,17 +1339,17 @@ (defun notmuch-show-get-message-id () >"Return the message id of the current message." >(concat "id:\"" (notmuch-show-get-prop :id) "\"")) > > -(defun notmuch-show-get-messages-ids () > - "Return all message ids of messages in the current thread." > +(defun notmuch-show-get-messages-ids ( separator) > + "Return a list of Message-Id's of all messages in the current buffer. > + > +If provided with optional argument SEPARATOR, return a string > +instead, consisting of all Message-Id's separated by SEPARATOR." >(let ((message-ids)) > (notmuch-show-mapc > (lambda () (push (notmuch-show-get-message-id) message-ids))) > -message-ids)) > - > -(defun notmuch-show-get-messages-ids-search () > - "Return a search string for all message ids of messages in the > -current thread." > - (mapconcat 'identity (notmuch-show-get-messages-ids) " or ")) > +(if separator > + (mapconcat 'identity message-ids separator) > + message-ids))) > > ;; dme: Would it make sense to use a macro for many of these? > > @@ -1638,7 +1638,7 @@ (defun notmuch-show-tag-all ( tag-changes) > > TAG-CHANGES is a list of tag operations for `notmuch-tag'." >(interactive (notmuch-read-tag-changes nil notmuch-show-thread-id)) > - (apply 'notmuch-tag (notmuch-show-get-messages-ids-search) tag-changes) > + (apply 'notmuch-tag (notmuch-show-get-messages-ids " or ") tag-changes) >(notmuch-show-mapc > (lambda () > (let* ((current-tags (notmuch-show-get-tags)) I like the use of separator rather than hard-wiring " or ". My personal preference would be to make that change but keep the two functions separate (my "C"ness makes me like functions that have clear return types!) But I am happy with the change too. Best wishes Mark
[PATCH v2 4/6] emacs: add optional predicate arg to `notmuch-show-mapc'
On Fri, 24 Feb 2012 23:30:38 +0100, Pieter Praet wrote: > * emacs/notmuch-show.el (notmuch-show-mapc): > > If provided with optional argument PREDICATE, only call > FUNCTION if calling PREDICATE returns non-nil. > > Also correct original docstring: 's/thread/buffer/'. > --- > emacs/notmuch-show.el | 14 ++ > 1 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el > index aa9ccee..6adbdc0 100644 > --- a/emacs/notmuch-show.el > +++ b/emacs/notmuch-show.el > @@ -1272,13 +1272,19 @@ (defun notmuch-show-goto-message-previous () > (notmuch-show-move-to-message-top) > t)) > > -(defun notmuch-show-mapc (function) > - "Iterate through all messages in the current thread with > +(defun notmuch-show-mapc (function predicate) > + "Iterate through all messages in the current buffer with > `notmuch-show-goto-message-next' and call FUNCTION for side > -effects." > +effects. > + > +If provided with optional argument PREDICATE, only call > +FUNCTION if calling PREDICATE returns non-nil." >(save-excursion > (goto-char (point-min)) > -(loop do (funcall function) > +(loop do (if predicate > + (if (funcall predicate) > + (funcall function)) > +(funcall function)) > while (notmuch-show-goto-message-next > > ;; Functions relating to the visibility of messages and their The change looks fine. The original function feels a little fragile to me as to what happens if predicate or function move point. Eg what happens if function collapses the message: where does point go, and so where does notmuch-show-goto-message-next go. Is this just my naivete as a lisp beginner? Is there someway of writing it so the user doesn't need to worry about such things? Best wishes Mark (sorry for the duplicate mail: I sent the first message from the wrong address)
[PATCH v2 1/6] test: emacs: new tests "notmuch-show: {add, remove} multiple tags {to, from} single message"
Hi
> * test/emacs:
>
> - Rename subtests "{Add,Remove} tag from notmuch-show view" to
> "notmuch-show: {add,remove} single tag {to,from} single message"
> to be consistent with the following tests.
>
> - New subtest "notmuch-show: add multiple tags to single message":
> `notmuch-show-add-tag' ("+") can add multiple tags to a message.
>
> - New subtest "notmuch-show: remove multiple tags from single message":
> `notmuch-show-remove-tag' ("-") can remove multiple tags from a message.
> ---
> test/emacs | 16 ++--
> 1 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/test/emacs b/test/emacs
> index b74cfa9..ec1dbb0 100755
> --- a/test/emacs
> +++ b/test/emacs
> @@ -112,18 +112,30 @@ test_emacs "(notmuch-search \"$os_x_darwin_thread\")
> output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
> test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
> Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
> unread)"
>
> -test_begin_subtest "Add tag from notmuch-show view"
> +test_begin_subtest "notmuch-show: add single tag to single message"
> test_emacs "(notmuch-show \"$os_x_darwin_thread\")
> (execute-kbd-macro \"+tag-from-show-view\")"
> output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
> test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
> Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
> tag-from-show-view unread)"
>
> -test_begin_subtest "Remove tag from notmuch-show view"
> +test_begin_subtest "notmuch-show: remove single tag from single message"
> test_emacs "(notmuch-show \"$os_x_darwin_thread\")
> (execute-kbd-macro \"-tag-from-show-view\")"
> output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
> test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
> Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
> unread)"
>
> +test_begin_subtest "notmuch-show: add multiple tags to single message"
> +test_emacs "(notmuch-show \"$os_x_darwin_thread\")
> + (execute-kbd-macro \"+tag1-from-show-view +tag2-from-show-view\")"
> +output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
> +test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
> Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
> tag1-from-show-view tag2-from-show-view unread)"
> +
> +test_begin_subtest "notmuch-show: remove multiple tags from single message"
> +test_emacs "(notmuch-show \"$os_x_darwin_thread\")
> + (execute-kbd-macro \"-tag1-from-show-view -tag2-from-show-view\")"
> +output=$(notmuch search $os_x_darwin_thread | notmuch_search_sanitize)
> +test_expect_equal "$output" "thread:XXX 2009-11-18 [4/4] Jjgod Jiang,
> Alexander Botero-Lowry; [notmuch] Mac OS X/Darwin compatibility issues (inbox
> unread)"
> +
> test_begin_subtest "Message with .. in Message-Id:"
> add_message [id]=123..456 at example '[subject]="Message with .. in
> Message-Id"'
> test_emacs '(notmuch-search "id:\"123..456 at example\"")
This looks good to me but I think it would be nice to have an extra test
for adding a tag and removing a tag simultaneously.
Best wishes
Mark
[PATCH 2/2] configure: print info about required gmime 2.4 or 2.6 versions
In case required gmime (2.4 or 2.6) version if not found print information
about both alternatives (and currently minimal 2.6 version that is needed).
---
I'm not entirely happy about the implementation but I would be less happy
to write static message that has the same spesific version information in
second place (third if comments are counted).
configure |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 393f859..43c2436 100755
--- a/configure
+++ b/configure
@@ -402,7 +402,9 @@ EOF
echo " http://xapian.org/;
fi
if [ $have_gmime -eq 0 ]; then
- echo " GMime 2.4 library (including development files such as headers)"
+ _24v=${GMIME_24_VERSION#*2.4} _26v=${GMIME_26_VERSION#*2.6}
+ echo " Either GMime 2.4 library" $_24v "or GMime 2.6 library" $_26v
+ echo " (including development files such as headers)"
echo " http://spruce.sourceforge.net/gmime/;
echo
fi
--
1.7.8.2
[PATCH 1/2] configure: add empty line after each missing component message
Currently whenever message about missing GMime, Glib or talloc is printed the message is 2 lines, component info and its http location in next line. In the future the amount of lines will vary. To ease reading in these cases newline is added after each message. --- configure |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 8cf6f2d..393f859 100755 --- a/configure +++ b/configure @@ -404,17 +404,19 @@ EOF if [ $have_gmime -eq 0 ]; then echo " GMime 2.4 library (including development files such as headers)" echo " http://spruce.sourceforge.net/gmime/; + echo fi if [ $have_glib -eq 0 ]; then echo " Glib library >= 2.22 (including development files such as headers)" echo " http://ftp.gnome.org/pub/gnome/sources/glib/; + echo fi if [ $have_talloc -eq 0 ]; then echo " The talloc library (including development files such as headers)" echo " http://talloc.samba.org/; + echo fi cat <
[RFC][alot] design decisions
Hi all, with alot 0.3 released, I started thinking seriously about proper™ MIME-display and gnupg integration for alot. I have to make a few design decisions here and could really use some informed opinions from more experienced UI developers. My question in particular is: How do I best integrate calls to external mime-handlers into my MVC event driven code? I mostly know how to implement the individual parts but I struggle coming up with a consistent way of organizing it all without compromising my current layout. Background -- Model. Alot uses an abstraction layer over notmuch's thread, message and database objects to make them less fragile and generally behave more OOP-y: You can e.g. directly call message.add_tags(['foo','bar']) and so on. This is made possible by a DatabaseManager that maintains centralized and queued access to the notmuch index and deals with notmuch exceptions like a locked index [0]. View/Controler. We use an event-driven interface (urwid.TwistedEventLoop, [1]) that handles user input and maintains a tree of widgets that knows how to render itself. Twisted offers a neat concept of Deferreds to organize call- and errbacks that we already make use of [2]. Alot has a MessageWidget that displays a single message. We can easily access and parse email messages into MIME-trees (msg.get_email() returns a email.message object; pythons email module allows extensive and RFC compliant dealing with this [3]). We already offer full compatibility with the mailcap protocol to constuct shell commands of external MIME handlers. We know how to call external commands asynchronously; `alot.helper.call_cmd_async` does this and returns a Deferred to which we can connect callback functions. Objective - We want to turn a email.message into nicely rendered text and display it as a widget. Calls to renderers should be done asynchronously, so that displaying large threads does not block the interface unnecessarily. The text representation should be stored in a way that can be incrementally updated for use with message parts decrypted at a later point. Bad Solutions - 1. Current solution: walk the MIME-tree depth-first, use blocking calls to handlers and create a fixed body string that is displayed in the widget. A silly and hackish solution that we want to get rid of for obvious reasons. 2. Use a PartWidget that is able to display a node in the MIME-tree: Its constructor creates the representation in a RFC compliant way, that is, it decodes 'text/plain' parts, stacks other widgets of the same kind on top of each other for multipart parts or calls external renderer to get a text representation. Cons: * widgets should not be clever and contain/construct any kind of additional info * its hard to update these widgets when a part gets decrypted; * decrypted parts are not available outside the displaying widget, widgets get replaced completely when one rebuilds the buffer (refresh cmd) Pros: * we can use Deferreds relatively painlessly in the ui (as opposed to the db-wrapper) 3. Accumulate rendered text in a tree structure *inside* message-objects and let that massage update the widget that displays it. One could let the widget register some update-callback with the widget that rebuilds the widgets content. These callbacks are called after the external handler has finished and the message- internal text-representation has been updated. Pros: * rendered text/decrypted message parts end up in the message and are available to process and redisplay at will Cons: * the calls to MIME-handlers are dealt with as Deferreds which depend on the twisted event loop and indirectly on urwid. This is exactly the kind of tight coupling I'm trying to avoid: Messages should be independent of the interface. * Messages with multiple externally rendered parts will rebuild their widgets more than once * references to old widgets (replaced e.g. after a buffer rebuild) will be kept, which keeps them from being garbage-collected I'm surely missing an easy and elegant solution here. Any pointers or comments are much appreciated. Thanks, /p [0]: http://alot.readthedocs.org/en/latest/api/database.html [1]: http://excess.org/urwid/ [2]: http://twistedmatrix.com/documents/current/core/howto/defer.html [3]: http://docs.python.org/library/email ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] config: Add 'config list' command
On Wed, 21 Mar 2012 09:31:37 +1100, Peter Wang noval...@gmail.com wrote: Add a command to list all keys in a given configuration section. One use is as follows: a MUA may prefer to store data in a central notmuch configuration file so that the data is accessible across different machines, e.g. an addressbook. The list command helps to implement features such as tab completion on the keys. Before getting deeper into implementation it is good to remember that 'notmuch config' is loosely modeled after 'git config'. git config --list outputs somewhat different output. Maybe this command should be like 'notmuch config list-section-keys' --- notmuch-config.c | 27 +++ 1 files changed, 27 insertions(+), 0 deletions(-) Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2b/2] configure: print info about required gmime 2.4 or 2.6 versions
In case required gmime (2.4 or 2.6) version if not found print information
about both alternatives (and currently minimal 2.6 version that is needed).
---
This replaces id:1332281811-24710-2-git-send-email-tomi.oll...@iki.fi
(having itself id:1332281811-24710-2b-git-send-email-tomi.oll...@iki.fi)
IMHO this is better and more robust that the other one. trailing space
in $GMIME_24_VERSION causes no problems (that could have been avoided
but the code looks slighty clearer this way.
configure | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 393f859..ace465b 100755
--- a/configure
+++ b/configure
@@ -48,8 +48,13 @@ WITH_EMACS=1
WITH_BASH=1
WITH_ZSH=1
-GMIME_24_VERSION='gmime-2.4'
-GMIME_26_VERSION='gmime-2.6 = 2.6.7'
+# Compatible GMime versions (with constraints).
+# If using GMime 2.6, we need to have a version = 2.6.5 to avoid a
+# crypto bug. We need 2.6.7 for permissive From header handling.
+GMIME_24_VERSION_CTR=''
+GMIME_24_VERSION=gmime-2.4 $GMIME_24_VERSION_CTR
+GMIME_26_VERSION_CTR='= 2.6.7'
+GMIME_26_VERSION=gmime-2.6 $GMIME_26_VERSION_CTR
WITH_GMIME_VERSIONS=$GMIME_26_VERSION;$GMIME_24_VERSION
@@ -259,8 +264,6 @@ if [ ${have_xapian} = 0 ]; then
errors=$((errors + 1))
fi
-# If using GMime 2.6, we need to have a version = 2.6.5 to avoid a
-# crypto bug. We need 2.6.7 for permissive From header handling.
printf Checking for GMime development files...
have_gmime=0
IFS=';'
@@ -402,7 +405,8 @@ EOF
echo http://xapian.org/;
fi
if [ $have_gmime -eq 0 ]; then
- echo GMime 2.4 library (including development files such as headers)
+ echo Either GMime 2.4 library $GMIME_24_VERSION_CTR or GMime 2.6
library $GMIME_26_VERSION_CTR
+ echo (including development files such as headers)
echo http://spruce.sourceforge.net/gmime/;
echo
fi
--
1.7.8.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2b/2] configure: print info about required gmime 2.4 or 2.6 versions
In case required gmime (2.4 or 2.6) version if not found print information
about both alternatives (and currently minimal 2.6 version that is needed).
---
This replaces id:1332281811-24710-2-git-send-email-tomi.oll...@iki.fi
(having itself id:1332281811-24710-2b-git-send-email-tomi.oll...@iki.fi)
IMHO this is better and more robust that the other one. trailing space
in $GMIME_24_VERSION causes no problems (that could have been avoided
but the code looks slighty clearer this way.
configure | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 393f859..ace465b 100755
--- a/configure
+++ b/configure
@@ -48,8 +48,13 @@ WITH_EMACS=1
WITH_BASH=1
WITH_ZSH=1
-GMIME_24_VERSION='gmime-2.4'
-GMIME_26_VERSION='gmime-2.6 = 2.6.7'
+# Compatible GMime versions (with constraints).
+# If using GMime 2.6, we need to have a version = 2.6.5 to avoid a
+# crypto bug. We need 2.6.7 for permissive From header handling.
+GMIME_24_VERSION_CTR=''
+GMIME_24_VERSION=gmime-2.4 $GMIME_24_VERSION_CTR
+GMIME_26_VERSION_CTR='= 2.6.7'
+GMIME_26_VERSION=gmime-2.6 $GMIME_26_VERSION_CTR
WITH_GMIME_VERSIONS=$GMIME_26_VERSION;$GMIME_24_VERSION
@@ -259,8 +264,6 @@ if [ ${have_xapian} = 0 ]; then
errors=$((errors + 1))
fi
-# If using GMime 2.6, we need to have a version = 2.6.5 to avoid a
-# crypto bug. We need 2.6.7 for permissive From header handling.
printf Checking for GMime development files...
have_gmime=0
IFS=';'
@@ -402,7 +405,8 @@ EOF
echo http://xapian.org/;
fi
if [ $have_gmime -eq 0 ]; then
- echo GMime 2.4 library (including development files such as headers)
+ echo Either GMime 2.4 library $GMIME_24_VERSION_CTR or GMime 2.6
library $GMIME_26_VERSION_CTR
+ echo (including development files such as headers)
echo http://spruce.sourceforge.net/gmime/;
echo
fi
--
1.7.8.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] NEWS: consistent 2-space indentation in new content
Some 0.12 NEWS items descriptions were indented with 3 spaces whereas all other lines are indented with 2 spaces. Brought those escaped lines back in line with others. --- NEWS | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index ed5e3c5..26c775c 100644 --- a/NEWS +++ b/NEWS @@ -67,18 +67,18 @@ Reply to sender Mail store folder/file ignore - A new configuration option, `new.ignore`, lets users specify a - ;-separated list of file and directory names that will not be - searched for messages by notmuch new. + A new configuration option, `new.ignore`, lets users specify a + ;-separated list of file and directory names that will not be + searched for messages by notmuch new. - NOTE: *Every* file/directory that goes by one of those names will - be ignored, independent of its depth/location in the mail store. + NOTE: *Every* file/directory that goes by one of those names will + be ignored, independent of its depth/location in the mail store. Unified help and manual pages - The notmuch help command now runs man for the appropriate page. If - you install notmuch somewhere unusual, you may need to update - MANPATH. + The notmuch help command now runs man for the appropriate page. If + you install notmuch somewhere unusual, you may need to update + MANPATH. Manual page for notmuch configuration options -- 1.7.8.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] config: Add 'config list' command
On Wed, 21 Mar 2012 20:30:43 +0200, Tomi Ollila tomi.oll...@iki.fi wrote: On Wed, 21 Mar 2012 09:31:37 +1100, Peter Wang noval...@gmail.com wrote: Add a command to list all keys in a given configuration section. One use is as follows: a MUA may prefer to store data in a central notmuch configuration file so that the data is accessible across different machines, e.g. an addressbook. The list command helps to implement features such as tab completion on the keys. Before getting deeper into implementation it is good to remember that 'notmuch config' is loosely modeled after 'git config'. git config --list outputs somewhat different output. Maybe this command should be like 'notmuch config list-section-keys' That would be fine. The documentation never mentions keys, only sections and items. The implementation seems to think item == group.key. Peter P.S. In the first patch free() should be g_strfreev(). ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Questions from a user new to notmuch
I've been playing with notmuch for a couple days and am impressed so far. The virtual folder concept is taking some getting accustomed to but I see the inherent flexibility. Now, some new user questions. :) 1. Using offlineimap to store mail into a Maildir, is it safe to move an already indexed message to a different folder from some other client? 2. I received a message that was addressed to a distribution group and tried to reply. Because the TO: address is not my address, notmuch fails to guess the proper FROM: address to set. Is there a way to handle this use case? This is with the emacs notmuch client. 3. The emacs news Gnus client supports Gravatar images for contacts, is that something that can be done w/ the emacs notmuch reader? Thanks in advance! -- Kyle Sexton ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] vim: fix regex after notmuch show output change
The new field excluded was added to the output and made this regex fail.
---
vim/plugin/notmuch.vim |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 21985c7..92e1b50 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -48,7 +48,7 @@ let s:notmuch_defaults = {
\ 'g:notmuch_show_part_end_regexp': ' part}'
,
\ 'g:notmuch_show_marker_regexp':'
\\(message\\|header\\|body\\|attachment\\|part\\)[{}].*$',
\
-\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\)
depth:\([0-9]*\) match:\([0-9]*\) filename:\(.*\)$',
+\ 'g:notmuch_show_message_parse_regexp': '\(id:[^ ]*\)
depth:\([0-9]*\) match:\([0-9]*\) excluded:\([[0-9]*\) filename:\(.*\)$',
\ 'g:notmuch_show_tags_regexp': '(\([^)]*\))$'
,
\
\ 'g:notmuch_show_signature_regexp': '^\(-- \?\|_\+\)$'
,
@@ -870,7 +870,8 @@ function! s:NM_cmd_show_parse(inlines)
let msg['id'] = m[1]
let msg['depth'] = m[2]
let msg['match'] = m[3]
-let msg['filename'] = m[4]
+let msg['excluded'] = m[4]
+let msg['filename'] = m[5]
endif
let in_message = 1
--
1.7.9.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
