Re: [PATCH] emacs: initialize ido mode in notmuch-mua.el
On Sun, Jan 26 2014, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> How about doing it with defadvice with something like:
>>
>> (from http://comments.gmane.org/gmane.emacs.bugs/27856 one can notice
>> this happening with emacs 23.3 -- David can check whether 23.4 if
>> affected)
>
> It's fixed in 23.4
>
>>
>> (if (and (= emacs-major-version 23) (< emacs-minor-version 4))
>> (defadvice ido-completing-read (before notmuch-ido-mode-init activate)
>> (unless (ido-mode) (ido-mode t))
>> (ad-disable-advice 'ido-completing-read 'before
>> 'notmuch-ido-mode-init)))
>
> Advice always seems over complex to me, but maybe I'm just
> prejudiced/ignorant.
With defadvice we can keep "mainline code less messy and less hard to
maintain" ;) -- and only install the advice on versions that need it.
Also with defadvice the other use of ido-completing-read is covered.
> Can you decode/reverse-engineer the fix in
>
> http://permalink.gmane.org/gmane.emacs.bugs/41957
>
> ?
>
> Maybe the advice or whatever should call
>
>(ido-init-completion-maps)
>(add-hook 'minibuffer-setup-hook 'ido-minibuffer-setup)
>(add-hook 'choose-completion-string-functions
> 'ido-choose-completion-string))
>
> Although that looks worryingly permanent.
(emacs-version) -> 24.3.1
(describe-variable 'minibuffer-setup-hook)
-> (rfn-eshadow-setup-minibuffer minibuffer-history-isearch-setup
minibuffer-history-initialize)
(ido-completing-read "test" '("foo" "bar"))
(describe-variable 'minibuffer-setup-hook)
-> (ido-minibuffer-setup rfn-eshadow-setup-minibuffer
minibuffer-history-isearch-setup minibuffer-history-initialize)
SO, although permanent, consistent w/ newer emacs versions...
> d
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC PATCH] configure: check for POSIX.1-2008 realpath(3) implementation.
On Sun, Jan 26 2014, David Bremner wrote:
> Tomi Ollila writes:
>> +#if POSIX_2008_REALPATH
>> filename = realpath (config->filename, NULL);
>> +#else
>> +/* compatibility with minor effort, not elegance, is the ruling factor
>> + in these (two) else branches... */
>> +char resolved_path[PATH_MAX];
>> +filename = realpath (config->filename, resolved_path);
>> +#endif
>
> I worry a bit about making the mainline code messier and harder to maintain,
> in order to
> accomodate an unknown number of targets without POSIX2008 realpath. Do
> we know how widespread this problem is? Is it just NetBSD?
>
> I looked at borrowing realpath from gnulib; it looks like it would be a
> bit of work as the least complicated version includes 3 other include
> files. But then the mainline code could be blisfully ignorant of the
> whole dispute.
We could also create
char * realpath2008 (const char * path, char * resolved_path)
{
if (resolved_path == NULL) {
resolved_path = malloc (MAX_PATH);
if (resolved_path == NULL)
return NULL;
}
return realpath (path, resolved_path);
}
And, in the case where NULL argument is accepted,
#define realpath2008(path, resolved_path) realpath(path, resolved_path)
(or an inline function to do the same)
In this case one is not totally ignorant to the whole dispute -- but
on the other hand, developer should be savvy about the potential
issues using realpath() function, and this might just ring the bell...
> d
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Bug: notmuch new chokes on dangling symlinks and quits
Dear notmuch developers, notmuch new quits operation if it hit's a dangling symlink: Error reading file /home/grfz/notmuch2/Mail/findex/cur/123456789.684055.mairix:2,: No such file or directory Note: A fatal error was encountered: Something went wrong trying to read or write a file Processed 85 total files in 1s (47 files/sec.) I consider this to be a bug. Instead notmuch should simply ignore the symlink. This is especially problematic while indexing a huge amount of mail the first time and notmuch hits the dangling symlink at an early stage of indexing. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: initialize ido mode in notmuch-mua.el
Tomi Ollila writes: > > (describe-variable 'minibuffer-setup-hook) > > -> (ido-minibuffer-setup rfn-eshadow-setup-minibuffer > minibuffer-history-isearch-setup minibuffer-history-initialize) > > SO, although permanent, consistent w/ newer emacs versions... > Yeah, the other hook is set permanently as well. So, do these three lines of code (in advice if you must ;) ) fix the problem? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/1] build: delete the default .SUFFIXES
Tomi Ollila writes: > All implicit rules in notmuch Makefiles are "pattern rules"; Deleting the > default suffixes (to support obsolete, old-fashioned "suffix rules") from > make reduces the output of 'make -d' by 40 to 90 percent, helping e.g. > debugging make problems. pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: update documentation for notmuch_database_get_directory
David Bremner writes: > Clarify that using the directory after destroying the corresponding > database is not permitted. > > This is implicit in the description of notmuch_database_destroy, but > it doesn't hurt to be explicit, and we do express similar "ownership" > relationships at other places in the docs. pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/7] cli: notmuch new improvements
Jani Nikula writes: > Here's an assortment of notmuch new fixes, non-functional cleanups, and > the oft-requested --quiet option. > pushed. Would be nice to have a simple test for the --quiet option. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: notmuch new chokes on dangling symlinks and quits
Gregor Zattler writes: > > I consider this to be a bug. Instead notmuch should simply > ignore the symlink. > Since there is a test for specifically this behaviour, I'd have to say it's a design decision you don't agree with, not a bug ;). In any case, if there is just a few broken symlinks, and you want to ignore them, you can add them the ignore= line in .notmuch-config d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC PATCH] configure: check for POSIX.1-2008 realpath(3) implementation.
Tomi Ollila writes:
>
> We could also create
>
> char * realpath2008 (const char * path, char * resolved_path)
> {
> if (resolved_path == NULL) {
> resolved_path = malloc (MAX_PATH);
> if (resolved_path == NULL)
> return NULL;
> }
> return realpath (path, resolved_path);
> }
>
I sent several private replies to Tomi this morning while being
sleepy. But they were not so great replies anyway.
What about implimenting a compat version of canonicalize_file_name ?
that function is a gnu extension, but since we only call realpath with a
NULL second argument, it might be slighltly simpler to test/google for.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] emacs: add a function to heuristically test if the CLI is configured OK.
We cache the result so that we can call the function many places without worrying about the cost. --- emacs/notmuch-lib.el | 11 +++ 1 file changed, 11 insertions(+) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 2be409b..dcdfbdc 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -168,6 +168,17 @@ Otherwise the output will be returned" (notmuch-check-exit-status status (cons notmuch-command args) output) output))) +(defvar notmuch--cli-sane-p nil + "Cache whether the CLI seems to be configured sanely.") + +(defun notmuch-cli-sane-p () + "Return t if the cli seems to be configured sanely." + (unless notmuch--cli-sane-p +(let ((status (call-process notmuch-command nil nil nil + "config" "get" "user.primary_email"))) + (setq notmuch--cli-setup-p (= status 0 + notmuch--cli-sane-p) + (defun notmuch-version () "Return a string with the notmuch version number." (let ((long-string -- 1.8.5.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/3] emacs: add notmuch-assert-cli-sane to notmuch-hello
This is meant to be the friendly entrypoint, so let's do something better than the mangled output described in id:5228989d.8030...@fifthhorseman.net --- emacs/notmuch-hello.el | 1 + 1 file changed, 1 insertion(+) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 55c416a..7b3d76b 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -788,6 +788,7 @@ following: "Run notmuch and display saved searches, known tags, etc." (interactive) + (notmuch-assert-cli-sane) ;; This may cause a window configuration change, so if the ;; auto-refresh hook is already installed, avoid recursive refresh. (let ((notmuch-hello-auto-refresh nil)) -- 1.8.5.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/3] emacs: add function notmuch-assert-cli-sane
If the CLI seems borked, signal an error, and log a suggestion for the user about how to recover. --- emacs/notmuch-lib.el | 7 +++ 1 file changed, 7 insertions(+) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index dcdfbdc..c195652 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -179,6 +179,13 @@ Otherwise the output will be returned" (setq notmuch--cli-setup-p (= status 0 notmuch--cli-sane-p) +(defun notmuch-assert-cli-sane () + (unless (notmuch-cli-sane-p) +(notmuch-logged-error + "notmuch cli seems misconfigured or unconfigured." +"Perhaps you haven't run \"notmuch setup\" yet? Try running this +on the command line, and then retry your notmuch command"))) + (defun notmuch-version () "Return a string with the notmuch version number." (let ((long-string -- 1.8.5.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: add basic tests for notmuch new --quiet option
This does not cover all the possible paths notmuch new could output
stuff, but it's better than nothing.
---
test/T050-new.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/T050-new.sh b/test/T050-new.sh
index f27423d..b7668ff 100755
--- a/test/T050-new.sh
+++ b/test/T050-new.sh
@@ -248,4 +248,19 @@ ln -s i_do_not_exist "${MAIL_DIR}"/broken_link
output=$(NOTMUCH_NEW 2>&1)
test_expect_equal "$output" "No new mail."
+test_begin_subtest "Quiet: No new mail."
+output=$(NOTMUCH_NEW --quiet)
+test_expect_equal "$output" ""
+
+test_begin_subtest "Quiet: new, removed and renamed messages."
+# new
+generate_message
+# deleted
+notmuch search --format=text0 --output=files --limit=1 '*' | xargs -0 rm
+# moved
+mkdir "${MAIL_DIR}"/moved_messages
+notmuch search --format=text0 --output=files --offset=1 --limit=1 '*' | xargs
-0 -I {} mv {} "${MAIL_DIR}"/moved_messages
+output=$(NOTMUCH_NEW --quiet)
+test_expect_equal "$output" ""
+
test_done
--
1.8.5.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: add a function to heuristically test if the CLI is configured OK.
We cache the result so that we can call the function many places without worrying about the cost. --- thanks to Tomi for catching the typos (uncommitted changes on my end). emacs/notmuch-lib.el | 11 +++ 1 file changed, 11 insertions(+) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 2be409b..140d760 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -168,6 +168,17 @@ Otherwise the output will be returned" (notmuch-check-exit-status status (cons notmuch-command args) output) output))) +(defvar notmuch--cli-sane-p nil + "Cache whether the CLI seems to be configured sanely.") + +(defun notmuch-cli-sane-p () + "Return t if the cli seems to be configured sanely." + (unless notmuch--cli-sane-p +(let ((status (call-process notmuch-command nil nil nil + "config" "get" "user.primary_email"))) + (setq notmuch--cli-sane-p (= status 0 + notmuch--cli-sane-p) + (defun notmuch-version () "Return a string with the notmuch version number." (let ((long-string -- 1.8.5.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: add basic tests for notmuch new --quiet option
LGTM +1.
Best wishes
Mark
On Sun, 26 Jan 2014, Jani Nikula wrote:
> This does not cover all the possible paths notmuch new could output
> stuff, but it's better than nothing.
> ---
> test/T050-new.sh | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/test/T050-new.sh b/test/T050-new.sh
> index f27423d..b7668ff 100755
> --- a/test/T050-new.sh
> +++ b/test/T050-new.sh
> @@ -248,4 +248,19 @@ ln -s i_do_not_exist "${MAIL_DIR}"/broken_link
> output=$(NOTMUCH_NEW 2>&1)
> test_expect_equal "$output" "No new mail."
>
> +test_begin_subtest "Quiet: No new mail."
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> +test_begin_subtest "Quiet: new, removed and renamed messages."
> +# new
> +generate_message
> +# deleted
> +notmuch search --format=text0 --output=files --limit=1 '*' | xargs -0 rm
> +# moved
> +mkdir "${MAIL_DIR}"/moved_messages
> +notmuch search --format=text0 --output=files --offset=1 --limit=1 '*' |
> xargs -0 -I {} mv {} "${MAIL_DIR}"/moved_messages
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> test_done
> --
> 1.8.5.2
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: initialize ido mode in notmuch-mua.el
I don't have anything older than 23.4 anymore so I am afraid I can't test. My recollection is that I upgraded to 23.4 the problem went away so I forgot about it. (I couldn't see easily what version of emacs debian stable has now as seemed to be called 45.) Best wishes Mark On Sat, 25 Jan 2014, David Bremner wrote: > Mark Walters writes: > >> ido-completing-read is used in notmuch-mua.el without any >> initialization. This should work but a bug (emacs bug #3247) in some >> emacs 23 versions (including 23.2.1 from Debian stable) causes emacs >> to get stuck in the mini-buffer. This tests to see if ido-mode has >> been initialized and if not calls it. This avoids the bug for these >> older versions of emacs. >> >> This is the only place that ido-completing-read is used so an alternative >> would be to replace ido-completing-read by completing-read but cworth >> expressed a preference for the ido version in >> id:"87wrhfvk6a@yoom.home.cworth. > > This patch was tagged wip, but then there was no progress ;). It still > applies cleanly, and doesn't seem to do any harm in emacs 23.4 nor > emacs24.3. I don't have 23.2 at hand but I guess Tomi or Mark can > confirm it actually fixes the bug there. > > I propose we either apply the patch or ::wontfix the bug. > > cheers, > > d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: add a function to heuristically test if the CLI is configured OK.
This version LGTM +1. (Just for the record there was some discussion on irc about switching to the *notmuch errors* buffer but that is more complex and fragile so let's go with this simple and effective solution.) Best wishes Mark On Sun, 26 Jan 2014, David Bremner wrote: > We cache the result so that we can call the function many places > without worrying about the cost. > --- > thanks to Tomi for catching the typos (uncommitted changes on my end). > > emacs/notmuch-lib.el | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el > index 2be409b..140d760 100644 > --- a/emacs/notmuch-lib.el > +++ b/emacs/notmuch-lib.el > @@ -168,6 +168,17 @@ Otherwise the output will be returned" >(notmuch-check-exit-status status (cons notmuch-command args) output) >output))) > > +(defvar notmuch--cli-sane-p nil > + "Cache whether the CLI seems to be configured sanely.") > + > +(defun notmuch-cli-sane-p () > + "Return t if the cli seems to be configured sanely." > + (unless notmuch--cli-sane-p > +(let ((status (call-process notmuch-command nil nil nil > + "config" "get" "user.primary_email"))) > + (setq notmuch--cli-sane-p (= status 0 > + notmuch--cli-sane-p) > + > (defun notmuch-version () >"Return a string with the notmuch version number." >(let ((long-string > -- > 1.8.5.2 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: add a function to heuristically test if the CLI is configured OK.
On Sun, Jan 26 2014, David Bremner wrote: > We cache the result so that we can call the function many places > without worrying about the cost. > --- > thanks to Tomi for catching the typos (uncommitted changes on my end). Series LGTM. Tomi > > emacs/notmuch-lib.el | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el > index 2be409b..140d760 100644 > --- a/emacs/notmuch-lib.el > +++ b/emacs/notmuch-lib.el > @@ -168,6 +168,17 @@ Otherwise the output will be returned" >(notmuch-check-exit-status status (cons notmuch-command args) output) >output))) > > +(defvar notmuch--cli-sane-p nil > + "Cache whether the CLI seems to be configured sanely.") > + > +(defun notmuch-cli-sane-p () > + "Return t if the cli seems to be configured sanely." > + (unless notmuch--cli-sane-p > +(let ((status (call-process notmuch-command nil nil nil > + "config" "get" "user.primary_email"))) > + (setq notmuch--cli-sane-p (= status 0 > + notmuch--cli-sane-p) > + > (defun notmuch-version () >"Return a string with the notmuch version number." >(let ((long-string > -- > 1.8.5.2 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: initialize ido mode in notmuch-mua.el
On Sun, Jan 26 2014, Mark Walters wrote: > I don't have anything older than 23.4 anymore so I am afraid I can't > test. My recollection is that I upgraded to 23.4 the problem went away > so I forgot about it. Fine, I prepare and test the patch then ;/ Tomi > (I couldn't see easily what version of emacs debian stable has now as > seemed to be called 45.) > > Best wishes > > Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/1] build: write VERSION file containing $(VERSION) string
Hi
I experimented with this and it didn't always seem to rebuild VERSION
when it should. Looking at the file .git/HEAD that just seems to be the
branch name not the commit id (unless in detached HEAD state)
This link
http://stackoverflow.com/questions/6526451/how-to-include-git-commit-number-into-a-c-executable
suggests adding .git/index to the VERSION depends.
I tested that and that does seem to work. It may mean that VERSION gets
rebuilt if you stash (for example) but that is probably not a big
problem.
Best wishes
Mark
On Sat, 25 Jan 2014, Tomi Ollila wrote:
> This version file will be as prerequisite to the target files
> that use the version info for some purpose, like printing
> it to the user to examine. The contents of the VERSION file
> is seldom read by the build system itself as the $(VERSION)
> variable has the same information.
> ---
> Makefile.local | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.local b/Makefile.local
> index c85e09c..1f876b3 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -22,6 +22,8 @@ VERSION:=$(shell cat ${srcdir}/version)
> ifeq ($(filter release release-message pre-release
> update-versions,$(MAKECMDGOALS)),)
> ifeq ($(IS_GIT),yes)
> VERSION:=$(shell git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e
> s/-/~/)
> +# Make the 'VERSION' file depend *also* on .git/HEAD in this case
> +VERSION: .git/HEAD
> endif
> endif
>
> @@ -69,6 +71,11 @@ ifeq ($(shell cat .first-build-message 2>/dev/null),)
> endif
> endif
>
> +# This VERSION file is used mostly for triggering other file remakes...
> +# This may get other dependency to .git/HEAD above in this file.
> +VERSION: version
> + echo $(VERSION) > $@
> +
> $(TAR_FILE):
> if git tag -v $(VERSION) >/dev/null 2>&1; then \
> ref=$(VERSION); \
> @@ -280,6 +287,8 @@ notmuch_client_srcs = \
>
> notmuch_client_modules = $(notmuch_client_srcs:.c=.o)
>
> +notmuch.o: VERSION
> +
> notmuch: $(notmuch_client_modules) lib/libnotmuch.a util/libutil.a
> parse-time-string/libparse-time-string.a
> $(call quiet,CXX $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@
>
> @@ -318,7 +327,7 @@ install-desktop:
> desktop-file-install --mode 0644 --dir "$(DESTDIR)$(desktop_dir)"
> notmuch.desktop
>
> SRCS := $(SRCS) $(notmuch_client_srcs)
> -CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules)
> notmuch.elc
> +CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)
>
> DISTCLEAN := $(DISTCLEAN) .first-build-message Makefile.config
>
> --
> 1.8.5.3
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: add basic tests for notmuch new --quiet option
On Sun, Jan 26 2014, Jani Nikula wrote:
> This does not cover all the possible paths notmuch new could output
> stuff, but it's better than nothing.
> ---
LGTM.
Tomi
> test/T050-new.sh | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/test/T050-new.sh b/test/T050-new.sh
> index f27423d..b7668ff 100755
> --- a/test/T050-new.sh
> +++ b/test/T050-new.sh
> @@ -248,4 +248,19 @@ ln -s i_do_not_exist "${MAIL_DIR}"/broken_link
> output=$(NOTMUCH_NEW 2>&1)
> test_expect_equal "$output" "No new mail."
>
> +test_begin_subtest "Quiet: No new mail."
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> +test_begin_subtest "Quiet: new, removed and renamed messages."
> +# new
> +generate_message
> +# deleted
> +notmuch search --format=text0 --output=files --limit=1 '*' | xargs -0 rm
> +# moved
> +mkdir "${MAIL_DIR}"/moved_messages
> +notmuch search --format=text0 --output=files --offset=1 --limit=1 '*' |
> xargs -0 -I {} mv {} "${MAIL_DIR}"/moved_messages
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> test_done
> --
> 1.8.5.2
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-emacs bug report -- infinite looping trying to select next message
David Bremner writes: > Michael Hudson-Doyle writes: > >> The attached gzipped mbox appears to trip up the emacs interface. The >> problem seems to come from the message with id >> CAGNsrLCWv6=36q+q+5Hc_SzgdZ2ergeKkapT7T3xXvim=2c...@mail.gmail.com. >> > > I can't reproduce this bug in current git, so I'm going to assume > something fixed it in the intervening years. I find the same. > In particular our handling of error reporting for corrupted parts > changed, so maybe that was it. When I load up the thread that caused the problem I end up with this in the buffer: [ message/external-body ] !!! Bodypart insert error: Couldn't find access type !!! [ text/plain ] so I think it's pretty likely your guess is accurate. > Thanks so much for including a test case with your bug report, No problem, thanks for checking this ancient report! (And thanks to myself for including the message-id in the report...) Cheers, mwh ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug?: notmuch-search-show-thread shows several threads; only one containing matching messages
Hi David, * David Bremner [24. Jan. 2014]: > Mark Walters writes: >> I have looked at this and I think this is not notmuch's fault: I think >> it is a mua doing strange things: >> >> One of the mails has an in-reply-to header which looks like >> >> In-reply-to: Message from Carsten Dominik of >>"Tue, 15 Mar 2011 12:18:51 BST." >> <17242340-a14f-495a-b144-20c96d52b...@gmail.com> >> >> and I think notmuch is taking the carsten.domi...@gmail.com as message >> id. >> > > Can someone test if this is fixed by cf8aaafbad68 (i.e. does the problem > persist in git master or 0.17)? The problem is *not* fixed. I was the one who reported this problem two years ago. I did the same notmuch search again. Since I did no know if it's important with which version the emails were indexed I did a full index with notmuch 0.17+40~gecbb29e. I still have the mbox produced with notmuch show two years ago. Viewed with mutt (1) I see 206 messages in 7 threads (number of lines after collapse-all) (notmuch emacs show showed three threads then). One of the threads is the one I searched for. Today I produced another mbox with the very same command but with a now larger email corpus freshly indexed with a fresh notmuch. The mbox contains (according to mutt) 507 messages in 34 threads. One of them is the thread I searched for. I grepped for the 7 subjects within the 34 subjects and only 5 showed up. Only 17 of the 507 messages arrived since the problem report two years ago. If somebody want's to dig into this: I can provide the two mboxes. Disclaimer: Many of the emails which arrived before the problem report are not the exact same than then, because since the I mangled them with a script. This should have not changed the threading but I cannot be 100% sure. But if it's important for further investigation I'm probably able to reproduce the status quo of the email corpus then from my backups. Thanks for your persistence. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug?: notmuch-search-show-thread shows several threads; only one containing matching messages
Gregor Zattler writes: > Today I produced another mbox with the very same command but with > a now larger email corpus freshly indexed with a fresh notmuch. > The mbox contains (according to mutt) 507 messages in 34 threads. > One of them is the thread I searched for. > > I grepped for the 7 subjects within the 34 subjects and only 5 > showed up. I don't know what you mean here. Grepped where? in the raw messages? > If somebody want's to dig into this: I can provide the two > mboxes. > > Disclaimer: Many of the emails which arrived before the problem > report are not the exact same than then, because since the I > mangled them with a script. This should have not changed the > threading but I cannot be 100% sure. But if it's important for > further investigation I'm probably able to reproduce the status > quo of the email corpus then from my backups. If it's currently not working then I guess your current corpus should be fine. It would probably help to restate what exactly is wrong. There was a lot of discussion, and the concrete problem I saw identified (in id:874nvcekjk@qmul.ac.uk ) was that certain malformed In-reply-to headers were causing unrelated threads to merge. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: notmuch new chokes on dangling symlinks and quits
Hi David, * David Bremner [26. Jan. 2014]: > Gregor Zattler writes: >> I consider this to be a bug. Instead notmuch should simply >> ignore the symlink. >> > > Since there is a test for specifically this behaviour, I'd have to say > it's a design decision you don't agree with, not a bug ;). May I ask why this is so? > In any case, if there is just a few broken symlinks, and you want to > ignore them, you can add them the ignore= line in .notmuch-config Thanks, I deleted some, and ignored others. Insofar my problem is solved. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug?: notmuch-search-show-thread shows several threads; only one containing matching messages
Hi David, * David Bremner [26. Jan. 2014]: > Gregor Zattler writes: > >> Today I produced another mbox with the very same command but with >> a now larger email corpus freshly indexed with a fresh notmuch. >> The mbox contains (according to mutt) 507 messages in 34 threads. >> One of them is the thread I searched for. >> >> I grepped for the 7 subjects within the 34 subjects and only 5 >> showed up. > > I don't know what you mean here. Grepped where? in the raw messages? With mutt I had a view at the collapsed 7 respective 34 threads. One then sees the very first E-Mails of a thread and among other information their subjects. Via editing I produced two lists with subjects and then searched each of the 7 in the list with the 34. >> If somebody want's to dig into this: I can provide the two >> mboxes. >> >> Disclaimer: Many of the emails which arrived before the problem >> report are not the exact same than then, because since the I >> mangled them with a script. This should have not changed the >> threading but I cannot be 100% sure. But if it's important for >> further investigation I'm probably able to reproduce the status >> quo of the email corpus then from my backups. > > If it's currently not working then I guess your current corpus should be > fine. It would probably help to restate what exactly is wrong. There was > a lot of discussion, and the concrete problem I saw identified (in > id:874nvcekjk@qmul.ac.uk ) was that certain malformed In-reply-to > headers were causing unrelated threads to merge. Yes. I understood the commit message of the commit you referenced in the email I answered to, that now notmuch uses Reference: headers to do the threading. I had a quick view at the References header in the mbox file and none looked suspicious. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC PATCH] configure: check for POSIX.1-2008 realpath(3) implementation.
On Sat, Jan 25 2014, Tomi Ollila wrote:
> Check whether realpath(3) supports the resolved_path == NULL feature,
> standardized in POSIX.1-2008.
>
> This is tested by executing the realpath(3) with NULL as second
> argument and the program is expected to SIGSEGV in case the
> feature is not supported.
>
> If the feature is not supported the compatibility code calls realpath(3)
> with second argument pointing to buffer with MAX_PATH in size. With
> this more systems are supported; those that have POSIX.1-2008 -capable
> realpath(3) and those that have MAX_PATH defined and realpath(3) does
> not exceed that limit.
> ---
>
> I tested running configure and then make test; then make clean,
> edited Makefile.config POSIX_2008_REALPATH = 0 and make clean
> again. then tested sigsegv'ing with (memcpy(0, 0, 4)...
>
>
> configure| 32 ++--
> notmuch-config.c | 21 -
> 2 files changed, 50 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index 13b6062..8174219 100755
> --- a/configure
> +++ b/configure
> @@ -454,6 +454,29 @@ echo $util_byte_order
>
> rm -f _byteorder _byteorder.c
>
> +printf "Checking for posix 2008 realpath()... "
> +# resolved_path == NULL is standardized in POSIX.1-2008
> +cat > _posix_2008_realpath.c < +#define _BSD_SOURCE
> +#include
> +#include
> +#include
> +void exit1(int sig) { exit(1); }
> +int main () {
> + signal(SIGSEGV, exit1);
> + int main () { realpath (".", (char*)0); return 0;
> +}
> +EOF
> +${CC} ${CFLAGS} _posix_2008_realpath.c -o _posix_2008_realpath > /dev/null
> 2>&1
> +if ./_posix_2008_realpath; then
> + echo Yes.
> + posix_2008_realpath=1
> +else
> + echo No.
> + posix_2008_realpath=0
> +fi
> +rm -f _posix_2008_realpath _posix_2008_realpath.c
> +
> if [ $errors -gt 0 ]; then
> cat <
> @@ -718,6 +741,9 @@ libdir = ${LIBDIR:=\$(prefix)/lib}
> # byte order within a 32 bit word. 1234 = little, 4321 = big, 0 = guess
> UTIL_BYTE_ORDER = ${util_byte_order}
>
> +# Whether realpath(3) supports resolved_path == NULL feature
> +POSIX_2008_REALPATH = ${posix_2008_realpath}
> +
> # Whether libdir is in a path configured into ldconfig
> LIBDIR_IN_LDCONFIG = ${libdir_in_ldconfig}
>
> @@ -824,7 +850,8 @@ CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE)
> \$(GMIME_CFLAGS) \\
> -DSTD_GETPWUID=\$(STD_GETPWUID) \\
> -DSTD_ASCTIME=\$(STD_ASCTIME) \\
> -DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) \\
> --DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER)
> +-DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER) \\
> +-DPOSIX_2008_REALPATH=\$(POSIX_2008_REALPATH)
>
> CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\
>\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
> @@ -834,7 +861,8 @@ CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE)
> \$(GMIME_CFLAGS)\\
>-DSTD_GETPWUID=\$(STD_GETPWUID) \\
>-DSTD_ASCTIME=\$(STD_ASCTIME) \\
>-DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) \\
> - -DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER)
> + -DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER) \\
> + -DPOSIX_2008_REALPATH=\$(POSIX_2008_REALPATH)
>
> CONFIGURE_LDFLAGS = \$(GMIME_LDFLAGS) \$(TALLOC_LDFLAGS) \$(XAPIAN_LDFLAGS)
> EOF
> diff --git a/notmuch-config.c b/notmuch-config.c
> index 8d28653..14d0e5c 100644
> --- a/notmuch-config.c
> +++ b/notmuch-config.c
> @@ -454,10 +454,26 @@ notmuch_config_save (notmuch_config_t *config)
> }
>
> /* Try not to overwrite symlinks. */
> +#if POSIX_2008_REALPATH
> filename = realpath (config->filename, NULL);
> +#else
> +/* compatibility with minor effort, not elegance, is the ruling factor
> + in these (two) else branches... */
> +char resolved_path[PATH_MAX];
> +filename = realpath (config->filename, resolved_path);
> +#endif
> if (! filename) {
> if (errno == ENOENT) {
> +#if POSIX_2008_REALPATH
> filename = strdup (config->filename);
> +#else
> + /* ... this is the other else... */
> + resolved_path[sizeof resolved_path - 1] = '\0';
> + strncpy(resolved_path, config->filename, sizeof resolved_path);
> + /* "faking" out of memory in case path too long -- close enough? */
> + filename = resolved_path[sizeof resolved_path - 1]?
> + resolved_path: NULL;
Ok, this above is wrong (should be other way around). Tests pass though
meaning this is not within test coverage...
Tomi
> +#endif
> if (! filename) {
> fprintf (stderr, "Out of memory.\n");
> g_free (data);
> @@ -480,12 +496,15 @@ notmuch_config_save (notmuch_config_t *config)
>filena
[PATCH 1/1] build: write VERSION file containing $(VERSION) string
This version file will be as prerequisite to the target files
that use the version info for some purpose, like printing
it to the user to examine. The contents of the VERSION file
is seldom read by the build system itself as the $(VERSION)
variable has the same information.
---
Makefile.local | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Makefile.local b/Makefile.local
index c85e09c..1f876b3 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -22,6 +22,8 @@ VERSION:=$(shell cat ${srcdir}/version)
ifeq ($(filter release release-message pre-release
update-versions,$(MAKECMDGOALS)),)
ifeq ($(IS_GIT),yes)
VERSION:=$(shell git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e
s/-/~/)
+# Make the 'VERSION' file depend *also* on .git/HEAD in this case
+VERSION: .git/HEAD
endif
endif
@@ -69,6 +71,11 @@ ifeq ($(shell cat .first-build-message 2>/dev/null),)
endif
endif
+# This VERSION file is used mostly for triggering other file remakes...
+# This may get other dependency to .git/HEAD above in this file.
+VERSION: version
+ echo $(VERSION) > $@
+
$(TAR_FILE):
if git tag -v $(VERSION) >/dev/null 2>&1; then \
ref=$(VERSION); \
@@ -280,6 +287,8 @@ notmuch_client_srcs = \
notmuch_client_modules = $(notmuch_client_srcs:.c=.o)
+notmuch.o: VERSION
+
notmuch: $(notmuch_client_modules) lib/libnotmuch.a util/libutil.a
parse-time-string/libparse-time-string.a
$(call quiet,CXX $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@
@@ -318,7 +327,7 @@ install-desktop:
desktop-file-install --mode 0644 --dir "$(DESTDIR)$(desktop_dir)"
notmuch.desktop
SRCS := $(SRCS) $(notmuch_client_srcs)
-CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc
+CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)
DISTCLEAN := $(DISTCLEAN) .first-build-message Makefile.config
--
1.8.5.3
[PATCH] emacs: initialize ido mode in notmuch-mua.el
On Sun, Jan 26 2014, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> How about doing it with defadvice with something like:
>>
>> (from http://comments.gmane.org/gmane.emacs.bugs/27856 one can notice
>> this happening with emacs 23.3 -- David can check whether 23.4 if
>> affected)
>
> It's fixed in 23.4
>
>>
>> (if (and (= emacs-major-version 23) (< emacs-minor-version 4))
>> (defadvice ido-completing-read (before notmuch-ido-mode-init activate)
>> (unless (ido-mode) (ido-mode t))
>> (ad-disable-advice 'ido-completing-read 'before
>> 'notmuch-ido-mode-init)))
>
> Advice always seems over complex to me, but maybe I'm just
> prejudiced/ignorant.
With defadvice we can keep "mainline code less messy and less hard to
maintain" ;) -- and only install the advice on versions that need it.
Also with defadvice the other use of ido-completing-read is covered.
> Can you decode/reverse-engineer the fix in
>
> http://permalink.gmane.org/gmane.emacs.bugs/41957
>
> ?
>
> Maybe the advice or whatever should call
>
>(ido-init-completion-maps)
>(add-hook 'minibuffer-setup-hook 'ido-minibuffer-setup)
>(add-hook 'choose-completion-string-functions
> 'ido-choose-completion-string))
>
> Although that looks worryingly permanent.
(emacs-version) -> 24.3.1
(describe-variable 'minibuffer-setup-hook)
-> (rfn-eshadow-setup-minibuffer minibuffer-history-isearch-setup
minibuffer-history-initialize)
(ido-completing-read "test" '("foo" "bar"))
(describe-variable 'minibuffer-setup-hook)
-> (ido-minibuffer-setup rfn-eshadow-setup-minibuffer
minibuffer-history-isearch-setup minibuffer-history-initialize)
SO, although permanent, consistent w/ newer emacs versions...
> d
Tomi
[RFC PATCH] configure: check for POSIX.1-2008 realpath(3) implementation.
On Sun, Jan 26 2014, David Bremner wrote:
> Tomi Ollila writes:
>> +#if POSIX_2008_REALPATH
>> filename = realpath (config->filename, NULL);
>> +#else
>> +/* compatibility with minor effort, not elegance, is the ruling factor
>> + in these (two) else branches... */
>> +char resolved_path[PATH_MAX];
>> +filename = realpath (config->filename, resolved_path);
>> +#endif
>
> I worry a bit about making the mainline code messier and harder to maintain,
> in order to
> accomodate an unknown number of targets without POSIX2008 realpath. Do
> we know how widespread this problem is? Is it just NetBSD?
>
> I looked at borrowing realpath from gnulib; it looks like it would be a
> bit of work as the least complicated version includes 3 other include
> files. But then the mainline code could be blisfully ignorant of the
> whole dispute.
We could also create
char * realpath2008 (const char * path, char * resolved_path)
{
if (resolved_path == NULL) {
resolved_path = malloc (MAX_PATH);
if (resolved_path == NULL)
return NULL;
}
return realpath (path, resolved_path);
}
And, in the case where NULL argument is accepted,
#define realpath2008(path, resolved_path) realpath(path, resolved_path)
(or an inline function to do the same)
In this case one is not totally ignorant to the whole dispute -- but
on the other hand, developer should be savvy about the potential
issues using realpath() function, and this might just ring the bell...
> d
Tomi
Bug: notmuch new chokes on dangling symlinks and quits
Dear notmuch developers, notmuch new quits operation if it hit's a dangling symlink: Error reading file /home/grfz/notmuch2/Mail/findex/cur/123456789.684055.mairix:2,: No such file or directory Note: A fatal error was encountered: Something went wrong trying to read or write a file Processed 85 total files in 1s (47 files/sec.) I consider this to be a bug. Instead notmuch should simply ignore the symlink. This is especially problematic while indexing a huge amount of mail the first time and notmuch hits the dangling symlink at an early stage of indexing. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
[PATCH] emacs: initialize ido mode in notmuch-mua.el
Tomi Ollila writes: > > (describe-variable 'minibuffer-setup-hook) > > -> (ido-minibuffer-setup rfn-eshadow-setup-minibuffer > minibuffer-history-isearch-setup minibuffer-history-initialize) > > SO, although permanent, consistent w/ newer emacs versions... > Yeah, the other hook is set permanently as well. So, do these three lines of code (in advice if you must ;) ) fix the problem? d
[PATCH 1/1] build: delete the default .SUFFIXES
Tomi Ollila writes: > All implicit rules in notmuch Makefiles are "pattern rules"; Deleting the > default suffixes (to support obsolete, old-fashioned "suffix rules") from > make reduces the output of 'make -d' by 40 to 90 percent, helping e.g. > debugging make problems. pushed. d
[PATCH] lib: update documentation for notmuch_database_get_directory
David Bremner writes: > Clarify that using the directory after destroying the corresponding > database is not permitted. > > This is implicit in the description of notmuch_database_destroy, but > it doesn't hurt to be explicit, and we do express similar "ownership" > relationships at other places in the docs. pushed, d
[PATCH 0/7] cli: notmuch new improvements
Jani Nikula writes: > Here's an assortment of notmuch new fixes, non-functional cleanups, and > the oft-requested --quiet option. > pushed. Would be nice to have a simple test for the --quiet option. d
Bug: notmuch new chokes on dangling symlinks and quits
Gregor Zattler writes: > > I consider this to be a bug. Instead notmuch should simply > ignore the symlink. > Since there is a test for specifically this behaviour, I'd have to say it's a design decision you don't agree with, not a bug ;). In any case, if there is just a few broken symlinks, and you want to ignore them, you can add them the ignore= line in .notmuch-config d
[RFC PATCH] configure: check for POSIX.1-2008 realpath(3) implementation.
Tomi Ollila writes:
>
> We could also create
>
> char * realpath2008 (const char * path, char * resolved_path)
> {
> if (resolved_path == NULL) {
> resolved_path = malloc (MAX_PATH);
> if (resolved_path == NULL)
> return NULL;
> }
> return realpath (path, resolved_path);
> }
>
I sent several private replies to Tomi this morning while being
sleepy. But they were not so great replies anyway.
What about implimenting a compat version of canonicalize_file_name ?
that function is a gnu extension, but since we only call realpath with a
NULL second argument, it might be slighltly simpler to test/google for.
d
[PATCH 1/3] emacs: add a function to heuristically test if the CLI is configured OK.
We cache the result so that we can call the function many places without worrying about the cost. --- emacs/notmuch-lib.el | 11 +++ 1 file changed, 11 insertions(+) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 2be409b..dcdfbdc 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -168,6 +168,17 @@ Otherwise the output will be returned" (notmuch-check-exit-status status (cons notmuch-command args) output) output))) +(defvar notmuch--cli-sane-p nil + "Cache whether the CLI seems to be configured sanely.") + +(defun notmuch-cli-sane-p () + "Return t if the cli seems to be configured sanely." + (unless notmuch--cli-sane-p +(let ((status (call-process notmuch-command nil nil nil + "config" "get" "user.primary_email"))) + (setq notmuch--cli-setup-p (= status 0 + notmuch--cli-sane-p) + (defun notmuch-version () "Return a string with the notmuch version number." (let ((long-string -- 1.8.5.2
[PATCH 2/3] emacs: add function notmuch-assert-cli-sane
If the CLI seems borked, signal an error, and log a suggestion for the user about how to recover. --- emacs/notmuch-lib.el | 7 +++ 1 file changed, 7 insertions(+) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index dcdfbdc..c195652 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -179,6 +179,13 @@ Otherwise the output will be returned" (setq notmuch--cli-setup-p (= status 0 notmuch--cli-sane-p) +(defun notmuch-assert-cli-sane () + (unless (notmuch-cli-sane-p) +(notmuch-logged-error + "notmuch cli seems misconfigured or unconfigured." +"Perhaps you haven't run \"notmuch setup\" yet? Try running this +on the command line, and then retry your notmuch command"))) + (defun notmuch-version () "Return a string with the notmuch version number." (let ((long-string -- 1.8.5.2
[PATCH 3/3] emacs: add notmuch-assert-cli-sane to notmuch-hello
This is meant to be the friendly entrypoint, so let's do something better than the mangled output described in id:5228989D.8030607 at fifthhorseman.net --- emacs/notmuch-hello.el | 1 + 1 file changed, 1 insertion(+) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 55c416a..7b3d76b 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -788,6 +788,7 @@ following: "Run notmuch and display saved searches, known tags, etc." (interactive) + (notmuch-assert-cli-sane) ;; This may cause a window configuration change, so if the ;; auto-refresh hook is already installed, avoid recursive refresh. (let ((notmuch-hello-auto-refresh nil)) -- 1.8.5.2
[PATCH] test: add basic tests for notmuch new --quiet option
This does not cover all the possible paths notmuch new could output
stuff, but it's better than nothing.
---
test/T050-new.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/test/T050-new.sh b/test/T050-new.sh
index f27423d..b7668ff 100755
--- a/test/T050-new.sh
+++ b/test/T050-new.sh
@@ -248,4 +248,19 @@ ln -s i_do_not_exist "${MAIL_DIR}"/broken_link
output=$(NOTMUCH_NEW 2>&1)
test_expect_equal "$output" "No new mail."
+test_begin_subtest "Quiet: No new mail."
+output=$(NOTMUCH_NEW --quiet)
+test_expect_equal "$output" ""
+
+test_begin_subtest "Quiet: new, removed and renamed messages."
+# new
+generate_message
+# deleted
+notmuch search --format=text0 --output=files --limit=1 '*' | xargs -0 rm
+# moved
+mkdir "${MAIL_DIR}"/moved_messages
+notmuch search --format=text0 --output=files --offset=1 --limit=1 '*' | xargs
-0 -I {} mv {} "${MAIL_DIR}"/moved_messages
+output=$(NOTMUCH_NEW --quiet)
+test_expect_equal "$output" ""
+
test_done
--
1.8.5.2
[PATCH] emacs: add a function to heuristically test if the CLI is configured OK.
We cache the result so that we can call the function many places without worrying about the cost. --- thanks to Tomi for catching the typos (uncommitted changes on my end). emacs/notmuch-lib.el | 11 +++ 1 file changed, 11 insertions(+) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 2be409b..140d760 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -168,6 +168,17 @@ Otherwise the output will be returned" (notmuch-check-exit-status status (cons notmuch-command args) output) output))) +(defvar notmuch--cli-sane-p nil + "Cache whether the CLI seems to be configured sanely.") + +(defun notmuch-cli-sane-p () + "Return t if the cli seems to be configured sanely." + (unless notmuch--cli-sane-p +(let ((status (call-process notmuch-command nil nil nil + "config" "get" "user.primary_email"))) + (setq notmuch--cli-sane-p (= status 0 + notmuch--cli-sane-p) + (defun notmuch-version () "Return a string with the notmuch version number." (let ((long-string -- 1.8.5.2
[PATCH] test: add basic tests for notmuch new --quiet option
LGTM +1.
Best wishes
Mark
On Sun, 26 Jan 2014, Jani Nikula wrote:
> This does not cover all the possible paths notmuch new could output
> stuff, but it's better than nothing.
> ---
> test/T050-new.sh | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/test/T050-new.sh b/test/T050-new.sh
> index f27423d..b7668ff 100755
> --- a/test/T050-new.sh
> +++ b/test/T050-new.sh
> @@ -248,4 +248,19 @@ ln -s i_do_not_exist "${MAIL_DIR}"/broken_link
> output=$(NOTMUCH_NEW 2>&1)
> test_expect_equal "$output" "No new mail."
>
> +test_begin_subtest "Quiet: No new mail."
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> +test_begin_subtest "Quiet: new, removed and renamed messages."
> +# new
> +generate_message
> +# deleted
> +notmuch search --format=text0 --output=files --limit=1 '*' | xargs -0 rm
> +# moved
> +mkdir "${MAIL_DIR}"/moved_messages
> +notmuch search --format=text0 --output=files --offset=1 --limit=1 '*' |
> xargs -0 -I {} mv {} "${MAIL_DIR}"/moved_messages
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> test_done
> --
> 1.8.5.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: initialize ido mode in notmuch-mua.el
I don't have anything older than 23.4 anymore so I am afraid I can't test. My recollection is that I upgraded to 23.4 the problem went away so I forgot about it. (I couldn't see easily what version of emacs debian stable has now as seemed to be called 45.) Best wishes Mark On Sat, 25 Jan 2014, David Bremner wrote: > Mark Walters writes: > >> ido-completing-read is used in notmuch-mua.el without any >> initialization. This should work but a bug (emacs bug #3247) in some >> emacs 23 versions (including 23.2.1 from Debian stable) causes emacs >> to get stuck in the mini-buffer. This tests to see if ido-mode has >> been initialized and if not calls it. This avoids the bug for these >> older versions of emacs. >> >> This is the only place that ido-completing-read is used so an alternative >> would be to replace ido-completing-read by completing-read but cworth >> expressed a preference for the ido version in >> id:"87wrhfvk6a.fsf at yoom.home.cworth. > > This patch was tagged wip, but then there was no progress ;). It still > applies cleanly, and doesn't seem to do any harm in emacs 23.4 nor > emacs24.3. I don't have 23.2 at hand but I guess Tomi or Mark can > confirm it actually fixes the bug there. > > I propose we either apply the patch or ::wontfix the bug. > > cheers, > > d
[PATCH] emacs: add a function to heuristically test if the CLI is configured OK.
This version LGTM +1. (Just for the record there was some discussion on irc about switching to the *notmuch errors* buffer but that is more complex and fragile so let's go with this simple and effective solution.) Best wishes Mark On Sun, 26 Jan 2014, David Bremner wrote: > We cache the result so that we can call the function many places > without worrying about the cost. > --- > thanks to Tomi for catching the typos (uncommitted changes on my end). > > emacs/notmuch-lib.el | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el > index 2be409b..140d760 100644 > --- a/emacs/notmuch-lib.el > +++ b/emacs/notmuch-lib.el > @@ -168,6 +168,17 @@ Otherwise the output will be returned" >(notmuch-check-exit-status status (cons notmuch-command args) output) >output))) > > +(defvar notmuch--cli-sane-p nil > + "Cache whether the CLI seems to be configured sanely.") > + > +(defun notmuch-cli-sane-p () > + "Return t if the cli seems to be configured sanely." > + (unless notmuch--cli-sane-p > +(let ((status (call-process notmuch-command nil nil nil > + "config" "get" "user.primary_email"))) > + (setq notmuch--cli-sane-p (= status 0 > + notmuch--cli-sane-p) > + > (defun notmuch-version () >"Return a string with the notmuch version number." >(let ((long-string > -- > 1.8.5.2 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: add a function to heuristically test if the CLI is configured OK.
On Sun, Jan 26 2014, David Bremner wrote: > We cache the result so that we can call the function many places > without worrying about the cost. > --- > thanks to Tomi for catching the typos (uncommitted changes on my end). Series LGTM. Tomi > > emacs/notmuch-lib.el | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el > index 2be409b..140d760 100644 > --- a/emacs/notmuch-lib.el > +++ b/emacs/notmuch-lib.el > @@ -168,6 +168,17 @@ Otherwise the output will be returned" >(notmuch-check-exit-status status (cons notmuch-command args) output) >output))) > > +(defvar notmuch--cli-sane-p nil > + "Cache whether the CLI seems to be configured sanely.") > + > +(defun notmuch-cli-sane-p () > + "Return t if the cli seems to be configured sanely." > + (unless notmuch--cli-sane-p > +(let ((status (call-process notmuch-command nil nil nil > + "config" "get" "user.primary_email"))) > + (setq notmuch--cli-sane-p (= status 0 > + notmuch--cli-sane-p) > + > (defun notmuch-version () >"Return a string with the notmuch version number." >(let ((long-string > -- > 1.8.5.2 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: initialize ido mode in notmuch-mua.el
On Sun, Jan 26 2014, Mark Walters wrote: > I don't have anything older than 23.4 anymore so I am afraid I can't > test. My recollection is that I upgraded to 23.4 the problem went away > so I forgot about it. Fine, I prepare and test the patch then ;/ Tomi > (I couldn't see easily what version of emacs debian stable has now as > seemed to be called 45.) > > Best wishes > > Mark
[PATCH 1/1] build: write VERSION file containing $(VERSION) string
Hi
I experimented with this and it didn't always seem to rebuild VERSION
when it should. Looking at the file .git/HEAD that just seems to be the
branch name not the commit id (unless in detached HEAD state)
This link
http://stackoverflow.com/questions/6526451/how-to-include-git-commit-number-into-a-c-executable
suggests adding .git/index to the VERSION depends.
I tested that and that does seem to work. It may mean that VERSION gets
rebuilt if you stash (for example) but that is probably not a big
problem.
Best wishes
Mark
On Sat, 25 Jan 2014, Tomi Ollila wrote:
> This version file will be as prerequisite to the target files
> that use the version info for some purpose, like printing
> it to the user to examine. The contents of the VERSION file
> is seldom read by the build system itself as the $(VERSION)
> variable has the same information.
> ---
> Makefile.local | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.local b/Makefile.local
> index c85e09c..1f876b3 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -22,6 +22,8 @@ VERSION:=$(shell cat ${srcdir}/version)
> ifeq ($(filter release release-message pre-release
> update-versions,$(MAKECMDGOALS)),)
> ifeq ($(IS_GIT),yes)
> VERSION:=$(shell git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e
> s/-/~/)
> +# Make the 'VERSION' file depend *also* on .git/HEAD in this case
> +VERSION: .git/HEAD
> endif
> endif
>
> @@ -69,6 +71,11 @@ ifeq ($(shell cat .first-build-message 2>/dev/null),)
> endif
> endif
>
> +# This VERSION file is used mostly for triggering other file remakes...
> +# This may get other dependency to .git/HEAD above in this file.
> +VERSION: version
> + echo $(VERSION) > $@
> +
> $(TAR_FILE):
> if git tag -v $(VERSION) >/dev/null 2>&1; then \
> ref=$(VERSION); \
> @@ -280,6 +287,8 @@ notmuch_client_srcs = \
>
> notmuch_client_modules = $(notmuch_client_srcs:.c=.o)
>
> +notmuch.o: VERSION
> +
> notmuch: $(notmuch_client_modules) lib/libnotmuch.a util/libutil.a
> parse-time-string/libparse-time-string.a
> $(call quiet,CXX $(CFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) -o $@
>
> @@ -318,7 +327,7 @@ install-desktop:
> desktop-file-install --mode 0644 --dir "$(DESTDIR)$(desktop_dir)"
> notmuch.desktop
>
> SRCS := $(SRCS) $(notmuch_client_srcs)
> -CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules)
> notmuch.elc
> +CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)
>
> DISTCLEAN := $(DISTCLEAN) .first-build-message Makefile.config
>
> --
> 1.8.5.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test: add basic tests for notmuch new --quiet option
On Sun, Jan 26 2014, Jani Nikula wrote:
> This does not cover all the possible paths notmuch new could output
> stuff, but it's better than nothing.
> ---
LGTM.
Tomi
> test/T050-new.sh | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/test/T050-new.sh b/test/T050-new.sh
> index f27423d..b7668ff 100755
> --- a/test/T050-new.sh
> +++ b/test/T050-new.sh
> @@ -248,4 +248,19 @@ ln -s i_do_not_exist "${MAIL_DIR}"/broken_link
> output=$(NOTMUCH_NEW 2>&1)
> test_expect_equal "$output" "No new mail."
>
> +test_begin_subtest "Quiet: No new mail."
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> +test_begin_subtest "Quiet: new, removed and renamed messages."
> +# new
> +generate_message
> +# deleted
> +notmuch search --format=text0 --output=files --limit=1 '*' | xargs -0 rm
> +# moved
> +mkdir "${MAIL_DIR}"/moved_messages
> +notmuch search --format=text0 --output=files --offset=1 --limit=1 '*' |
> xargs -0 -I {} mv {} "${MAIL_DIR}"/moved_messages
> +output=$(NOTMUCH_NEW --quiet)
> +test_expect_equal "$output" ""
> +
> test_done
> --
> 1.8.5.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Bug?: notmuch-search-show-thread shows several threads; only one containing matching messages
Hi David, * David Bremner [24. Jan. 2014]: > Mark Walters writes: >> I have looked at this and I think this is not notmuch's fault: I think >> it is a mua doing strange things: >> >> One of the mails has an in-reply-to header which looks like >> >> In-reply-to: Message from Carsten Dominik of >> "Tue, 15 Mar 2011 12:18:51 BST." >> <17242340-A14F-495A-B144-20C96D52B620 at gmail.com> >> >> and I think notmuch is taking the carsten.dominik at gmail.com as message >> id. >> > > Can someone test if this is fixed by cf8aaafbad68 (i.e. does the problem > persist in git master or 0.17)? The problem is *not* fixed. I was the one who reported this problem two years ago. I did the same notmuch search again. Since I did no know if it's important with which version the emails were indexed I did a full index with notmuch 0.17+40~gecbb29e. I still have the mbox produced with notmuch show two years ago. Viewed with mutt (1) I see 206 messages in 7 threads (number of lines after collapse-all) (notmuch emacs show showed three threads then). One of the threads is the one I searched for. Today I produced another mbox with the very same command but with a now larger email corpus freshly indexed with a fresh notmuch. The mbox contains (according to mutt) 507 messages in 34 threads. One of them is the thread I searched for. I grepped for the 7 subjects within the 34 subjects and only 5 showed up. Only 17 of the 507 messages arrived since the problem report two years ago. If somebody want's to dig into this: I can provide the two mboxes. Disclaimer: Many of the emails which arrived before the problem report are not the exact same than then, because since the I mangled them with a script. This should have not changed the threading but I cannot be 100% sure. But if it's important for further investigation I'm probably able to reproduce the status quo of the email corpus then from my backups. Thanks for your persistence. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.-
Bug?: notmuch-search-show-thread shows several threads; only one containing matching messages
Gregor Zattler writes: > Today I produced another mbox with the very same command but with > a now larger email corpus freshly indexed with a fresh notmuch. > The mbox contains (according to mutt) 507 messages in 34 threads. > One of them is the thread I searched for. > > I grepped for the 7 subjects within the 34 subjects and only 5 > showed up. I don't know what you mean here. Grepped where? in the raw messages? > If somebody want's to dig into this: I can provide the two > mboxes. > > Disclaimer: Many of the emails which arrived before the problem > report are not the exact same than then, because since the I > mangled them with a script. This should have not changed the > threading but I cannot be 100% sure. But if it's important for > further investigation I'm probably able to reproduce the status > quo of the email corpus then from my backups. If it's currently not working then I guess your current corpus should be fine. It would probably help to restate what exactly is wrong. There was a lot of discussion, and the concrete problem I saw identified (in id:874nvcekjk.fsf at qmul.ac.uk ) was that certain malformed In-reply-to headers were causing unrelated threads to merge. d
