Enabling and disabling maildir.synchronize_flags

2015-07-01 Thread dm-list-email-notm...@scs.stanford.edu
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

2015-07-01 Thread J. Lewis Muir
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

2015-07-01 Thread David Bremner
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

2015-07-01 Thread Mark Walters
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

2015-07-01 Thread J. Lewis Muir
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

2015-07-01 Thread dm-list-email-notmuch
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

2015-07-01 Thread David Bremner
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