[PATCH 1/1] devel: news2wiki to recognize yyyy-mm-dd or UNRELEASED as release date
The -mm-dd (actually \d\d\d\d-\d\d-\d\d) for a bit more restrictive
(and self-documentative) than the \w\w\w\w-... that used to be there and
UNRELEASED so that developers can test the latest NEWS converted to mdwn
format before submitting NEWS patches.
---
devel/news2wiki.pl | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/devel/news2wiki.pl b/devel/news2wiki.pl
index 8066ba7..d966bab 100755
--- a/devel/news2wiki.pl
+++ b/devel/news2wiki.pl
@@ -32,8 +32,7 @@ while ()
{
warn "$ARGV[0]:$.: tab(s) in line!\n" if /\t/;
warn "$ARGV[0]:$.: trailing whitespace\n" if /\s\s$/;
-# The date part in regex recognizes wip version dates like: (201x-xx-xx).
-if (/^Notmuch\s+(\S+)\s+\((\w\w\w\w-\w\w-\w\w)\)\s*$/) {
+if (/^Notmuch\s+(\S+)\s+\((\d\d\d\d-\d\d-\d\d|UNRELEASED)\)\s*$/) {
# open O... autocloses previously opened file.
open O, '>', "$ARGV[1]/release-$1.mdwn" or die $!;
print "+ release-$1.mdwn...\n";
--
1.9.0
folder and path completely broken in HEAD?
> The trick here is that it's easy to miss people who are happy with > current functionality. Adding functionality to address newly-identified > use cases makes a lot of sense. But removing functionality runs the risk > of only discovering that people were relying on it after the fact, > (Which seems to have happened here). Yes indeed. I think one thing that I, at least, hadn't realised is that people have lots of strange mail layouts often to work around problems in mail agents (notmuch or others) or filesystem limitations etc. >>> The idea of path: is that it's the exact filesystem directory, relative >>> from the maildir root, with an rsync like ** syntax for recursive >>> matching. > > This definition of "path:" seems good. It covers a lot of cases that the > original "folder:" did not and allows precise, predictable control. > >>> Turns out people want folder: to hide maildir implementation >>> details like cur and new. > > Which is something that "folder:" always did. > >>> These are not compatible, or you need to add a syntax that's not easy >>> or discoverable. > > OK. So I won't argue that we don't need two different syntaxes here. But > I will continue to discuss a use case that was addressed before and is > no longer. > >> I think many of us would agree, but there were users who wanted to >> distinguish new and cur, and in at least one case, the toplevel as >> well. > > So now, "path:" allows for that, right? > > My concern is not so much that "path:" was added to address new things, > but more than "folder:" was modified in a way that dropped useful > functionality, (beyond just fixing bugs in "folder:" such as the > accidental support of stemming). One possibly perverse remark: it wouldn't surprise me if someone actually used the stemming. I have used folders called old older and oldest and that probably can be excluded by stemming. All I am really saying is that any change we made was going to break some people's setups. >> I think it is unfortunate that we need two variants, but I think they do >> do different things. > > I'll accept that. > > But, while I have heard a good definition of "path:", (see above), I > haven't heard a good one for "folder:" yet. Can you provide that? I think folder:foo/bar means "In the maildir exactly foo/bar" >> Also, I think any single user will find one matches their setup and >> use that one essentially exclusively: > > The current discussion is evidence against that. We have a user of > folder: that can no longer get at the desired functionality, (that used > to exist). Sorry I wasn't trying to suggest that the current setup does everything people want (clearly not!): just answering your question about the differences being confusing. since each user will probably only use one of them they probably become accustomed to its use. Indeed, I think of the choice as being analogous to allowing the user to choose which path scheme they like (so sort of like a customisation): maildir folder based or filesystem path based. >> Indeed, it may be that a third option of roughly a maildir++: search term >> might solve David's use case. > > Or just making "folder:" index each term of a filesytem path like it > used to do. And if that doesn't give sufficient control to some users, > then "path:" is available. We could do this. It might break things for user who are using the new syntax Maybe we could make an initial / match the root of the maildir store. But I think some people will dislike any of the options. > > I've already lost what I would have preferred, (a single syntax for all > use cases---which was lost not to a design problem, but simply the > implementation difficulty of requiring a custom query parser). I really > would not like to see things continue down to have a *third* syntax. So this third syntax would fit with my view of it being a customisation like thing. Best wishes Mark
[Patch v3 0/3] emacs: show: redesign unread/read logic
On Wed, 07 May 2014, David Edmondson wrote: > On Tue, Mar 25 2014, Mark Walters wrote: >> The third patch adds my attempt at a plausible logic. I find it works >> very well: it usually does both what I expect and what I want. > > Whilst I think that the patch is well done, I don't like the resulting > behaviour. That is a personal preference, of course. At the moment it > doesn't seem that there is a way to accept this patch and (optionally) > retain the existing behaviour. Do you have any thoughts on how we might > achieve that? Thanks for looking and for the feedback. I should emphasise to everyone that I would like all feedback whether positive or negative! > I don't have a strong preference for the default behaviour, though I > suspect that something closer to the current behaviour (where a message > is marked seen when it becomes the current message[1]) would better > match user expectation (but this is an opinion, not something founded in > fact). Just for the record I will detail what happens currently and then I have a couple questions about your suggestion. A message is marked read if: 1) if you navigate to a message using n/p (next/prev open message) 2) if you navigate to it using N/P (next/prev message) regardless of whether the message is open or closed. 3) if you go to it using n.s.next-matching-message (not bound by default) whether message is open or closed. 4) when you enter a buffer and notmuch goes to the first open message. but not marked read in cases like: 1) opening a message 2) viewing or entering a message using other notmuch navigation such as notmuch-show-advance and friends (bound to space) 3) viewing or entering a message using arrow keys, page-up page-down, ctrl-v mouse clicks etc Personally, I think marking a closed message read is a bug, and not marking it read when opening it is too (at least in many cases). The other problem with the current approach (in my view) is that if you try to use the navigation commands non-interactively then messages end up being marked read, even if they are never displayed to the user. Linking into the post-command-hook means that this should "just work". Questions: What does it mean for a message to be the current message? Is it just point being in the message? Would you be happy with a message being marked read when point entered the message? That could be done from the post-command-hook infrastructure to fix some of the problems mentioned above. I think that is likely that people will disagree on how they want this to work so I would like to try and make it customisable so I would definitely be interested to see if I can get the behaviour you would like from this infrastructure (or something similar). Best wishes Mark
[PATCH v2] emacs: Add support for saved search accelerators
Extended the saved search definition to allow the inclusion of an accelerator key for the search. Bind 'j' in the common mode map as a leader for such accelerator keys. --- emacs/notmuch-hello.el | 5 - emacs/notmuch-lib.el | 46 ++ 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 3de5238..64d5aa1 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -85,6 +85,7 @@ searches so they still work in customize." (group :format "%v" :inline t (const :format " Query: " :query) (string :format "%v"))) (checklist :inline t :format "%v" +(group :format "%v" :inline t (const :format "Key: " :key) (key-sequence :format "%v")) (group :format "%v" :inline t (const :format "Count-Query: " :count-query) (string :format "%v")) (group :format "%v" :inline t (const :format "" :sort-order) (choice :tag " Sort Order" @@ -101,6 +102,7 @@ a plist. Supported properties are :nameName of the search (required). :query Search to run (required). + :key Optional accelerator key. :count-query Optional extra query to generate the count shown. If not present then the :query property is used. @@ -551,7 +553,8 @@ with `notmuch-hello-query-counts'." (when elem (if (> column-indent 0) (widget-insert (make-string column-indent ? ))) - (let* ((name (plist-get elem :name)) + (let* ((key (plist-get elem :key)) +(name (plist-get elem :name)) (query (plist-get elem :query)) (oldest-first (case (plist-get elem :sort-order) (newest-first nil) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 2941da3..f8c5f96 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -25,6 +25,10 @@ (require 'mm-decode) (require 'cl) +(declare-function notmuch-search "notmuch" ( query oldest-first target-thread target-line continuation)) +(declare-function notmuch-saved-search-get "notmuch-hello" (saved-search field)) +(defvar notmuch-saved-searches) ;; In `notmuch-hello.el'. + (defvar notmuch-command "notmuch" "Command to run the notmuch binary.") @@ -130,6 +134,7 @@ For example, if you wanted to remove an \"inbox\" tag and add an (define-key map "m" 'notmuch-mua-new-mail) (define-key map "=" 'notmuch-refresh-this-buffer) (define-key map "G" 'notmuch-poll-and-refresh-this-buffer) +(define-key map "j" 'notmuch-jump) map) "Keymap shared by all notmuch modes.") @@ -845,6 +850,47 @@ status." (defvar notmuch-show-process-crypto nil) (make-variable-buffer-local 'notmuch-show-process-crypto) +;; Jump key support: + +(defvar notmuch-jump-search nil) +(defun notmuch-jump-map () + (let ((map (make-sparse-keymap)) + help) +(set-keymap-parent map minibuffer-local-map) +(suppress-keymap map) +(dolist (saved-search notmuch-saved-searches) + (let ((key (notmuch-saved-search-get saved-search :key))) + (when key + (define-key map key `(lambda () +(interactive) +(setq notmuch-jump-search ',saved-search) +(exit-minibuffer))) + (push (format "%s: %s" + (propertize key 'face 'minibuffer-prompt) + (notmuch-saved-search-get saved-search :name)) + help +;; Hitting ? displays a quick hint of the accelerators. +(define-key map "?" `(lambda () + (interactive) + (message "%s" + (mapconcat #'identity + ;; Reverse the list so + ;; that elements appear + ;; in the same order as + ;; `notmuch-saved-searches'. + (reverse ',help) + " " +map)) + +(defun notmuch-jump () + "Read a saved search accelerator key and perform the search." + (interactive) + (setq notmuch-jump-search nil) + (read-from-minibuffer "Jump to saved search: " nil (notmuch-jump-map)) + (when notmuch-jump-search +(notmuch-search (notmuch-saved-search-get notmuch-jump-search :query) + (notmuch-saved-search-get notmuch-jump-search :oldest-first + (provide 'notmuch-lib) ;; Local Variables: -- 2.0.0.rc0
[PATCH v2] emacs: Add support for saved search accelerator keys
emacs: Add support for saved search accelerator keys This arose out a conversation in #notmuch and Mark's patch to extend the saved search custom specification based on requirements for an external package (Austin's notmuch-go.el). v2: - Comments from Mark Walters: - Use `notmuch-saved-search-get'. - Use key-sequence rather than string in the custom definition. - Add a ? binding to display the accelerators. - Use the minibuffer-local-map as parent for the new keymap. - Fix external declarations. - Remove the display of the accelerators in notmuch-hello. David Edmondson (1): emacs: Add support for saved search accelerators emacs/notmuch-hello.el | 5 - emacs/notmuch-lib.el | 46 ++ 2 files changed, 50 insertions(+), 1 deletion(-) -- 2.0.0.rc0
[PATCH] emacs: hello: allow arbitrary lisp for generating the count.
(or (plist-get options :filter-count) > + (plist-get options :filter > +"\n" > > (unless (= (call-process-region (point-min) (point-max) notmuch-command > t t nil "count" "--batch") 0) > @@ -515,12 +519,17 @@ (defun notmuch-hello-query-counts (query-list > options) > (mapcar >(lambda (elem) > (let* ((elem-plist (notmuch-hello-saved-search-to-plist elem)) > +(count-query (plist-get elem-plist :count-query)) > (search-query (plist-get elem-plist :query)) > (filtered-query (notmuch-hello-filtered-query > search-query (plist-get options :filter))) > -(message-count (prog1 (read (current-buffer)) > - (forward-line 1 > - (when (and filtered-query (or (plist-get options > :show-empty-searches) (> message-count 0))) > +(message-count (if (functionp count-query) > + (funcall count-query elem-plist) > + (prog1 (read (current-buffer)) > + (forward-line 1) > + (when (and filtered-query (or (plist-get options :show-empty-searches) > + (not (integerp message-count)) > + (> message-count 0))) > (setq elem-plist (plist-put elem-plist :query filtered-query)) > (plist-put elem-plist :count message-count >query-list > @@ -559,7 +568,9 @@ (defun notmuch-hello-insert-buttons (searches) >(otherwise notmuch-search-oldest-first))) >(msg-count (plist-get elem :count))) > (widget-insert (format "%8s " > -(notmuch-hello-nice-number msg-count))) > + (if (stringp msg-count) > +msg-count > + (notmuch-hello-nice-number > msg-count > (widget-create 'push-button > :notify #'notmuch-hello-widget-search > :notmuch-search-terms query > -- > 1.7.10.4 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 310 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140507/bc1cd05b/attachment.pgp>
[PATCH v2 00/10] add insert --must-index option
On Wed, Apr 16 2014, Peter Wang wrote: > Follow up to id:1374365254-13227-1-git-send-email-novalazy at gmail.com > The main changes are to take into account failures during > tagging and flushing of the database. > > I took Jani's patch id:1390152046-6509-1-git-send-email-jani at nikula.org > without modification. > > The soname bump is included in case it is required. I guess it is -- then changing in that file is not enough, lib/notmuch.h needs to have the same change. But, would a MINOR value update work -- anyone who needs only 3.1.0 could also work with 3.2.0... If MINOR update were sufficient then we would not need to add api changes that supports logging (etc.) to this conversation... ... but anyone interested these changes should also take a look of the actual changes... :D Tomi > The python/go/ruby changes are untested. > > > Jani Nikula (1): > lib: add return status to database close and destroy > > Peter Wang (9): > lib: bump soname > python: handle return status of database close and destroy > go: add return status to database close method > ruby: handle return status of database close > cli: refactor insert > cli: indicate insert failure mode in exit status > cli: add insert --must-index option > test: test insert --must-index > man: update insert documentation > > bindings/go/src/notmuch/notmuch.go | 4 +- > bindings/python/notmuch/database.py | 12 ++-- > bindings/ruby/database.c| 4 +- > doc/man1/notmuch-insert.rst | 24 +-- > lib/Makefile.local | 2 +- > lib/database.cc | 30 ++-- > lib/notmuch.h | 15 +++- > notmuch-insert.c| 134 > +--- > test/T070-insert.sh | 32 +++-- > 9 files changed, 176 insertions(+), 81 deletions(-) > > -- > 1.8.4 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 5/5] T360-symbol-hiding: Use nm instead of objdump.
The output of `objdump -t` depends on the format of the object files
which are different across platforms (e.g. Mac OS X). Since we really
just want to filter the symbols in the object file, nm is a more
appropriate tool since it only lists symbols from object files (nm(1))
and has a consistent output format.
Signed-off-by: Charles Celerier
---
test/T360-symbol-hiding.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/T360-symbol-hiding.sh b/test/T360-symbol-hiding.sh
index 9239fc1..21cabca 100755
--- a/test/T360-symbol-hiding.sh
+++ b/test/T360-symbol-hiding.sh
@@ -33,7 +33,7 @@ test_begin_subtest 'checking output'
test_expect_equal "$result" "$output"
test_begin_subtest 'comparing existing to exported symbols'
-objdump -t $TEST_DIRECTORY/../lib/*.o | awk '$4 == ".text" && $6 ~ "^notmuch"
{print $6}' | sort | uniq > ACTUAL
+nm -g $TEST_DIRECTORY/../lib/*.o | sed -n 's/.*\s\+T\s\+_\(notmuch_.*\)/\1/p'
| sort | uniq > ACTUAL
sed -n 's/[[:blank:]]*\(notmuch_[^;]*\);/\1/p' $TEST_DIRECTORY/../notmuch.sym
| sort | uniq > EXPORTED
test_expect_equal_file EXPORTED ACTUAL
--
1.8.5.2 (Apple Git-48)
[PATCH v2 4/5] T360-symbol-hiding: Added code to support testing on Mac OS X.
The Mac OS X platform uses *.dylib object files instead of *.so object
files for linking. Adding the path to notmuch.dylib to the end of
DYLD_FALLBACK_LIBRARY_PATH has a similar effect to adding the path to
notmuch.so to LD_LIBRARY_PATH on most Linux-based platforms (see
dyld(1)).
Signed-off-by: Charles Celerier
---
test/T360-symbol-hiding.sh | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/test/T360-symbol-hiding.sh b/test/T360-symbol-hiding.sh
index 636ec91..9239fc1 100755
--- a/test/T360-symbol-hiding.sh
+++ b/test/T360-symbol-hiding.sh
@@ -12,7 +12,14 @@ test_description='exception symbol hiding'
. ./test-lib.sh
run_test(){
-
result=$(LD_LIBRARY_PATH="$TEST_DIRECTORY/../lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
$TEST_DIRECTORY/symbol-test 2>&1)
+case $(uname -s) in
+Darwin)
+
result=$(DYLD_FALLBACK_LIBRARY_PATH="$TEST_DIRECTORY/../lib${DYLD_FALLBACK_LIBRARY_PATH:+:$DYLD_FALLBACK_LIBRARY_PATH}"
$TEST_DIRECTORY/symbol-test 2>&1)
+;;
+*)
+
result=$(LD_LIBRARY_PATH="$TEST_DIRECTORY/../lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
$TEST_DIRECTORY/symbol-test 2>&1)
+;;
+esac
}
output="A Xapian exception occurred opening database: Couldn't stat
'fakedb/.notmuch/xapian'
--
1.8.5.2 (Apple Git-48)
pkg-config zlib check in 3c13bc
On Tue, May 06 2014, X?c? wrote:
> Dear notmuch,
>
> Although notmuch was configuring fine on FreeBSD before 3c13bc, the pkg-config
> check introduced for zlib does not work. Indeed, zlib is part of the
> base system, and always assumed to be present.
>
> Proposed patch puts platform test before pkg-config checks, and add a
> special case for zlib on FreeBSD. uname -U is used to get (numeric) OS
> version,
> and compared to lowest release where at least zlib 1.2.5.2 was available
> (that?s FreeBSD 9.1, with zlib 1.2.7).
>
> Best,
This line:
if [ $platform = FREEBSD -a `uname -U` -ge 901000 ] ; then
fails on systems where uname does not have -U option
as `uname -U` is executed always...
if [ $platform = FREEBSD ] && [ "`uname -U`" -ge 901000 ] ; then
would work better there...
But, I'd like suggest alternate option to create a test c program
and test whether it compiles (analogous to what there is already
done with many other checks) -- this same would apply to fdatasync()
case too.
If we cared about cross-compilability one could also do
zlib_vernum=$(printf '#include \nZLIB_VERNUM' | gcc -E - | sed -n '$
s/^0x/0x/p')
if [ $((${zlib_vernum:-0})) -ge 4690 ]; then # 4690 == 0x1252
printf "Yes\n"
...
But that would be so inconsistent what we have now
(and possibly fragile?)
> --
> X?c?
Tomi
>>From ca0b168ac01391b4137de504bea2845d39d0fff9 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?X=C4=ABc=C3=B2?=
> Date: Tue, 6 May 2014 12:37:32 -0700
> Subject: [PATCH 1/1] FreeBSD check for zlib version.
>
> ---
> configure | 130
> +-
> 1 file changed, 69 insertions(+), 61 deletions(-)
>
> diff --git a/configure b/configure
> index 9bde2eb..7204812 100755
> --- a/configure
> +++ b/configure
> @@ -270,6 +270,62 @@ EOF
>
> errors=0
>
> +libdir_in_ldconfig=0
> +
> +printf "Checking which platform we are on... "
> +uname=`uname`
> +if [ $uname = "Darwin" ] ; then
> +printf "Mac OS X.\n"
> +platform=MACOSX
> +linker_resolves_library_dependencies=0
> +elif [ $uname = "SunOS" ] ; then
> +printf "Solaris.\n"
> +platform=SOLARIS
> +linker_resolves_library_dependencies=0
> +elif [ $uname = "FreeBSD" ] ; then
> +printf "FreeBSD.\n"
> +platform=FREEBSD
> +linker_resolves_library_dependencies=0
> +elif [ $uname = "OpenBSD" ] ; then
> +printf "OpenBSD.\n"
> +platform=OPENBSD
> +linker_resolves_library_dependencies=0
> +elif [ $uname = "Linux" ] || [ $uname = "GNU" ] ; then
> +printf "$uname\n"
> +platform="$uname"
> +linker_resolves_library_dependencies=1
> +
> +printf "Checking for $libdir_expanded in ldconfig... "
> +ldconfig_paths=$(/sbin/ldconfig -N -X -v 2>/dev/null | sed -n -e
> 's,^\(/.*\):\( (.*)\)\?$,\1,p')
> +# Separate ldconfig_paths only on newline (not on any potential
> +# embedded space characters in any filenames). Note, we use a
> +# literal newline in the source here rather than something like:
> +#
> +#IFS=$(printf '\n')
> +#
> +# because the shell's command substitution deletes any trailing newlines.
> +IFS="
> +"
> +for path in $ldconfig_paths; do
> + if [ "$path" = "$libdir_expanded" ]; then
> + libdir_in_ldconfig=1
> + fi
> +done
> +IFS=$DEFAULT_IFS
> +if [ "$libdir_in_ldconfig" = '0' ]; then
> + printf "No (will set RPATH)\n"
> +else
> + printf "Yes\n"
> +fi
> +else
> +printf "Unknown.\n"
> +cat < +
> +*** Warning: Unknown platform. Notmuch might or might not build correctly.
> +
> +EOF
> +fi
> +
> if pkg-config --version > /dev/null 2>&1; then
> have_pkg_config=1
> else
> @@ -342,14 +398,22 @@ fi
>
> printf "Checking for zlib (>= 1.2.5.2)... "
> have_zlib=0
> -if pkg-config --atleast-version=1.2.5.2 zlib; then
> +# zlib is part of base in FreeBSD. version 9.1 included 1.2.7
> +if [ $platform = FREEBSD -a `uname -U` -ge 901000 ] ; then
> printf "Yes.\n"
> have_zlib=1
> -zlib_cflags=$(pkg-config --cflags zlib)
> -zlib_ldflags=$(pkg-config --libs zlib)
> +zlib_cflags=
> +zlib_ldflags=-lz
> else
> -printf "No.\n"
> -errors=$((errors + 1))
> +if pkg-config --atleast-version=1.2.5.2 zlib; then
> +printf "Yes.\n"
> +have_zlib=1
> +zlib_cflags=$(pkg-config --cflags zlib)
> +zlib_ldflags=$(pkg-config --libs zlib)
> +else
> +printf "No.\n"
> +errors=$((errors + 1))
> +fi
> fi
>
> printf "Checking for talloc development files... "
> @@ -427,62 +491,6 @@ else
> fi
> fi
>
> -libdir_in_ldconfig=0
> -
> -printf "Checking which platform we are on... "
> -uname=`uname`
> -if [ $uname = "Darwin" ] ; then
> -printf "Mac OS X.\n"
> -platform=MACOSX
> -linker_resolves_library_dependencies=0
> -elif [ $uname = "SunOS" ] ; then
> -printf "Solaris.\n"
> -platform=SOLARIS
> -linker_resolves_library_dependencies=0
> -elif [ $uname =
GMAIL tag sync arriving in next branch in Offlineimap
Recently, gmail tag sync was discussed here, and it seems something is happening in Offlineimap: patches implementing synching of gmail tags to X-Labels have been applied in the next branch and announced on the Offline mailing list. Cheers, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpBplsoDZkRW.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Linux-only fdatasync() in 3c13bc
Xīcò x...@atelo.org writes: Also, commit 3c13bc introduced a call to fdatasync() which is not available on FreeBSD, and probably not either on MacOS at least. fdatasync is POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html -- regards, kushal pgpIDJi7crZ95.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] emacs: Add support for saved search accelerator keys
emacs: Add support for saved search accelerator keys This arose out a conversation in #notmuch and Mark's patch to extend the saved search custom specification based on requirements for an external package (Austin's notmuch-go.el). v2: - Comments from Mark Walters: - Use `notmuch-saved-search-get'. - Use key-sequence rather than string in the custom definition. - Add a ? binding to display the accelerators. - Use the minibuffer-local-map as parent for the new keymap. - Fix external declarations. - Remove the display of the accelerators in notmuch-hello. David Edmondson (1): emacs: Add support for saved search accelerators emacs/notmuch-hello.el | 5 - emacs/notmuch-lib.el | 46 ++ 2 files changed, 50 insertions(+), 1 deletion(-) -- 2.0.0.rc0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] emacs: Add support for saved search accelerators
Extended the saved search definition to allow the inclusion of an accelerator key for the search. Bind 'j' in the common mode map as a leader for such accelerator keys. --- emacs/notmuch-hello.el | 5 - emacs/notmuch-lib.el | 46 ++ 2 files changed, 50 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 3de5238..64d5aa1 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -85,6 +85,7 @@ searches so they still work in customize. (group :format %v :inline t (const :format Query: :query) (string :format %v))) (checklist :inline t :format %v +(group :format %v :inline t (const :format Key: :key) (key-sequence :format %v)) (group :format %v :inline t (const :format Count-Query: :count-query) (string :format %v)) (group :format %v :inline t (const :format :sort-order) (choice :tag Sort Order @@ -101,6 +102,7 @@ a plist. Supported properties are :nameName of the search (required). :query Search to run (required). + :key Optional accelerator key. :count-query Optional extra query to generate the count shown. If not present then the :query property is used. @@ -551,7 +553,8 @@ with `notmuch-hello-query-counts'. (when elem (if ( column-indent 0) (widget-insert (make-string column-indent ? ))) - (let* ((name (plist-get elem :name)) + (let* ((key (plist-get elem :key)) +(name (plist-get elem :name)) (query (plist-get elem :query)) (oldest-first (case (plist-get elem :sort-order) (newest-first nil) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 2941da3..f8c5f96 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -25,6 +25,10 @@ (require 'mm-decode) (require 'cl) +(declare-function notmuch-search notmuch (optional query oldest-first target-thread target-line continuation)) +(declare-function notmuch-saved-search-get notmuch-hello (saved-search field)) +(defvar notmuch-saved-searches) ;; In `notmuch-hello.el'. + (defvar notmuch-command notmuch Command to run the notmuch binary.) @@ -130,6 +134,7 @@ For example, if you wanted to remove an \inbox\ tag and add an (define-key map m 'notmuch-mua-new-mail) (define-key map = 'notmuch-refresh-this-buffer) (define-key map G 'notmuch-poll-and-refresh-this-buffer) +(define-key map j 'notmuch-jump) map) Keymap shared by all notmuch modes.) @@ -845,6 +850,47 @@ status. (defvar notmuch-show-process-crypto nil) (make-variable-buffer-local 'notmuch-show-process-crypto) +;; Jump key support: + +(defvar notmuch-jump-search nil) +(defun notmuch-jump-map () + (let ((map (make-sparse-keymap)) + help) +(set-keymap-parent map minibuffer-local-map) +(suppress-keymap map) +(dolist (saved-search notmuch-saved-searches) + (let ((key (notmuch-saved-search-get saved-search :key))) + (when key + (define-key map key `(lambda () +(interactive) +(setq notmuch-jump-search ',saved-search) +(exit-minibuffer))) + (push (format %s: %s + (propertize key 'face 'minibuffer-prompt) + (notmuch-saved-search-get saved-search :name)) + help +;; Hitting ? displays a quick hint of the accelerators. +(define-key map ? `(lambda () + (interactive) + (message %s + (mapconcat #'identity + ;; Reverse the list so + ;; that elements appear + ;; in the same order as + ;; `notmuch-saved-searches'. + (reverse ',help) + +map)) + +(defun notmuch-jump () + Read a saved search accelerator key and perform the search. + (interactive) + (setq notmuch-jump-search nil) + (read-from-minibuffer Jump to saved search: nil (notmuch-jump-map)) + (when notmuch-jump-search +(notmuch-search (notmuch-saved-search-get notmuch-jump-search :query) + (notmuch-saved-search-get notmuch-jump-search :oldest-first + (provide 'notmuch-lib) ;; Local Variables: -- 2.0.0.rc0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Improving spam-tagging keybinding function to act on region in emacs
Hi. Mark Walters markwalters1...@gmail.com writes: Hello As this section was rather outdated I have updated to modern notmuch. (In fact the lisp snippets should work back to at least 0.13) On Tue, 06 May 2014, Olivier Berger olivier.ber...@telecom-sudparis.eu wrote: Hi. I've tried tu use the tips indicated at http://notmuchmail.org/emacstips/#index8h2 so as to add a keybinding to tag spam messages, and wonder if there's a possibility to make it apply on selected regions, like what notmuch-search-archive-thread does. I have added a snippet showing how to do this (and noted that is not possible in notmuch-tree as we don't have a tag region option there). Thanks. This works exactly I like it :-) Btw, I think that the current examples could be improved by adding a (next-line) at the end, like : (define-key notmuch-search-mode-map S (lambda () mark messages in thread as spam (interactive) (notmuch-search-tag '(+spam -inbox)) (next-line))) I have left this as it is as this works in search mode, but not show mode and I didn't want to have too many examples. Obviously feel free to edit the wiki if you like! Note that I'm now using the following : (define-key notmuch-search-mode-map S (lambda (optional beg end) mark messages in thread as spam (interactive (notmuch-search-interactive-region)) (notmuch-search-tag '(+spam -inbox) beg end) (if (eq beg end) (notmuch-search-next-thread This offers the possibility to jump to the next line when tagging individual lines, and not do so when acting on a region. Btw, such a difference in behaviour may be a tiny, but still nice improvement on the code of notmuch-search-archive-thread too. I haven't touched the wiki, as I'm not sure this is the best way to write it and everyone would be interested. Hope this helps. Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: GMAIL tag sync arriving in next branch in Offlineimap
On Wed, 07 May 2014, Rainer M Krug rai...@krugs.de wrote: Recently, gmail tag sync was discussed here, and it seems something is happening in Offlineimap: patches implementing synching of gmail tags to X-Labels have been applied in the next branch and announced on the Offline mailing list. https://github.com/OfflineIMAP/offlineimap/commit/0e4afa913253c43409e6a32a6b6e11e8b03ed3d9 This is an example of a setup where GMail gets synced with a local Maildir. It also keeps track of GMail labels, that get embedded into the messages under the header X-Keywords (or whatever labelsheader is set to), and syncs them back and forth the same way as flags. The first time it runs on a large repository may take some time as the labels are read / embedded on every message. Afterwards local label changes are detected using modification times (much faster): Modification of message files as labels change? Ugh. I guess notmuch could read a user configurable header and apply the tags there, but notmuch modifying the message files is probably not going to happen. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Linux-only fdatasync() in 3c13bc
On Wed, May 07 2014, Kushal Kumaran kushal.kumaran+notm...@gmail.com wrote: Xīcò x...@atelo.org writes: Also, commit 3c13bc introduced a call to fdatasync() which is not available on FreeBSD, and probably not either on MacOS at least. fdatasync is POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html No wonder it is problematic, then ;) -- regards, kushal Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Linux-only fdatasync() in 3c13bc
Tomi Ollila tomi.oll...@iki.fi writes: On Wed, May 07 2014, Kushal Kumaran kushal.kumaran+notm...@gmail.com wrote: Xīcò x...@atelo.org writes: Also, commit 3c13bc introduced a call to fdatasync() which is not available on FreeBSD, and probably not either on MacOS at least. fdatasync is POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html No wonder it is problematic, then ;) I seem to recall Austin saying on IRC that this usage was guaranteed to call fsync anyway. Comments Austin? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Log of tagging actions
Hi, The amazing thing about the notmuch emacs interface is that with just a couple of keystrokes you can quickly manipulate a lot of emails and thus be very efficient. The big disadvantage is that with just a couple of keystrokes you can manipulate a lot of emails and thus quickly completely mess up your emails. Just think about the scenario of a cat wandering across your keyboard. Is there a possibility to log all tagging actions done in notmuch? Something like: timestamp, msgid, old set of tags new set of tags It would be helpful for restoring things in case something went wrong, and it could be the start of an undo function. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Patch v3 0/3] emacs: show: redesign unread/read logic
On Tue, Mar 25 2014, Mark Walters wrote: The third patch adds my attempt at a plausible logic. I find it works very well: it usually does both what I expect and what I want. Whilst I think that the patch is well done, I don't like the resulting behaviour. That is a personal preference, of course. At the moment it doesn't seem that there is a way to accept this patch and (optionally) retain the existing behaviour. Do you have any thoughts on how we might achieve that? I don't have a strong preference for the default behaviour, though I suspect that something closer to the current behaviour (where a message is marked seen when it becomes the current message[1]) would better match user expectation (but this is an opinion, not something founded in fact). Footnotes: [1] Modulo bugs. signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v4 2/3] emacs: `notmuch-show-buttonize-links' only `notmuch-show's a message if it exists
[ Trimmed to/cc list. ] On Sun, Jan 22 2012, Pieter Praet wrote: * emacs/notmuch-show.el (notmuch-show-found-target-p): new predicate function that uses notmuch(1) 'count' to see if a query turns up any results. * emacs/notmuch-show.el (notmuch-show-if-found): new function that only shows a message/thread if present in the database and otherwise returns an error. * emacs/notmuch-show.el (notmuch-show-buttonize-links): some deduplication, and use new function `notmuch-show-if-found' instead of `notmuch-show' to prevent showing a blank screen for Message-Id's which aren't present in the database. Mark provided some feedback about this (relating to exclusions), but more generally there is a problem that `M-x notmuch-show id:doesntexist' will result in an error (notmuch-show-message-top: Beginning of buffer). That seems like a bug that should be fixed. signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] [PATCH] emacs/notmuch-mua: Generate improved cited text for replies
Use the message display code to generate message text to cite in replies. --- This breaks the tests, which know about the details of how the reply buffer looks in emacs. I will fix that of course, if this approach is considered acceptable. The original implementation took a simplistic view of how a reply to a complex message could be generated (essentially it tried to reduce it to a flat list of text parts). Given that we already have code to display more complex message structure, it seems obvious to use it. emacs/notmuch-mua.el | 34 -- 1 file changed, 4 insertions(+), 30 deletions(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 95e4a4d..a8cff3d 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -28,7 +28,7 @@ (eval-when-compile (require 'cl)) -(declare-function notmuch-show-insert-bodypart notmuch-show (msg part depth optional hide)) +(declare-function notmuch-show-insert-body notmuch-show (msg body depth)) ;; @@ -123,31 +123,6 @@ list. else if (notmuch-match-content-type (plist-get part :content-type) multipart/*) do (notmuch-mua-reply-crypto (plist-get part :content -(defun notmuch-mua-get-quotable-parts (parts) - (loop for part in parts - if (notmuch-match-content-type (plist-get part :content-type) multipart/alternative) - collect (let* ((subparts (plist-get part :content)) - (types (mapcar (lambda (part) (plist-get part :content-type)) subparts)) - (chosen-type (car (notmuch-multipart/alternative-choose types - (loop for part in (reverse subparts) -if (notmuch-match-content-type (plist-get part :content-type) chosen-type) -return part)) - else if (notmuch-match-content-type (plist-get part :content-type) multipart/*) - append (notmuch-mua-get-quotable-parts (plist-get part :content)) - else if (notmuch-match-content-type (plist-get part :content-type) text/*) - collect part)) - -(defun notmuch-mua-insert-quotable-part (message part) - ;; We don't want text properties leaking from the show renderer into - ;; the reply so we use a temp buffer. Also we don't want hooks, such - ;; as notmuch-wash-*, to be run on the quotable part so we set - ;; notmuch-show-insert-text/plain-hook to nil. - (insert (with-temp-buffer - (let ((notmuch-show-insert-text/plain-hook nil)) - ;; Show the part but do not add buttons. - (notmuch-show-insert-bodypart message part 0 'no-buttons)) - (buffer-substring-no-properties (point-min) (point-max) - ;; There is a bug in emacs 23's message.el that results in a newline ;; not being inserted after the References header, so the next header ;; is concatenated to the end of it. This function fixes the problem, @@ -225,10 +200,9 @@ list. (insert From: from \n) (insert Date: date \n\n) - ;; Get the parts of the original message that should be quoted; this includes - ;; all the text parts, except the non-preferred ones in a multipart/alternative. - (let ((quotable-parts (notmuch-mua-get-quotable-parts (plist-get original :body - (mapc (apply-partially 'notmuch-mua-insert-quotable-part original) quotable-parts)) + (insert (with-temp-buffer + (notmuch-show-insert-body original (plist-get original :body) 0) + (buffer-substring-no-properties (point-min) (point-max (set-mark (point)) (goto-char start) -- 2.0.0.rc0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Linux-only fdatasync() in 3c13bc
Quoth David Bremner on May 07 at 10:17 pm: Tomi Ollila tomi.oll...@iki.fi writes: On Wed, May 07 2014, Kushal Kumaran kushal.kumaran+notm...@gmail.com wrote: Xīcò x...@atelo.org writes: Also, commit 3c13bc introduced a call to fdatasync() which is not available on FreeBSD, and probably not either on MacOS at least. fdatasync is POSIX: http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html No wonder it is problematic, then ;) I seem to recall Austin saying on IRC that this usage was guaranteed to call fsync anyway. Comments Austin? Yes, since the size of the file will have definitely changed, the metadata will have to be flushed anyway, so using fdatasync here has no advantage over using fsync. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Patch v3 0/3] emacs: show: redesign unread/read logic
On Wed, 07 May 2014, David Edmondson d...@dme.org wrote: On Tue, Mar 25 2014, Mark Walters wrote: The third patch adds my attempt at a plausible logic. I find it works very well: it usually does both what I expect and what I want. Whilst I think that the patch is well done, I don't like the resulting behaviour. That is a personal preference, of course. At the moment it doesn't seem that there is a way to accept this patch and (optionally) retain the existing behaviour. Do you have any thoughts on how we might achieve that? Thanks for looking and for the feedback. I should emphasise to everyone that I would like all feedback whether positive or negative! I don't have a strong preference for the default behaviour, though I suspect that something closer to the current behaviour (where a message is marked seen when it becomes the current message[1]) would better match user expectation (but this is an opinion, not something founded in fact). Just for the record I will detail what happens currently and then I have a couple questions about your suggestion. A message is marked read if: 1) if you navigate to a message using n/p (next/prev open message) 2) if you navigate to it using N/P (next/prev message) regardless of whether the message is open or closed. 3) if you go to it using n.s.next-matching-message (not bound by default) whether message is open or closed. 4) when you enter a buffer and notmuch goes to the first open message. but not marked read in cases like: 1) opening a message 2) viewing or entering a message using other notmuch navigation such as notmuch-show-advance and friends (bound to space) 3) viewing or entering a message using arrow keys, page-up page-down, ctrl-v mouse clicks etc Personally, I think marking a closed message read is a bug, and not marking it read when opening it is too (at least in many cases). The other problem with the current approach (in my view) is that if you try to use the navigation commands non-interactively then messages end up being marked read, even if they are never displayed to the user. Linking into the post-command-hook means that this should just work. Questions: What does it mean for a message to be the current message? Is it just point being in the message? Would you be happy with a message being marked read when point entered the message? That could be done from the post-command-hook infrastructure to fix some of the problems mentioned above. I think that is likely that people will disagree on how they want this to work so I would like to try and make it customisable so I would definitely be interested to see if I can get the behaviour you would like from this infrastructure (or something similar). Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: folder and path completely broken in HEAD?
The trick here is that it's easy to miss people who are happy with current functionality. Adding functionality to address newly-identified use cases makes a lot of sense. But removing functionality runs the risk of only discovering that people were relying on it after the fact, (Which seems to have happened here). Yes indeed. I think one thing that I, at least, hadn't realised is that people have lots of strange mail layouts often to work around problems in mail agents (notmuch or others) or filesystem limitations etc. The idea of path: is that it's the exact filesystem directory, relative from the maildir root, with an rsync like ** syntax for recursive matching. This definition of path: seems good. It covers a lot of cases that the original folder: did not and allows precise, predictable control. Turns out people want folder: to hide maildir implementation details like cur and new. Which is something that folder: always did. These are not compatible, or you need to add a syntax that's not easy or discoverable. OK. So I won't argue that we don't need two different syntaxes here. But I will continue to discuss a use case that was addressed before and is no longer. I think many of us would agree, but there were users who wanted to distinguish new and cur, and in at least one case, the toplevel as well. So now, path: allows for that, right? My concern is not so much that path: was added to address new things, but more than folder: was modified in a way that dropped useful functionality, (beyond just fixing bugs in folder: such as the accidental support of stemming). One possibly perverse remark: it wouldn't surprise me if someone actually used the stemming. I have used folders called old older and oldest and that probably can be excluded by stemming. All I am really saying is that any change we made was going to break some people's setups. I think it is unfortunate that we need two variants, but I think they do do different things. I'll accept that. But, while I have heard a good definition of path:, (see above), I haven't heard a good one for folder: yet. Can you provide that? I think folder:foo/bar means In the maildir exactly foo/bar Also, I think any single user will find one matches their setup and use that one essentially exclusively: The current discussion is evidence against that. We have a user of folder: that can no longer get at the desired functionality, (that used to exist). Sorry I wasn't trying to suggest that the current setup does everything people want (clearly not!): just answering your question about the differences being confusing. since each user will probably only use one of them they probably become accustomed to its use. Indeed, I think of the choice as being analogous to allowing the user to choose which path scheme they like (so sort of like a customisation): maildir folder based or filesystem path based. Indeed, it may be that a third option of roughly a maildir++: search term might solve David's use case. Or just making folder: index each term of a filesytem path like it used to do. And if that doesn't give sufficient control to some users, then path: is available. We could do this. It might break things for user who are using the new syntax Maybe we could make an initial / match the root of the maildir store. But I think some people will dislike any of the options. I've already lost what I would have preferred, (a single syntax for all use cases---which was lost not to a design problem, but simply the implementation difficulty of requiring a custom query parser). I really would not like to see things continue down to have a *third* syntax. So this third syntax would fit with my view of it being a customisation like thing. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/1] devel: news2wiki to recognize yyyy-mm-dd or UNRELEASED as release date
The -mm-dd (actually \d\d\d\d-\d\d-\d\d) for a bit more restrictive
(and self-documentative) than the \w\w\w\w-... that used to be there and
UNRELEASED so that developers can test the latest NEWS converted to mdwn
format before submitting NEWS patches.
---
devel/news2wiki.pl | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/devel/news2wiki.pl b/devel/news2wiki.pl
index 8066ba7..d966bab 100755
--- a/devel/news2wiki.pl
+++ b/devel/news2wiki.pl
@@ -32,8 +32,7 @@ while (I)
{
warn $ARGV[0]:$.: tab(s) in line!\n if /\t/;
warn $ARGV[0]:$.: trailing whitespace\n if /\s\s$/;
-# The date part in regex recognizes wip version dates like: (201x-xx-xx).
-if (/^Notmuch\s+(\S+)\s+\((\w\w\w\w-\w\w-\w\w)\)\s*$/) {
+if (/^Notmuch\s+(\S+)\s+\((\d\d\d\d-\d\d-\d\d|UNRELEASED)\)\s*$/) {
# open O... autocloses previously opened file.
open O, '', $ARGV[1]/release-$1.mdwn or die $!;
print + release-$1.mdwn...\n;
--
1.9.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Github?
Hello everyone, Thank you so much for creating Notmuch, I am coming from sup and I was looking for a more stable alternative and I think I found what I am looking for :) I was a bit disappointed that the project is not living (or at least mirrored) to Github, it would have made my search much easier. Any thoughts on moving to Github? I took the liberty of making the first move by creating https://github.com/notmuch and splitting the contrib/ and binding/ into their own repository (conserving all their history). @owners and devs, if you'd like to explore the Github option more I'd be happy to grant you admin rights of the notmuch Github organisation. Thanks, Wael ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Github?
I forgot to mention that I also enabled Travis-CI for notmuch, you can access it here https://travis-ci.org/notmuch/notmuch, there are 33 failed tests, they are also failing on my own machine. On Wed May 07 2014 at 10:28:06 PM, Wael Nasreddine wael.nasredd...@gmail.com wrote: Hello everyone, Thank you so much for creating Notmuch, I am coming from sup and I was looking for a more stable alternative and I think I found what I am looking for :) I was a bit disappointed that the project is not living (or at least mirrored) to Github, it would have made my search much easier. Any thoughts on moving to Github? I took the liberty of making the first move by creating https://github.com/notmuch and splitting the contrib/ and binding/ into their own repository (conserving all their history). @owners and devs, if you'd like to explore the Github option more I'd be happy to grant you admin rights of the notmuch Github organisation. Thanks, Wael ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
