Enabling and disabling maildir.synchronize_flags
Sorry if this question is answered somewhere, but I'm wondering: What is the best way to enable and disable maildir.synchronize_flags? It seems that disabling it should simply be safe. But re-enabling, one risks losing tags, as the next notmuch new will cause old maildir flags to override the xapian database. So that suggests something like: notmuch dump > backup notmuch config set maildir.synchronize_flags false # Do I need to run notmuch new here? notmuch restore < backup Is that safe? The man page suggests one additionally need to run notmuch new before running notmuch restore. All of this is pretty slow. Is there a more efficient way? A one or two sentence clarification in the notmuch-config man page might be helpful to people contemplating playing with this switch. The default is on, to I suspect it costs a lot of performance. I've been afraid to turn it off for fear that I won't be able to undo this cleanly. Thanks, David
[PATCH] build: Support Mac OS X 10.6.8
On 6/30/15 4:29 PM, Nate Eagleson wrote:
> +# Mac OS X 10.6 has a built-in libutil.dylib that prevents ld from
> +# picking up notmuch's libutil.a. The best way to prefer our local
> +# libutil.a is to specify it via absolute path, which should work on
> +# all supported OSes.
> +LIBUTIL_PATH=${srcdir}/util/libutil.a
Hi, Nate.
I think it would be better to make the above comment not specific to OS
X, but instead just refer to "systems that have a built-in util library"
or similar. For example, NetBSD has a built-in util library [1]. I
don't have access to a FreeBSD system, but it looks like FreeBSD might
have a built-in util library too [2].
Similarly for the one-line commit summary since this change is not
specific to OS X.
Regards,
Lewis
[1] http://netbsd.gw.com/cgi-bin/man-cgi?libutil++NetBSD-current
[2] http://svnweb.freebsd.org/base/head/lib/libutil/Makefile?view=markup
[PATCH] build: Support Mac OS X 10.6.8
Nate Eagleson writes:
> OS X 10.6.8 has a built-in library named libutil.dylib and a version
> of ld that picks that up instead of util/libutil.a.
>
> We now use an absolute path to util/libutil.a, so that notmuch can be
> built successfully on 10.6.8.
I'd like a one line subject that mentions libutil.a and perhaps
"absolute path"
>
> +# Mac OS X 10.6 has a built-in libutil.dylib that prevents ld from
> +# picking up notmuch's libutil.a. The best way to prefer our local
> +# libutil.a is to specify it via absolute path, which should work on
> +# all supported OSes.
> +LIBUTIL_PATH=${srcdir}/util/libutil.a
> +
This needs to be relative to ${dir}, not ${srcdir} in order not to break
out of tree builds. You can test with
% mkdir -p /tmp/foo-build
% cd /tmp/foo-build
% ~/projects/notmuch/configure && make
Also, one Makefile gotcha is that anything using $(dir) should use :=
rather than = to force immediate expansion.
Cheers,
David
[PATCH] emacs: show: let the user override the mime-type of an attachment
This allows the user to override the mime-type of a part in the show buffer. This takes the simple option of displaying the part with the specified mime-type in its own buffer (in view mode). This avoids further complicating the part handling code. Bound to ". m" (i.e., m in the part map). Then the user can either enter a mime-type or press return for the default choice of text/plain. --- Jani and dkg suggested something like this on irc. As mentioned in the commit message I have taken the simpler option of displaying the part in its own buffer: the part handling with lazy parts and hidden parts etc is really very complicated and fragile so I do not think it sensible to complicate it further for a relatively uncommon use case. It would be nice to have some completions for the mime-type but that could always be added later. Best wishes Mark emacs/notmuch-show.el | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2a53461..c674e9c 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1354,6 +1354,7 @@ reset based on the original query." (define-key map "v" 'notmuch-show-view-part) (define-key map "o" 'notmuch-show-interactively-view-part) (define-key map "|" 'notmuch-show-pipe-part) +(define-key map "m" 'notmuch-show-choose-mime-of-part) (define-key map "?" 'notmuch-subkeymap-help) map) "Submap for part commands") @@ -2243,25 +2244,27 @@ omit --in-reply-to=." (insert (notmuch-get-bodypart-binary msg part process-crypto))) buf)) -(defun notmuch-show-current-part-handle () +(defun notmuch-show-current-part-handle ( mime-type) "Return an mm-handle for the part containing point. This creates a temporary buffer for the part's content; the -caller is responsible for killing this buffer as appropriate." +caller is responsible for killing this buffer as appropriate. If +MIME-TYPE is given then set the handle's mime-type to MIME-TYPE." (let* ((msg (notmuch-show-get-message-properties)) (part (notmuch-show-get-part-properties)) (buf (notmuch-show-generate-part-buffer msg part)) -(computed-type (plist-get part :computed-type)) +(computed-type (or mime-type (plist-get part :computed-type))) (filename (plist-get part :filename)) (disposition (if filename `(attachment (filename . ,filename) (mm-make-handle buf (list computed-type) nil nil disposition))) -(defun notmuch-show-apply-to-current-part-handle (fn) +(defun notmuch-show-apply-to-current-part-handle (fn mime-type) "Apply FN to an mm-handle for the part containing point. This ensures that the temporary buffer created for the mm-handle -is destroyed when FN returns." - (let ((handle (notmuch-show-current-part-handle))) +is destroyed when FN returns. If MIME-TYPE is given then force +part to be treated as if it had that mime-type." + (let ((handle (notmuch-show-current-part-handle mime-type))) ;; emacs 24.3+ puts stdout/stderr into the calling buffer so we ;; call it from a temp-buffer, unless ;; notmuch-show-attachment-debug is non-nil in which case we put @@ -2306,4 +2309,24 @@ is destroyed when FN returns." (notmuch-show-apply-to-current-part-handle #'mm-pipe-part)) +(defun notmuch-show-internal-mm-display-part (handle) + "Use mm-display-part to display HANDLE in a new buffer. + +If the part is displayed in an external application then close +the new buffer." + (let ((buf (get-buffer-create (generate-new-buffer-name +(concat " *notmuch-internal-part*") +(switch-to-buffer buf) +(if (eq (mm-display-part handle) 'external) + (kill-buffer buf) + (goto-char (point-min)) + (set-buffer-modified-p nil) + (view-buffer buf 'kill-buffer-if-not-modified + +(defun notmuch-show-choose-mime-of-part (mime-type) + "Choose the mime type to use for displaying part" + (interactive + (list (read-string "Mime type to use (default text/plain): " nil nil "text/plain"))) + (notmuch-show-apply-to-current-part-handle #'notmuch-show-internal-mm-display-part mime-type)) + (provide 'notmuch-show) -- 2.1.4
Re: [PATCH] build: Support Mac OS X 10.6.8
On 6/30/15 4:29 PM, Nate Eagleson wrote:
+# Mac OS X 10.6 has a built-in libutil.dylib that prevents ld from
+# picking up notmuch's libutil.a. The best way to prefer our local
+# libutil.a is to specify it via absolute path, which should work on
+# all supported OSes.
+LIBUTIL_PATH=${srcdir}/util/libutil.a
Hi, Nate.
I think it would be better to make the above comment not specific to OS
X, but instead just refer to systems that have a built-in util library
or similar. For example, NetBSD has a built-in util library [1]. I
don't have access to a FreeBSD system, but it looks like FreeBSD might
have a built-in util library too [2].
Similarly for the one-line commit summary since this change is not
specific to OS X.
Regards,
Lewis
[1] http://netbsd.gw.com/cgi-bin/man-cgi?libutil++NetBSD-current
[2] http://svnweb.freebsd.org/base/head/lib/libutil/Makefile?view=markup
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Enabling and disabling maildir.synchronize_flags
Sorry if this question is answered somewhere, but I'm wondering: What is the best way to enable and disable maildir.synchronize_flags? It seems that disabling it should simply be safe. But re-enabling, one risks losing tags, as the next notmuch new will cause old maildir flags to override the xapian database. So that suggests something like: notmuch dump backup notmuch config set maildir.synchronize_flags false # Do I need to run notmuch new here? notmuch restore backup Is that safe? The man page suggests one additionally need to run notmuch new before running notmuch restore. All of this is pretty slow. Is there a more efficient way? A one or two sentence clarification in the notmuch-config man page might be helpful to people contemplating playing with this switch. The default is on, to I suspect it costs a lot of performance. I've been afraid to turn it off for fear that I won't be able to undo this cleanly. Thanks, David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] build: Support Mac OS X 10.6.8
Nate Eagleson n...@nateeag.com writes:
OS X 10.6.8 has a built-in library named libutil.dylib and a version
of ld that picks that up instead of util/libutil.a.
We now use an absolute path to util/libutil.a, so that notmuch can be
built successfully on 10.6.8.
I'd like a one line subject that mentions libutil.a and perhaps
absolute path
+# Mac OS X 10.6 has a built-in libutil.dylib that prevents ld from
+# picking up notmuch's libutil.a. The best way to prefer our local
+# libutil.a is to specify it via absolute path, which should work on
+# all supported OSes.
+LIBUTIL_PATH=${srcdir}/util/libutil.a
+
This needs to be relative to ${dir}, not ${srcdir} in order not to break
out of tree builds. You can test with
% mkdir -p /tmp/foo-build
% cd /tmp/foo-build
% ~/projects/notmuch/configure make
Also, one Makefile gotcha is that anything using $(dir) should use :=
rather than = to force immediate expansion.
Cheers,
David
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
