[PATCH v3] 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.
---
diffdiff to v2
-CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc
+CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)
Makefile.local | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/Makefile.local b/Makefile.local
index 174506c..9293ed1 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -21,7 +21,8 @@ endif
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/-/~/)
+# Also write VERSION file in case its contents differ from $(VERSION)
+VERSION:=$(shell gv=`exec git describe --match '[0-9.]*'|sed -e s/_/~/ -e
s/-/+/ -e s/-/~/`; test -f VERSION || touch VERSION; read fv < VERSION; test
x"$$fv" = x"$$gv" || echo "$$gv" > VERSION; echo "$$gv")
endif
endif
@@ -69,6 +70,11 @@ ifeq ($(shell cat .first-build-message 2>/dev/null),)
endif
endif
+# Depend (also) on 'version' file. In case of ifeq ($(IS_GIT),yes)
+# this file may already have been updated.
+VERSION: version
+ echo $(VERSION) > version
+
$(TAR_FILE):
if git tag -v $(VERSION) >/dev/null 2>&1; then \
ref=$(VERSION); \
@@ -280,6 +286,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 +326,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.0
[PATCH v2] 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.
---
This is version 2 of id:1390689800-16654-1-git-send-email-tomi.ollila at iki.fi
in case of IS_GIT = yes, the contents of file VERSION is compared what
git describe returns and if this differs then VERSION file is updated.
Makefile.local | 10 +-
diff --git a/Makefile.local b/Makefile.local
index c85e09c..96f39be 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -21,7 +21,8 @@ endif
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/-/~/)
+# Also write VERSION file in case its contents differ from $(VERSION)
+VERSION:=$(shell gv=`exec git describe --match '[0-9.]*'|sed -e s/_/~/ -e
s/-/+/ -e s/-/~/`; test -f VERSION || touch VERSION; read fv < VERSION; test
x"$$fv" = x"$$gv" || echo "$$gv" > VERSION; echo "$$gv")
endif
endif
@@ -69,6 +70,11 @@ ifeq ($(shell cat .first-build-message 2>/dev/null),)
endif
endif
+# Depend (also) on 'version' file. In case of ifeq ($(IS_GIT),yes)
+# this file may already have been updated.
+VERSION: version
+ echo $(VERSION) > version
+
$(TAR_FILE):
if git tag -v $(VERSION) >/dev/null 2>&1; then \
ref=$(VERSION); \
@@ -280,6 +286,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 $@
--
1.8.4.2
[PATCH 1/1] emacs: ad-activate 'mm-shr after ad-disable-advice 'mm-shr
Imitated from "Enabling advice" in Emacs lisp manual... ad-disable-advice by itself only changes the enable flag for a piece of advice. To make the change take effect in the advised definition, the advice needs to be activated again. --- emacs/notmuch-lib.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index e6e9f97..fa35fa9 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -531,7 +531,8 @@ the given type." (if (>= emacs-major-version 24) (defadvice mm-shr (before load-gnus-arts activate) (require 'gnus-art nil t) - (ad-disable-advice 'mm-shr 'before 'load-gnus-arts))) + (ad-disable-advice 'mm-shr 'before 'load-gnus-arts) + (ad-activate 'mm-shr))) (defun notmuch-mm-display-part-inline (msg part nth content-type process-crypto) "Use the mm-decode/mm-view functions to display a part in the -- 1.8.0
[PATCH 1/1] emacs: initialize ido(-completing-read) in emacs 23.[123]
Otherwise `ido-completing-read' will freeze after PROMPT is displayed. --- I tested this on emacs 23.1 & 24.3. I also tested this by adding (sit-for 2.0) inside the advice -- this lead to the addition of (ad-activate 'ido-completing-read (*)). (*) http://lists.gnu.org/archive/html/emacs-pretest-bug/2003-02/msg00087.html emacs/notmuch-mua.el | 13 + 1 file changed, 13 insertions(+) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 00cd980..481abd7 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -287,6 +287,19 @@ the From: header is already filled in by notmuch." (defvar notmuch-mua-sender-history nil) +;; Workaround: Running `ido-completing-read' in emacs 23.1, 23.2 and 23.3 +;; without some explicit initialization fill freeze the operation. +;; Hence, we advice `ido-completing-read' to ensure required initialization +;; is done. +(if (and (= emacs-major-version 23) (< emacs-minor-version 4)) +(defadvice ido-completing-read (before notmuch-ido-mode-init activate) + (ido-init-completion-maps) + (add-hook 'minibuffer-setup-hook 'ido-minibuffer-setup) + (add-hook 'choose-completion-string-functions + 'ido-choose-completion-string) + (ad-disable-advice 'ido-completing-read 'before 'notmuch-ido-mode-init) + (ad-activate 'ido-completing-read))) + (defun notmuch-mua-prompt-for-sender () (interactive) (let (name addresses one-name-only) -- 1.8.0
[PATCH v3] build: write VERSION file containing $(VERSION) string
Tomi Ollila writes: > +VERSION:=$(shell gv=`exec git describe --match '[0-9.]*'|sed -e s/_/~/ -e > s/-/+/ -e s/-/~/`; test -f VERSION || touch VERSION; read fv < VERSION; test > x"$$fv" = x"$$gv" || echo "$$gv" > VERSION; echo "$$gv") does this need to be one line long? It's a bit scary. > +# this file may already have been updated. > +VERSION: version > + echo $(VERSION) > version I'd prefer the build process does not change any version controlled file. It should be source, or generated, but not both. did you mean to write to VERSION here? d
[PATCH] compat: add canonicalize_file_name
On Mon, Jan 27 2014, David Bremner wrote: > the POSIX 2008 behaviour of realpath is not available everywhere so we > provide a simple wrapper function. We use (and provide) the gnu > extension canonicalize_file_name to make it cleaner to test for the > feature we need; otherwise we have to rely on realpath segfaulting if > the second argument is null. > --- I think this patch is tolerable. I first thought we should check the combination of not having canonicalize_file_name() and having POSIX 2008 behaviour of realpath()... ... but the compat code is simple enough and basically done the same way as in (e.g.) http://svnweb.freebsd.org/base/release/9.2.0/lib/libc/stdlib/realpath.c?revision=255898=markup qualifying the implementation. So +1 from me. Tomi > compat/Makefile.local| 4 > compat/canonicalize_file_name.c | 18 ++ > compat/compat.h | 8 > compat/have_canonicalize_file_name.c | 10 ++ > configure| 16 > notmuch-config.c | 2 +- > 6 files changed, 57 insertions(+), 1 deletion(-) > create mode 100644 compat/canonicalize_file_name.c > create mode 100644 compat/have_canonicalize_file_name.c >
mm-image-fit-p: Invalid image specification
On Sat, Jan 25 2014, David Bremner wrote:
> Michal Sojka writes:
>
>> Hello,
>>
>> in emacs, I have a problem displaying an email that contain the
>> following part (--format=json):
>>
>> {
>>"content-type" : "image/svg+xml",
>>"filename" : "_logo.svg",
>>"id" : 4
>> }
>>
>> I see this message "mm-image-fit-p: Invalid image specification" and no
>> other emails after this one in the thread are shown. This happens in GNU
>> Emacs 24.2.1 (Debian). Emacs 23 works correctly.
>>
>
> Hi Michal;
>
> I just tried to duplicate this old bug on emacs 24.3 and I couldn't. Can
> you still duplicate it?
Hi David,
I've found the problematic message and everything works correctly now.
> If so, a test message would be appreciated. I think if it's 24.2.1
> specific, we can call it fixed.
Maybe it was 24.2.1 specific or Emacs didn't use --format=sexp at that
time.
Thanks for taking care of this.
-Michal
Unexpected search results
Paul Melis writes: > Hi, > > How exactly does the search function work when it comes to things like > searching in the from or subject field? See the below queries and (lack > of) results: > > paulmlocal at sara11006:/data$ notmuch search from:dem > paulmlocal at sara11006:/data$ notmuch search from:demi > paulmlocal at sara11006:/data$ notmuch search from:demiu > paulmlocal at sara11006:/data$ notmuch search from:demiur > paulmlocal at sara11006:/data$ notmuch search from:demiurg > thread:00012d53 January 18 [1/5] Demiurg HG| Paul Melis, X > thread:00011b82 November 14 [3/6] Demiurg HG| Paul Melis; X > > Only the last queries returns the mails I was looking for, while > prefixes of the query don't return anything. Even stranger is that the > actual from e-mail address is demiurghg at , so why does "from:demiurg" > match (which is also a prefix of the mail address), but all the other > don't match? I guess it has to do with the mysteries of stemming. There is some information at http://notmuchmail.org/searching/ In your case, it would probably help to try notmuch search from:"demi*" Note that the * only works at the end.
Bug?: notmuch-search-show-thread shows several threads; only one containing matching messages
On Sun, 26 Jan 2014 22:26:04 +0100, Gregor Zattler wrote: > 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've never been happy with notmuch's threading, always seem to get too many threads, so I tend to do notmuch show --format=mbox \ $(notmuch search --output=threads -- whatever) | mhonarc -tlevels 15 - to work out which threads I want (I am not an emacs user!). mhonarc, as far as I know, uses something like the jwz algorithm ( http://http://www.jwz.org/doc/threading.html), the use of which would solve my problem but possibly not Gregor's. If that is indeed caused by the header referred to above and there is some email client which does that, it would need special handling in jwz and probably in any algorithm, but the maintainers of the mail client should also be told to fix it! (RFC2822) Digression I know, but I just wanted to flag the need for more work in general on threading in notmuch. Eric -- ms fnd in a lbry
Bug: notmuch new chokes on dangling symlinks and quits
On Mon, 27 Jan 2014 02:14:27 +0100, Gregor Zattler wrote: > 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? I have no idea what went on with such a decision, but, from the outside: 1) A dangling symlink should probably be handled in the same way as an unreadable file, but would need a separate test because it is a separate condition. 2) A dangling symlink should not be a normal condition anywhere, why do you have them? 3) I am even more amazed that there should be a dangling symlink in a Maildir tree. > > > 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. Eric -- ms fnd in a lbry
Bug: notmuch new chokes on dangling symlinks and quits
Gregor Zattler writes: > 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? > Purely from memory (I wasn't involved, and didn't dig up the the discussion): - a common use case is linking different trees into one notmuch-index tree. - if a subtree disappears (e.g. by a network failure), then the choices are stop the index or ignore the missing files. - in the latter case, all tags from "deleted" messages are lost So, a simple solution which avoids data loss is to abort the index process. A more complicated solution would be possible of course, but nobody proposed it (or more importantly, did it) yet. d
Unexpected search results
Hi, How exactly does the search function work when it comes to things like searching in the from or subject field? See the below queries and (lack of) results: paulmlocal at sara11006:/data$ notmuch search from:dem paulmlocal at sara11006:/data$ notmuch search from:demi paulmlocal at sara11006:/data$ notmuch search from:demiu paulmlocal at sara11006:/data$ notmuch search from:demiur paulmlocal at sara11006:/data$ notmuch search from:demiurg thread:00012d53 January 18 [1/5] Demiurg HG| Paul Melis, X thread:00011b82 November 14 [3/6] Demiurg HG| Paul Melis; X Only the last queries returns the mails I was looking for, while prefixes of the query don't return anything. Even stranger is that the actual from e-mail address is demiurghg at , so why does "from:demiurg" match (which is also a prefix of the mail address), but all the other don't match? Thanks for a great tool, btw! Regards, Paul -- ** SURFsara heeft een nieuw algemeen telefoonnummer: 020 800 1300 ** Paul Melis | Groepsleider & Adviseur Visualisatie | SURFsara | | Science Park 140 | 1098 XG Amsterdam | | T 020 592 30 59 | paul.melis at surfsara.nl | www.surfsara.nl |
[PATCH] compat: add canonicalize_file_name
the POSIX 2008 behaviour of realpath is not available everywhere so we
provide a simple wrapper function. We use (and provide) the gnu
extension canonicalize_file_name to make it cleaner to test for the
feature we need; otherwise we have to rely on realpath segfaulting if
the second argument is null.
---
compat/Makefile.local| 4
compat/canonicalize_file_name.c | 18 ++
compat/compat.h | 8
compat/have_canonicalize_file_name.c | 10 ++
configure| 16
notmuch-config.c | 2 +-
6 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644 compat/canonicalize_file_name.c
create mode 100644 compat/have_canonicalize_file_name.c
diff --git a/compat/Makefile.local b/compat/Makefile.local
index b0d5417..bcb9f0e 100644
--- a/compat/Makefile.local
+++ b/compat/Makefile.local
@@ -5,6 +5,10 @@ extra_cflags += -I$(srcdir)/$(dir)
notmuch_compat_srcs :=
+ifneq ($(HAVE_CANONICALIZE_FILE_NAME),1)
+notmuch_compat_srcs += $(dir)/canonicalize_file_name.c
+endif
+
ifneq ($(HAVE_GETLINE),1)
notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
endif
diff --git a/compat/canonicalize_file_name.c b/compat/canonicalize_file_name.c
new file mode 100644
index 000..e92c0f6
--- /dev/null
+++ b/compat/canonicalize_file_name.c
@@ -0,0 +1,18 @@
+#include "compat.h"
+#include
+#undef _GNU_SOURCE
+#include
+
+char *
+canonicalize_file_name (const char * path)
+{
+#ifdef PATH_MAX
+char *resolved_path = malloc (PATH_MAX+1);
+if (resolved_path == NULL)
+ return NULL;
+
+return realpath (path, resolved_path);
+#else
+#error undefined PATH_MAX _and_ missing canonicalize_file_name not supported
+#endif
+}
diff --git a/compat/compat.h b/compat/compat.h
index 5a402d5..634d505 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -37,6 +37,14 @@ extern "C" {
#define _POSIX_PTHREAD_SEMANTICS 1
#endif
+#if !HAVE_CANONICALIZE_FILE_NAME
+/* we only call this function from C, and this makes testing easier */
+#ifndef __cplusplus
+char *
+canonicalize_file_name (const char *path);
+#endif
+#endif
+
#if !HAVE_GETLINE
#include
#include
diff --git a/compat/have_canonicalize_file_name.c
b/compat/have_canonicalize_file_name.c
new file mode 100644
index 000..24c848e
--- /dev/null
+++ b/compat/have_canonicalize_file_name.c
@@ -0,0 +1,10 @@
+#define _GNU_SOURCE
+#include
+
+int main()
+{
+char *found;
+char *string;
+
+found = canonicalize_file_name (string);
+}
diff --git a/configure b/configure
index 13b6062..5b7c941 100755
--- a/configure
+++ b/configure
@@ -526,6 +526,18 @@ EOF
exit 1
fi
+printf "Checking for canonicalize_file_name... "
+if ${CC} -o compat/have_canonicalize_file_name
"$srcdir"/compat/have_canonicalize_file_name.c > /dev/null 2>&1
+then
+printf "Yes.\n"
+have_canonicalize_file_name=1
+else
+printf "No (will use our own instead).\n"
+have_canonicalize_file_name=0
+fi
+rm -f compat/have_canonicalize_file_name
+
+
printf "Checking for getline... "
if ${CC} -o compat/have_getline "$srcdir"/compat/have_getline.c > /dev/null
2>&1
then
@@ -751,6 +763,10 @@ zsh_completion_dir =
${ZSHCOMLETIONDIR:=\$(prefix)/share/zsh/functions/Completio
# Whether the getline function is available (if not, then notmuch will
# build its own version)
+HAVE_CANONICALIZE_FILE_NAME = ${have_canonicalize_file_name}
+
+# Whether the getline function is available (if not, then notmuch will
+# build its own version)
HAVE_GETLINE = ${have_getline}
# Whether the strcasestr function is available (if not, then notmuch will
diff --git a/notmuch-config.c b/notmuch-config.c
index 8d28653..4886d36 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -454,7 +454,7 @@ notmuch_config_save (notmuch_config_t *config)
}
/* Try not to overwrite symlinks. */
-filename = realpath (config->filename, NULL);
+filename = canonicalize_file_name (config->filename);
if (! filename) {
if (errno == ENOENT) {
filename = strdup (config->filename);
--
1.8.5.2
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=2cK+A at 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 emacs mode could be friendlier when the user has never run "notmuch setup"
Daniel Kahn Gillmor writes: > At the very least, the error message could say "please run 'notmuch > setup' from a shell". This is implimented in git commit 1c2f2c960c (with the patch series in this thread), and will be part of notmuch 0.18. So far I only added the assert to notmuch-hello (also known as M-x notmuch), but it would be easy to add to other entry-points if people think it's a good idea. > > The current behavior (notmuch and notmuch-emacs 0.16-1 on debian) is to > open a *notmuch-hello* buffer that says : > > Welcome to notmuch. You have > > And in the minibuffer, a message says "notmuch exited with status 1" >
[PATCH] test: add basic tests for notmuch new --quiet option
Jani Nikula writes: > This does not cover all the possible paths notmuch new could output > stuff, but it's better than nothing. pushed. really, honest. d
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.fsf at 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 -- -... --- .-. . -.. ..--.. ...-.-
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 -- -... --- .-. . -.. ..--.. ...-.-
Re: [PATCH] test: add basic tests for notmuch new --quiet option
Jani Nikula j...@nikula.org writes: This does not cover all the possible paths notmuch new could output stuff, but it's better than nothing. pushed. really, honest. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch emacs mode could be friendlier when the user has never run notmuch setup
Daniel Kahn Gillmor d...@fifthhorseman.net writes: At the very least, the error message could say please run 'notmuch setup' from a shell. This is implimented in git commit 1c2f2c960c (with the patch series in this thread), and will be part of notmuch 0.18. So far I only added the assert to notmuch-hello (also known as M-x notmuch), but it would be easy to add to other entry-points if people think it's a good idea. The current behavior (notmuch and notmuch-emacs 0.16-1 on debian) is to open a *notmuch-hello* buffer that says : Welcome to notmuch. You have And in the minibuffer, a message says notmuch exited with status 1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] compat: add canonicalize_file_name
the POSIX 2008 behaviour of realpath is not available everywhere so we
provide a simple wrapper function. We use (and provide) the gnu
extension canonicalize_file_name to make it cleaner to test for the
feature we need; otherwise we have to rely on realpath segfaulting if
the second argument is null.
---
compat/Makefile.local| 4
compat/canonicalize_file_name.c | 18 ++
compat/compat.h | 8
compat/have_canonicalize_file_name.c | 10 ++
configure| 16
notmuch-config.c | 2 +-
6 files changed, 57 insertions(+), 1 deletion(-)
create mode 100644 compat/canonicalize_file_name.c
create mode 100644 compat/have_canonicalize_file_name.c
diff --git a/compat/Makefile.local b/compat/Makefile.local
index b0d5417..bcb9f0e 100644
--- a/compat/Makefile.local
+++ b/compat/Makefile.local
@@ -5,6 +5,10 @@ extra_cflags += -I$(srcdir)/$(dir)
notmuch_compat_srcs :=
+ifneq ($(HAVE_CANONICALIZE_FILE_NAME),1)
+notmuch_compat_srcs += $(dir)/canonicalize_file_name.c
+endif
+
ifneq ($(HAVE_GETLINE),1)
notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
endif
diff --git a/compat/canonicalize_file_name.c b/compat/canonicalize_file_name.c
new file mode 100644
index 000..e92c0f6
--- /dev/null
+++ b/compat/canonicalize_file_name.c
@@ -0,0 +1,18 @@
+#include compat.h
+#include limits.h
+#undef _GNU_SOURCE
+#include stdlib.h
+
+char *
+canonicalize_file_name (const char * path)
+{
+#ifdef PATH_MAX
+char *resolved_path = malloc (PATH_MAX+1);
+if (resolved_path == NULL)
+ return NULL;
+
+return realpath (path, resolved_path);
+#else
+#error undefined PATH_MAX _and_ missing canonicalize_file_name not supported
+#endif
+}
diff --git a/compat/compat.h b/compat/compat.h
index 5a402d5..634d505 100644
--- a/compat/compat.h
+++ b/compat/compat.h
@@ -37,6 +37,14 @@ extern C {
#define _POSIX_PTHREAD_SEMANTICS 1
#endif
+#if !HAVE_CANONICALIZE_FILE_NAME
+/* we only call this function from C, and this makes testing easier */
+#ifndef __cplusplus
+char *
+canonicalize_file_name (const char *path);
+#endif
+#endif
+
#if !HAVE_GETLINE
#include stdio.h
#include unistd.h
diff --git a/compat/have_canonicalize_file_name.c
b/compat/have_canonicalize_file_name.c
new file mode 100644
index 000..24c848e
--- /dev/null
+++ b/compat/have_canonicalize_file_name.c
@@ -0,0 +1,10 @@
+#define _GNU_SOURCE
+#include stdlib.h
+
+int main()
+{
+char *found;
+char *string;
+
+found = canonicalize_file_name (string);
+}
diff --git a/configure b/configure
index 13b6062..5b7c941 100755
--- a/configure
+++ b/configure
@@ -526,6 +526,18 @@ EOF
exit 1
fi
+printf Checking for canonicalize_file_name...
+if ${CC} -o compat/have_canonicalize_file_name
$srcdir/compat/have_canonicalize_file_name.c /dev/null 21
+then
+printf Yes.\n
+have_canonicalize_file_name=1
+else
+printf No (will use our own instead).\n
+have_canonicalize_file_name=0
+fi
+rm -f compat/have_canonicalize_file_name
+
+
printf Checking for getline...
if ${CC} -o compat/have_getline $srcdir/compat/have_getline.c /dev/null
21
then
@@ -751,6 +763,10 @@ zsh_completion_dir =
${ZSHCOMLETIONDIR:=\$(prefix)/share/zsh/functions/Completio
# Whether the getline function is available (if not, then notmuch will
# build its own version)
+HAVE_CANONICALIZE_FILE_NAME = ${have_canonicalize_file_name}
+
+# Whether the getline function is available (if not, then notmuch will
+# build its own version)
HAVE_GETLINE = ${have_getline}
# Whether the strcasestr function is available (if not, then notmuch will
diff --git a/notmuch-config.c b/notmuch-config.c
index 8d28653..4886d36 100644
--- a/notmuch-config.c
+++ b/notmuch-config.c
@@ -454,7 +454,7 @@ notmuch_config_save (notmuch_config_t *config)
}
/* Try not to overwrite symlinks. */
-filename = realpath (config-filename, NULL);
+filename = canonicalize_file_name (config-filename);
if (! filename) {
if (errno == ENOENT) {
filename = strdup (config-filename);
--
1.8.5.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: notmuch new chokes on dangling symlinks and quits
On Mon, 27 Jan 2014 02:14:27 +0100, Gregor Zattler telegr...@gmx.net wrote: Hi David, * David Bremner da...@tethera.net [26. Jan. 2014]: Gregor Zattler telegr...@gmx.net 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? I have no idea what went on with such a decision, but, from the outside: 1) A dangling symlink should probably be handled in the same way as an unreadable file, but would need a separate test because it is a separate condition. 2) A dangling symlink should not be a normal condition anywhere, why do you have them? 3) I am even more amazed that there should be a dangling symlink in a Maildir tree. 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. Eric -- ms fnd in a lbry ___ 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
On Sun, 26 Jan 2014 22:26:04 +0100, Gregor Zattler telegr...@gmx.net wrote: Hi David, * David Bremner da...@tethera.net [24. Jan. 2014]: Mark Walters markwalters1...@gmail.com 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 carsten.domi...@gmail.com 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've never been happy with notmuch's threading, always seem to get too many threads, so I tend to do notmuch show --format=mbox \ $(notmuch search --output=threads -- whatever) | mhonarc -tlevels 15 - to work out which threads I want (I am not an emacs user!). mhonarc, as far as I know, uses something like the jwz algorithm ( http://http://www.jwz.org/doc/threading.html), the use of which would solve my problem but possibly not Gregor's. If that is indeed caused by the header referred to above and there is some email client which does that, it would need special handling in jwz and probably in any algorithm, but the maintainers of the mail client should also be told to fix it! (RFC2822) Digression I know, but I just wanted to flag the need for more work in general on threading in notmuch. Eric -- ms fnd in a lbry ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Bug: notmuch new chokes on dangling symlinks and quits
Gregor Zattler telegr...@gmx.net writes: Hi David, * David Bremner da...@tethera.net [26. Jan. 2014]: Gregor Zattler telegr...@gmx.net 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? Purely from memory (I wasn't involved, and didn't dig up the the discussion): - a common use case is linking different trees into one notmuch-index tree. - if a subtree disappears (e.g. by a network failure), then the choices are stop the index or ignore the missing files. - in the latter case, all tags from deleted messages are lost So, a simple solution which avoids data loss is to abort the index process. A more complicated solution would be possible of course, but nobody proposed it (or more importantly, did it) yet. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] compat: add canonicalize_file_name
On Mon, Jan 27 2014, David Bremner da...@tethera.net wrote: the POSIX 2008 behaviour of realpath is not available everywhere so we provide a simple wrapper function. We use (and provide) the gnu extension canonicalize_file_name to make it cleaner to test for the feature we need; otherwise we have to rely on realpath segfaulting if the second argument is null. --- I think this patch is tolerable. I first thought we should check the combination of not having canonicalize_file_name() and having POSIX 2008 behaviour of realpath()... ... but the compat code is simple enough and basically done the same way as in (e.g.) http://svnweb.freebsd.org/base/release/9.2.0/lib/libc/stdlib/realpath.c?revision=255898view=markup qualifying the implementation. So +1 from me. Tomi compat/Makefile.local| 4 compat/canonicalize_file_name.c | 18 ++ compat/compat.h | 8 compat/have_canonicalize_file_name.c | 10 ++ configure| 16 notmuch-config.c | 2 +- 6 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 compat/canonicalize_file_name.c create mode 100644 compat/have_canonicalize_file_name.c ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: mm-image-fit-p: Invalid image specification
On Sat, Jan 25 2014, David Bremner wrote:
Michal Sojka sojk...@fel.cvut.cz writes:
Hello,
in emacs, I have a problem displaying an email that contain the
following part (--format=json):
{
content-type : image/svg+xml,
filename : _logo.svg,
id : 4
}
I see this message mm-image-fit-p: Invalid image specification and no
other emails after this one in the thread are shown. This happens in GNU
Emacs 24.2.1 (Debian). Emacs 23 works correctly.
Hi Michal;
I just tried to duplicate this old bug on emacs 24.3 and I couldn't. Can
you still duplicate it?
Hi David,
I've found the problematic message and everything works correctly now.
If so, a test message would be appreciated. I think if it's 24.2.1
specific, we can call it fixed.
Maybe it was 24.2.1 specific or Emacs didn't use --format=sexp at that
time.
Thanks for taking care of this.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/1] emacs: initialize ido(-completing-read) in emacs 23.[123]
Otherwise `ido-completing-read' will freeze after PROMPT is displayed. --- I tested this on emacs 23.1 24.3. I also tested this by adding (sit-for 2.0) inside the advice -- this lead to the addition of (ad-activate 'ido-completing-read (*)). (*) http://lists.gnu.org/archive/html/emacs-pretest-bug/2003-02/msg00087.html emacs/notmuch-mua.el | 13 + 1 file changed, 13 insertions(+) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 00cd980..481abd7 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -287,6 +287,19 @@ the From: header is already filled in by notmuch. (defvar notmuch-mua-sender-history nil) +;; Workaround: Running `ido-completing-read' in emacs 23.1, 23.2 and 23.3 +;; without some explicit initialization fill freeze the operation. +;; Hence, we advice `ido-completing-read' to ensure required initialization +;; is done. +(if (and (= emacs-major-version 23) ( emacs-minor-version 4)) +(defadvice ido-completing-read (before notmuch-ido-mode-init activate) + (ido-init-completion-maps) + (add-hook 'minibuffer-setup-hook 'ido-minibuffer-setup) + (add-hook 'choose-completion-string-functions + 'ido-choose-completion-string) + (ad-disable-advice 'ido-completing-read 'before 'notmuch-ido-mode-init) + (ad-activate 'ido-completing-read))) + (defun notmuch-mua-prompt-for-sender () (interactive) (let (name addresses one-name-only) -- 1.8.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/1] emacs: ad-activate 'mm-shr after ad-disable-advice 'mm-shr
Imitated from Enabling advice in Emacs lisp manual... ad-disable-advice by itself only changes the enable flag for a piece of advice. To make the change take effect in the advised definition, the advice needs to be activated again. --- emacs/notmuch-lib.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index e6e9f97..fa35fa9 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -531,7 +531,8 @@ the given type. (if (= emacs-major-version 24) (defadvice mm-shr (before load-gnus-arts activate) (require 'gnus-art nil t) - (ad-disable-advice 'mm-shr 'before 'load-gnus-arts))) + (ad-disable-advice 'mm-shr 'before 'load-gnus-arts) + (ad-activate 'mm-shr))) (defun notmuch-mm-display-part-inline (msg part nth content-type process-crypto) Use the mm-decode/mm-view functions to display a part in the -- 1.8.0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] 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.
---
This is version 2 of id:1390689800-16654-1-git-send-email-tomi.oll...@iki.fi
in case of IS_GIT = yes, the contents of file VERSION is compared what
git describe returns and if this differs then VERSION file is updated.
Makefile.local | 10 +-
diff --git a/Makefile.local b/Makefile.local
index c85e09c..96f39be 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -21,7 +21,8 @@ endif
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/-/~/)
+# Also write VERSION file in case its contents differ from $(VERSION)
+VERSION:=$(shell gv=`exec git describe --match '[0-9.]*'|sed -e s/_/~/ -e
s/-/+/ -e s/-/~/`; test -f VERSION || touch VERSION; read fv VERSION; test
x$$fv = x$$gv || echo $$gv VERSION; echo $$gv)
endif
endif
@@ -69,6 +70,11 @@ ifeq ($(shell cat .first-build-message 2/dev/null),)
endif
endif
+# Depend (also) on 'version' file. In case of ifeq ($(IS_GIT),yes)
+# this file may already have been updated.
+VERSION: version
+ echo $(VERSION) version
+
$(TAR_FILE):
if git tag -v $(VERSION) /dev/null 21; then \
ref=$(VERSION); \
@@ -280,6 +286,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 $@
--
1.8.4.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v3] 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.
---
diffdiff to v2
-CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) notmuch.elc
+CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)
Makefile.local | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/Makefile.local b/Makefile.local
index 174506c..9293ed1 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -21,7 +21,8 @@ endif
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/-/~/)
+# Also write VERSION file in case its contents differ from $(VERSION)
+VERSION:=$(shell gv=`exec git describe --match '[0-9.]*'|sed -e s/_/~/ -e
s/-/+/ -e s/-/~/`; test -f VERSION || touch VERSION; read fv VERSION; test
x$$fv = x$$gv || echo $$gv VERSION; echo $$gv)
endif
endif
@@ -69,6 +70,11 @@ ifeq ($(shell cat .first-build-message 2/dev/null),)
endif
endif
+# Depend (also) on 'version' file. In case of ifeq ($(IS_GIT),yes)
+# this file may already have been updated.
+VERSION: version
+ echo $(VERSION) version
+
$(TAR_FILE):
if git tag -v $(VERSION) /dev/null 21; then \
ref=$(VERSION); \
@@ -280,6 +286,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 +326,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.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected search results
Paul Melis paul.me...@surfsara.nl writes: Hi, How exactly does the search function work when it comes to things like searching in the from or subject field? See the below queries and (lack of) results: paulmlocal@sara11006:/data$ notmuch search from:dem paulmlocal@sara11006:/data$ notmuch search from:demi paulmlocal@sara11006:/data$ notmuch search from:demiu paulmlocal@sara11006:/data$ notmuch search from:demiur paulmlocal@sara11006:/data$ notmuch search from:demiurg thread:00012d53 January 18 [1/5] Demiurg HG| Paul Melis, X thread:00011b82 November 14 [3/6] Demiurg HG| Paul Melis; X Only the last queries returns the mails I was looking for, while prefixes of the query don't return anything. Even stranger is that the actual from e-mail address is demiurghg@, so why does from:demiurg match (which is also a prefix of the mail address), but all the other don't match? I guess it has to do with the mysteries of stemming. There is some information at http://notmuchmail.org/searching/ In your case, it would probably help to try notmuch search from:demi* Note that the * only works at the end. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3] build: write VERSION file containing $(VERSION) string
Tomi Ollila tomi.oll...@iki.fi writes: +VERSION:=$(shell gv=`exec git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e s/-/~/`; test -f VERSION || touch VERSION; read fv VERSION; test x$$fv = x$$gv || echo $$gv VERSION; echo $$gv) does this need to be one line long? It's a bit scary. +# this file may already have been updated. +VERSION: version + echo $(VERSION) version I'd prefer the build process does not change any version controlled file. It should be source, or generated, but not both. did you mean to write to VERSION here? d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
