[PATCH] emacs: do not unconditionally set mail-user-agent

A user that loads notmuch.el does not necessarily want to user notmuch-message-mode to send mail. --- emacs/notmuch.el | 2 -- 1 file changed, 2 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 6d37c623..3e2713e2 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -1162,8

Re: Emacs: prevent notmuch from tampering with message headers & settings

"Tory S. Anderson" writes: > I send mail with either global C-x m (compose-mail) or from my gnus > buffer when I reply to a message. In both cases, if I happen to have > visited a notmuch search result previously, it has changed my headers > and completion methods. Yeah, over-writing

Re: Emacs: prevent notmuch from tampering with message headers & settings

I send mail with either global C-x m (compose-mail) or from my gnus buffer when I reply to a message. In both cases, if I happen to have visited a notmuch search result previously, it has changed my headers and completion methods. Yeah, over-writing mail-user-agent seems to be the case -- I see

Re: Emacs: prevent notmuch from tampering with message headers & settings

web...@toryanderson.com (Tory S. Anderson) writes: > As an emacs user, I use notmuch for searching and indexing my mail, > and love it. The only problem is that every time I open a message in > notmuch, it overwrites my message configuration for sending mails. In > particular, it seems to change

[PATCH 4/7] CLI: centralize initialization in notmuch_client_init

Initially make sure gmime_filter_reply initialization is thread-safe (assuming notmuch_client_init is only called once). For tidyness, also put talloc initialization in the new function. --- Makefile.local | 1 + gmime-filter-reply.c | 42 +-

[PATCH 5/7] CLI/config: make immutable tables const

Let the compiler help us catch bugs. --- notmuch-config.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/notmuch-config.c b/notmuch-config.c index d9390c4d..3430a3d3 100644 --- a/notmuch-config.c +++ b/notmuch-config.c @@ -32,7 +32,7 @@ static const char

[PATCH 2/7] lib/generate_thread_id: move static buffer to notmuch_database_t

Work towards the goal of concurrent access to different Xapian databases from the same process. --- lib/add-message.cc | 9 +++-- lib/database-private.h | 4 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/lib/add-message.cc b/lib/add-message.cc index

[PATCH 6/7] CLI: make static message strings const

This is both a bit clearer and avoids the possibility of modification. --- notmuch-insert.c | 2 +- notmuch-tag.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/notmuch-insert.c b/notmuch-insert.c index 00c00468..e3d87e4a 100644 --- a/notmuch-insert.c +++

[PATCH 3/7] lib/message: mark flag2tag as const

This table is intended to be immutable --- lib/message.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/message.cc b/lib/message.cc index 42d56acb..7af6ab82 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -68,7 +68,7 @@ struct maildir_flag_tag { }; /* ASCII

[PATCH 1/7] lib: make glib initialization thread-safe

In principle this could be done without depending on C++11 features, but these features should be available since gcc 4.8.1, and this localized usage is easy to replace if it turns out to be problematic for portability. --- lib/Makefile.local| 3 ++- lib/index.cc | 43

static variable cleanup

Both the library and the CLI use a fair amount of static variables. These are an obvious blocker for any kind of thread-safety, even the limited goal of concurrently opening two databases for reading in the same process. This series cleans up some of the low-hanging fruit.

[PATCH 7/7] CLI/notmuch: make immutable tables const

Let the compiler enforce the immutability. --- notmuch.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/notmuch.c b/notmuch.c index 9ca3a4be..d0a94fc2 100644 --- a/notmuch.c +++ b/notmuch.c @@ -139,7 +139,7 @@ notmuch_process_shared_indexing_options