[notmuch] [PATCH] emacs: Move emacs UI (currently just one file) to subdirectory.

[da...@tethera.net]

From: David Bremner 

Add emacs/Makefile.local and emacs/Makefile. Move emacs targets into
emacs/Makefile.local, but leave the byte compilation rule in the top
level Makefile.

---

I decided to put the actual targets for byte compilation and installation in
emacs/Makefile.local. This seems more modular to me.

 Makefile   |1 +
 Makefile.local |   10 --
 emacs/Makefile |7 +++
 emacs/Makefile.local   |   19 +++
 notmuch.el => emacs/notmuch.el |0
 5 files changed, 27 insertions(+), 10 deletions(-)
 create mode 100644 emacs/Makefile
 create mode 100644 emacs/Makefile.local
 rename notmuch.el => emacs/notmuch.el (100%)

diff --git a/Makefile b/Makefile
index 64b9d4a..bd8f50a 100644
--- a/Makefile
+++ b/Makefile
@@ -38,6 +38,7 @@ include Makefile.config

 include lib/Makefile.local
 include compat/Makefile.local
+include emacs/Makefile.local
 include Makefile.local

 # The user has not set any verbosity, default to quiet mode and inform the
diff --git a/Makefile.local b/Makefile.local
index 04bac83..8431eba 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -1,5 +1,3 @@
-emacs: notmuch.elc
-
 notmuch_client_srcs =  \
$(notmuch_compat_srcs)  \
debugger.c  \
@@ -35,14 +33,6 @@ install: all notmuch.1.gz
install notmuch $(DESTDIR)$(prefix)/bin/
install -m0644 notmuch.1.gz $(DESTDIR)$(prefix)/share/man/man1/

-install-emacs: install emacs
-   for d in $(DESTDIR)/$(emacs_lispdir) ; \
-   do \
-   install -d $$d ; \
-   done ;
-   install -m0644 notmuch.el $(DESTDIR)$(emacs_lispdir)
-   install -m0644 notmuch.elc $(DESTDIR)$(emacs_lispdir)
-
 install-desktop:
install -d $(DESTDIR)$(desktop_dir)
desktop-file-install --mode 0644 --dir $(DESTDIR)$(desktop_dir) 
notmuch.desktop
diff --git a/emacs/Makefile b/emacs/Makefile
new file mode 100644
index 000..b6859ea
--- /dev/null
+++ b/emacs/Makefile
@@ -0,0 +1,7 @@
+# See Makfefile.local for the list of files to be compiled in this
+# directory.
+all:
+   $(MAKE) -C .. all
+
+.DEFAULT:
+   $(MAKE) -C .. $@
diff --git a/emacs/Makefile.local b/emacs/Makefile.local
new file mode 100644
index 000..c6ca142
--- /dev/null
+++ b/emacs/Makefile.local
@@ -0,0 +1,19 @@
+dir=emacs
+emacs_sources= \
+   $(dir)/notmuch.el
+
+emacs_bytecode=$(subst .el,.elc,$(emacs_sources))
+
+emacs: $(emacs_bytecode)
+
+install-emacs: install emacs
+   for d in $(DESTDIR)/$(emacs_lispdir) ; \
+   do \
+   install -d $$d ; \
+   done ;
+   for f in $(emacs_sources) $(emacs_bytecode); \
+   do \
+   install -m0644 $$f $(DESTDIR)$(emacs_lispdir) ;\
+   done;
+
+CLEAN := $(CLEAN) $(emacs_bytecode)
diff --git a/notmuch.el b/emacs/notmuch.el
similarity index 100%
rename from notmuch.el
rename to emacs/notmuch.el
-- 
1.6.5

[notmuch] Notmuch performance problems on OSX

[Oliver Charles]

On Tue, Feb 9, 2010 at 10:09 PM, Olly Betts  wrote:
> On 2010-02-09, Oliver Charles wrote:
>> I just upgraded to xapian-core HEAD and notmuch master tip today, in
>> desparation to get away from GMail. Sadly it's still taking at least
>> 0.7s to tag a single thread (with one message). I'm really eager to
>> solve this, could anyone give me any pointers on how I could go about
>> profiling it or finding the cause of this problem?
>
> The first thing to try is disabling use of F_FULLFSYNC.  You'll need to
> run this command in the xapian-core source tree to comment out the F_FULLFSYNC
> code:
>
> perl -pi -e 's/^#ifdef F_FULLFSYNC/#if 0/' backends/*/*_io.h
>
> Then run "make" and "make install".

$ time notmuch tag +inbox thread:6e66368b7887184c6d4c63653211b3f2

real0m0.067s
user0m0.036s
sys 0m0.028s

Now this looks a little bit more usable!

> Assuming that helps, then (a) you have a workaround, and (b) we'll know for
> sure it is F_FULLFSYNC to blame.

Looks like this is the case.

> I've created a ticket for a change to Xapian which should help here, but
> not had a chance to work on it yet:
>
> http://trac.xapian.org/ticket/426

I will add my info there and follow the ticket if I can.

--
   Oliver Charles / aCiD2

(Olly, sorry about the double email - in all my excitement I didn't
hit reply all :))

[notmuch] viewing text/html (inline or otherwise)

[Keith Packard]

On Tue, 09 Feb 2010 16:22:56 -0800, Carl Worth  wrote:

> I know that Keith is using a little script he wrote so that he can hit
> '|' on a message and pipe it to his script. The script then uses a
> utility, (munpack?) to extract all the various MIME parts to a temporary
> directory and then run a web broswer on that directory. Perhaps Keith
> would be so kind as to share that script with the community here.

It's not much of a script, I call it 'view-html'

#!/bin/sh
dir=`mktemp -d`
trap "rm -r $dir" 0
cat "$@" > "$dir"/msg
if munpack -C "$dir" -t < "$dir"/msg 2>&1 | grep 'Did not find'; then
sed -n '/[Hh][Tt][Mm][Ll]/,$p' "$dir"/msg > $dir/part1.html
rm "$dir"/msg
fi
for i in "$dir"/part*; do
if grep -q -i -e '' -e 'text/html' "$i"; then
iceweasel "$i" &
sleep 3
exit 0
fi
done

Note that if iceweasel isn't already running, it seems to shut down when
the script exits. I don't know why.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100209/24edf42b/attachment.pgp>

[notmuch] Notmuch performance problems on OSX

[Olly Betts]

On 2010-02-09, Oliver Charles wrote:
> I just upgraded to xapian-core HEAD and notmuch master tip today, in
> desparation to get away from GMail. Sadly it's still taking at least
> 0.7s to tag a single thread (with one message). I'm really eager to
> solve this, could anyone give me any pointers on how I could go about
> profiling it or finding the cause of this problem?

The first thing to try is disabling use of F_FULLFSYNC.  You'll need to
run this command in the xapian-core source tree to comment out the F_FULLFSYNC
code:

perl -pi -e 's/^#ifdef F_FULLFSYNC/#if 0/' backends/*/*_io.h

Then run "make" and "make install".

This makes you a bit more vulnerable to power failures, but no worse than
a typical Unix system.  There's some background here:

http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html

Assuming that helps, then (a) you have a workaround, and (b) we'll know for
sure it is F_FULLFSYNC to blame.

I've created a ticket for a change to Xapian which should help here, but
not had a chance to work on it yet:

http://trac.xapian.org/ticket/426

Cheers,
Olly

[notmuch] viewing text/html (inline or otherwise)

[Alex Ghitza]

Dear Notmuch folks,

I've been using notmuch exclusively (or almost, see below) for the past
couple of months and it is absolutely fabulous!  It also keeps getting
better for me, due for instance to the improved speed from the xapian
bug #250 being fixed, and Jesse and Jamie's code for setting Fcc (which
is working like a charm for me).

There were still two typical occasions when I needed to resort to
logging into Gmail: (a) to look at attachments and (b) to read html
mail.  Tonight, after some searching, I managed to get my emacs to do
(a), and it would be really sweet if I could also do (b) from notmuch in
emacs.  It's such a basic thing that I'm sure everybody else has it
figured out; in fact, I resisted the temptation to be lazy and ask about
this for quite some time, but nothing that I tried got me very far.  (To
be specific, my latest attempt involved w3m, and now when I press 'v'
within a message that has a text/html part, I see "Rendering... done"
followed by "Fontifying... done", but then nothing.)

Ideally, I'd like to be able to see what's hidden behind the 
"Non-text part: text/html", and if it could happen inline that would be
great.  I would also entertain the idea of opening an external browser
window, if that's the way this has to go.

Back in the days when I was using mutt, this could be done by adding
something like:

  in .muttrc:
  auto_view text/html

  in .mailcap:
  text/html; lynx -dump %s ; copiousoutput ; nametemplate=%s.html

Is something like this possible in notmuch+emacs?  (The alternative is
that I get procmail to send all html mail back to sender with a request
to resend as plain text, but most of the culprits won't know what I'm
talking about.)


Best,
Alex

-- 
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/

[notmuch] Notmuch performance problems on OSX

[Oliver Charles]

I just upgraded to xapian-core HEAD and notmuch master tip today, in
desparation to get away from GMail. Sadly it's still taking at least
0.7s to tag a single thread (with one message). I'm really eager to
solve this, could anyone give me any pointers on how I could go about
profiling it or finding the cause of this problem?
-- 
Oliver Charles / aCiD2

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Jed Brown]

On Tue, 09 Feb 2010 11:19:54 -0800, Carl Worth  wrote:
> I did verify the above in a copy of WG14/N1124. For anyone that doesn't
> recognize that, that's the draft from the C99 working group that I've
> been told is remarkably similar to C99 but distinct in that it's freely
> available[*]. I haven't verified the similarity, but I have found that
> document quite useful in cases like this one.

This one is more recent (TC3):

  http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

I don't know the legality of this copy:

  http://www.ishiboo.com/~danny/c++/C_STANDARD-ISOIEC9899-1999.pdf


Jed

[notmuch] Problems with Maildir and files moving from new/ to cur/

[Michal Sojka]

On Tue, 9 Feb 2010 10:38:04 -0500, Brett Viren  wrote:
> Hi,
> 
> I use procmail to prefilter mail into various sub groups of a Maildir.
>  This Maildir is served by dovecot IMAP and is also visible to
> notmuch.  I run "notmuch new" followed by "notmuch tag -inbox -unread
> tag:inbox" (I use GNUS to do my reading and don't want these tags in
> the way the few times I run notmuch for reading) every 10 minutes from
> cron.  I often will check my email before the cron job gets a chance
> to run and vice versa.
> 
> The problem I have is that this race condition means that sometimes
> notmuch will index a message as being under the Maildir/./new/
> subdirectory, I then read it and it is moved to Maildir/./cur/
> (I think that is what is happening).  Then when I do a search, notmuch
> returns a file that is no longer around.
> 
> This may not be an issue with notmuch, per se, but does anyone have
> any suggestions to make this work more smoothly?

Hi,

I'm afraid that with current version there is no solution for this.
There were some proposals to tell notmuch which files you want to index
and use this functionality to run indexing right on delivery on when a
rename is detected (e.g. by inotify). See
id:1264719647-sup-9540 at ben-laptop for details. AFAIK nobody have sent
patches for this yet.

Cheers,
Michal

[notmuch] [PATCH] Reintroduce HTML inlining, with a much needed optimization

[Carl Worth]

On Tue,  9 Feb 2010 17:55:21 -0800, Alexander Botero-Lowry  wrote:
> Now instead of requiring every single message be parsed, we now check
> the Content-type in the parsed headers and only do HTML inlining if it's
> text/html

Excellent! I've pushed this out now. Greatly appreciated.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100209/fc1d6686/attachment.pgp>

[notmuch] [PATCH] Reintroduce HTML inlining, with a much needed optimization

[Alexander Botero-Lowry]

Now instead of requiring every single message be parsed, we now check
the Content-type in the parsed headers and only do HTML inlining if it's
text/html
---
 notmuch.el |   54 --
 1 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6f69001..b49d4d1 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -133,6 +133,8 @@ remaining lines into a button.")
 (defvar notmuch-show-id-regexp "\\(id:[^ ]*\\)")
 (defvar notmuch-show-depth-match-regexp " depth:\\([0-9]*\\).*match:\\([01]\\) 
")
 (defvar notmuch-show-filename-regexp "filename:\\(.*\\)$")
+(defvar notmuch-show-contentype-regexp "Content-type: \\(.*\\)")
+
 (defvar notmuch-show-tags-regexp "(\\([^)]*\\))$")

 (defvar notmuch-show-parent-buffer nil)
@@ -713,20 +715,44 @@ is what to put on the button."
 (defun notmuch-show-markup-part (beg end depth)
   (if (re-search-forward notmuch-show-part-begin-regexp nil t)
   (progn
-   (forward-line)
-   (let ((beg (point-marker)))
- (re-search-forward notmuch-show-part-end-regexp)
- (let ((end (copy-marker (match-beginning 0
-   (goto-char end)
-   (if (not (bolp))
-   (insert "\n"))
-   (indent-rigidly beg end depth)
-   (notmuch-show-markup-citations-region beg end depth)
-   ; Advance to the next part (if any) (so the outer loop can
-   ; determine whether we've left the current message.
-   (if (re-search-forward notmuch-show-part-begin-regexp nil t)
-   (beginning-of-line)
-(goto-char end)))
+(let (mime-message mime-type)
+  (save-excursion
+(re-search-forward notmuch-show-contentype-regexp end t)
+(setq mime-type (car (split-string (buffer-substring 
+(match-beginning 1) (match-end 
1))
+
+  (if (equal mime-type "text/html")
+  (let ((filename (notmuch-show-get-filename)))
+(with-temp-buffer
+  (insert-file-contents filename nil nil nil t)
+  (setq mime-message (mm-dissect-buffer)
+  (forward-line)
+  (let ((beg (point-marker)))
+(re-search-forward notmuch-show-part-end-regexp)
+(let ((end (copy-marker (match-beginning 0
+  (goto-char end)
+  (if (not (bolp))
+  (insert "\n"))
+  (indent-rigidly beg end depth)
+  (if (not (eq mime-message nil))
+  (save-excursion
+(goto-char beg)
+(forward-line -1)
+(let ((handle-type (mm-handle-type mime-message))
+  mime-type)
+  (if (sequencep (car handle-type))
+  (setq mime-type (car handle-type))
+(setq mime-type (car (car (cdr handle-type
+)
+  (if (equal mime-type "text/html")
+  (mm-display-part mime-message
+)
+  (notmuch-show-markup-citations-region beg end depth)
+  ; Advance to the next part (if any) (so the outer loop can
+  ; determine whether we've left the current message.
+  (if (re-search-forward notmuch-show-part-begin-regexp nil t)
+  (beginning-of-line)
+(goto-char end

 (defun notmuch-show-markup-parts-region (beg end depth)
   (save-excursion
-- 
1.6.5.2

[notmuch] viewing text/html (inline or otherwise)

[Alexander Botero-Lowry]

On Tue, 09 Feb 2010 16:22:56 -0800, Carl Worth  wrote:
> On Tue, 09 Feb 2010 21:28:25 +1100, Alex Ghitza  wrote:
> > Ideally, I'd like to be able to see what's hidden behind the 
> > "Non-text part: text/html", and if it could happen inline that would be
> > great.  I would also entertain the idea of opening an external browser
> > window, if that's the way this has to go.
> 
> We actually had some support for inline viewing of HTML message parts
> for a while. I reverted the code only because it was slowing down
> rendering of non-HTML messages. And I did that with the expectation that
> the code would appear again shortly with the obvious optimization to not
> do any extra work for non-HTML messages.
EBUSY...

I'll get around to it, I continue to run ancient notmuch with my patch
still in place though because I find it basically unuseable without it,
so I hope to get some free time to pull the change back up and add the
optimization (which is to check the type of the mime part before trying
to do an mm-display-parts on it, so that you save the time of the
dissection if it's not needed).

alex

[notmuch] Problems with Maildir and files moving from new/ to cur/

[Carl Worth]

On Tue, 9 Feb 2010 10:38:04 -0500, Brett Viren  wrote:
> The problem I have is that this race condition means that sometimes
> notmuch will index a message as being under the Maildir/./new/
> subdirectory, I then read it and it is moved to Maildir/./cur/
> (I think that is what is happening).  Then when I do a search, notmuch
> returns a file that is no longer around.

The problem here is due to some drifting assumptions.

When I made the "notmuch new" command, I was assuming a mailstore that
wouldn't change except for new messages being added, (such that it
likely wouldn't be inconvenient to run "notmuch new" when that mail was
added).

But now that we have support within notmuch for a mailstore that does
change, (with messages being deleted and renamed), then "notmuch new" is
too blunt a tool for what you want here.

One option would be to implement some new interface in notmuch for
indexing specific file paths. Then you could arrange for that to be
called when your mail client does the renaming, (either by modifying the
mail client itself or by hooking into something like inotify).

> This may not be an issue with notmuch, per se, but does anyone have
> any suggestions to make this work more smoothly?

Otherwise, the only way I see for you to get the behavior you want
without having to write any new code is to just run "notmuch new;
notmuch search " whenever you want to search. That's not ideal, but
might be a usable workaround for now as it would hopefully add just a
second or two to your search times.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100209/bb6640ca/attachment.pgp>

[notmuch] notmuch.el patch for older emacs

[James Vasile]

Emacs22 lacks apply-partially and mouse-event-p, so define them if
emacs version is less than 23.  With this change, I was able to begin
using notmuch in emacs22.

apply-partially cribbed from 
http://notmuchmail.org/pipermail/notmuch/2009/000889.html



diff --git a/notmuch.el b/notmuch.el
index 97914f2..03b17f6 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -51,6 +51,21 @@
 (require 'mm-view)
 (require 'message)

+;; Old emacs lacks apply-partially and mouse-event-p
+(when (<= emacs-major-version 23)
+  (defun apply-partially (fun  args)
+  "Return a function that is a partial application of FUN to ARGS.
+ARGS is a list of the first N arguments to pass to FUN.
+The result is a new function which does the same as FUN, except that
+the first N arguments are fixed at the values with which this function
+was called."
+  (lexical-let ((fun fun) (args1 args))
+(lambda ( args2) (apply fun (append args1 args2)
+
+  (defun mouse-event-p (object)
+  "Return non-nil if OBJECT is a mouse click event."
+  (memq (event-basic-type object) '(mouse-1 mouse-2 mouse-3 mouse-movement
+
 (defvar notmuch-show-mode-map
   (let ((map (make-sparse-keymap)))
 (define-key map "?" 'notmuch-help)

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Michal Sojka]

On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth  wrote:
> The sequential identifiers have the advantage of being guaranteed to
> be unique (until we overflow a 64-bit unsigned integer), and also take
> up half as much space in the "notmuch search" output (16 columns
> rather than 32).
>  [...]

On amd64 I get:
lib/database.cc: In function ?const char* 
_notmuch_database_generate_thread_id(notmuch_database_t*)?:
lib/database.cc:1309: warning: format ?%016llx? expects type ?long long 
unsigned int?, but argument 3 has type ?uint64_t?

What about the following? This could also fix Sebastian's problem.

 8< 
>From afcc07ae03ae40cf7e1c33d8632fba0a9fc0b4c8 Mon Sep 17 00:00:00 2001
From: Michal Sojka 
Date: Tue, 9 Feb 2010 15:35:39 +0100
Subject: [PATCH] Suppress warning on amd64

---
 lib/database.cc |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/lib/database.cc b/lib/database.cc
index 8641321..20a4c72 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -26,6 +26,9 @@
 #include 
 #include 

+#define __STDC_FORMAT_MACROS
+#include 
+
 #include  /* g_free, GPtrArray, GHashTable */

 using namespace std;
@@ -1306,7 +1309,7 @@ _notmuch_database_generate_thread_id (notmuch_database_t 
*notmuch)

 notmuch->last_thread_id++;

-sprintf (thread_id, "%016llx", notmuch->last_thread_id);
+sprintf (thread_id, "%016"PRIx64, notmuch->last_thread_id);

 db->set_metadata ("last_thread_id", thread_id);

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Sebastian Spaeth]

On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth  wrote:
> -NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/'
> +NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/'

Caught you not running your test suite before submitting v2 of a patch!
:-)

This still assumes the 20 digit thread ids.

Sebastian

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Carl Worth]

On Tue, 09 Feb 2010 11:35:39 +0100, "Sebastian Spaeth"  wrote:
> On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth  wrote:
> > -NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/'
> > +NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/'
> 
> Caught you not running your test suite before submitting v2 of a patch!
> :-)

Drat, I'm exposed.

And silly of me since this patch is what enables the test suite to
complete in less than 2 seconds now. So I really don't have any excuse
to not run it anymore.

Anyway, I do appreciate all the review. I haven't seen any complaints,
so I'll go ahead and push these changes out, (a version 3 including a
fix for the above...and which I *have* tested with the test suite).

-Carl

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100209/80071871/attachment.pgp>

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Carl Worth]

On Tue, 09 Feb 2010 15:40:00 +0100, Michal Sojka  wrote:
> What about the following? This could also fix Sebastian's problem.
...
> +#define __STDC_FORMAT_MACROS
> +#include 
...
> -sprintf (thread_id, "%016llx", notmuch->last_thread_id);
> +sprintf (thread_id, "%016"PRIx64, notmuch->last_thread_id);

Excellent! I did hesitate for a moment when typing "llx" into the format
string, but I had no idea what the correct thing to use was. I'm sure
glad to have access to such a knowledgeable community where I can learn
for the low cost of exposing my ignorance in public.

I did verify the above in a copy of WG14/N1124. For anyone that doesn't
recognize that, that's the draft from the C99 working group that I've
been told is remarkably similar to C99 but distinct in that it's freely
available[*]. I haven't verified the similarity, but I have found that
document quite useful in cases like this one.

Thanks for the fix. I'll likely push my change out now that I've added
this fix.

-Carl

[*] http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100209/96eeb688/attachment.pgp>

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Sebastian Spaeth]

On Tue, 09 Feb 2010 10:58:53 +0100, Sebastian Spaeth  
wrote:
> On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth  wrote:
> > diff --git a/lib/database-private.h b/lib/database-private.h
> ...
> > +
> > +uint64_t last_thread_id;
> 
> throws:
> lib/database-private.h:37: error: 'uint64_t' does not name a type

using "unsigned long long int" works fine though. I think gcc 4.4 does
not include stdint by default anymore in C++ or something...

[notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Sebastian Spaeth]

On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth  wrote:
> diff --git a/lib/database-private.h b/lib/database-private.h
...
> +
> +uint64_t last_thread_id;

throws:
lib/database-private.h:37: error: 'uint64_t' does not name a type


Is it just me, or have I made an error in applying this patch?

spaetz

[notmuch] Problems with Maildir and files moving from new/ to cur/

[Brett Viren]

Hi,

I use procmail to prefilter mail into various sub groups of a Maildir.
 This Maildir is served by dovecot IMAP and is also visible to
notmuch.  I run "notmuch new" followed by "notmuch tag -inbox -unread
tag:inbox" (I use GNUS to do my reading and don't want these tags in
the way the few times I run notmuch for reading) every 10 minutes from
cron.  I often will check my email before the cron job gets a chance
to run and vice versa.

The problem I have is that this race condition means that sometimes
notmuch will index a message as being under the Maildir/./new/
subdirectory, I then read it and it is moved to Maildir/./cur/
(I think that is what is happening).  Then when I do a search, notmuch
returns a file that is no longer around.

This may not be an issue with notmuch, per se, but does anyone have
any suggestions to make this work more smoothly?

Thanks,
-Brett.

Re: [notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Sebastian Spaeth]

On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth cwo...@cworth.org wrote:
 diff --git a/lib/database-private.h b/lib/database-private.h
...
 +
 +uint64_t last_thread_id;

throws:
lib/database-private.h:37: error: 'uint64_t' does not name a type


Is it just me, or have I made an error in applying this patch?

spaetz
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Sebastian Spaeth]

On Tue, 09 Feb 2010 10:58:53 +0100, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 On Mon, 08 Feb 2010 13:36:14 -0800, Carl Worth cwo...@cworth.org wrote:
  diff --git a/lib/database-private.h b/lib/database-private.h
 ...
  +
  +uint64_t last_thread_id;
 
 throws:
 lib/database-private.h:37: error: 'uint64_t' does not name a type

using unsigned long long int works fine though. I think gcc 4.4 does
not include stdint by default anymore in C++ or something...
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] viewing text/html (inline or otherwise)

[Alex Ghitza]

Dear Notmuch folks,

I've been using notmuch exclusively (or almost, see below) for the past
couple of months and it is absolutely fabulous!  It also keeps getting
better for me, due for instance to the improved speed from the xapian
bug #250 being fixed, and Jesse and Jamie's code for setting Fcc (which
is working like a charm for me).

There were still two typical occasions when I needed to resort to
logging into Gmail: (a) to look at attachments and (b) to read html
mail.  Tonight, after some searching, I managed to get my emacs to do
(a), and it would be really sweet if I could also do (b) from notmuch in
emacs.  It's such a basic thing that I'm sure everybody else has it
figured out; in fact, I resisted the temptation to be lazy and ask about
this for quite some time, but nothing that I tried got me very far.  (To
be specific, my latest attempt involved w3m, and now when I press 'v'
within a message that has a text/html part, I see Rendering... done
followed by Fontifying... done, but then nothing.)

Ideally, I'd like to be able to see what's hidden behind the 
Non-text part: text/html, and if it could happen inline that would be
great.  I would also entertain the idea of opening an external browser
window, if that's the way this has to go.

Back in the days when I was using mutt, this could be done by adding
something like:

  in .muttrc:
  auto_view text/html

  in .mailcap:
  text/html; lynx -dump %s ; copiousoutput ; nametemplate=%s.html

Is something like this possible in notmuch+emacs?  (The alternative is
that I get procmail to send all html mail back to sender with a request
to resend as plain text, but most of the culprits won't know what I'm
talking about.)


Best,
Alex

-- 
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Switch from random to sequential thread identifiers.

[Jed Brown]

On Tue, 09 Feb 2010 11:19:54 -0800, Carl Worth cwo...@cworth.org wrote:
 I did verify the above in a copy of WG14/N1124. For anyone that doesn't
 recognize that, that's the draft from the C99 working group that I've
 been told is remarkably similar to C99 but distinct in that it's freely
 available[*]. I haven't verified the similarity, but I have found that
 document quite useful in cases like this one.

This one is more recent (TC3):

  http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf

I don't know the legality of this copy:

  http://www.ishiboo.com/~danny/c++/C_STANDARD-ISOIEC9899-1999.pdf


Jed
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch performance problems on OSX

[Oliver Charles]

On Tue, Feb 9, 2010 at 10:09 PM, Olly Betts o...@survex.com wrote:
 On 2010-02-09, Oliver Charles wrote:
 I just upgraded to xapian-core HEAD and notmuch master tip today, in
 desparation to get away from GMail. Sadly it's still taking at least
 0.7s to tag a single thread (with one message). I'm really eager to
 solve this, could anyone give me any pointers on how I could go about
 profiling it or finding the cause of this problem?

 The first thing to try is disabling use of F_FULLFSYNC.  You'll need to
 run this command in the xapian-core source tree to comment out the F_FULLFSYNC
 code:

 perl -pi -e 's/^#ifdef F_FULLFSYNC/#if 0/' backends/*/*_io.h

 Then run make and make install.

$ time notmuch tag +inbox thread:6e66368b7887184c6d4c63653211b3f2

real0m0.067s
user0m0.036s
sys 0m0.028s

Now this looks a little bit more usable!

 Assuming that helps, then (a) you have a workaround, and (b) we'll know for
 sure it is F_FULLFSYNC to blame.

Looks like this is the case.

 I've created a ticket for a change to Xapian which should help here, but
 not had a chance to work on it yet:

 http://trac.xapian.org/ticket/426

I will add my info there and follow the ticket if I can.

--
   Oliver Charles / aCiD2

(Olly, sorry about the double email - in all my excitement I didn't
hit reply all :))
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] viewing text/html (inline or otherwise)

[Carl Worth]

On Tue, 09 Feb 2010 21:28:25 +1100, Alex Ghitza aghi...@gmail.com wrote:
 Ideally, I'd like to be able to see what's hidden behind the 
 Non-text part: text/html, and if it could happen inline that would be
 great.  I would also entertain the idea of opening an external browser
 window, if that's the way this has to go.

We actually had some support for inline viewing of HTML message parts
for a while. I reverted the code only because it was slowing down
rendering of non-HTML messages. And I did that with the expectation that
the code would appear again shortly with the obvious optimization to not
do any extra work for non-HTML messages.

I know that Keith is using a little script he wrote so that he can hit
'|' on a message and pipe it to his script. The script then uses a
utility, (munpack?) to extract all the various MIME parts to a temporary
directory and then run a web broswer on that directory. Perhaps Keith
would be so kind as to share that script with the community here.

What I'm doing write now is using 'V' to view the raw message and then
running eval-expression (by typing M-:) and then using:

(mm-display-parts (mm-dissect-buffer))

That isn't ideal because it leaves a bunch of the raw message around,
and leaves a buffer open with a modified version of a mail file in the
mailstore.

I'd definitely like a correct solution. Emacs definitely has no shortage
of already-existing code to parse and render HTML, (even with inline
images, etc.). We just need to find and hook things up properly.

-Carl


pgpsuALYHIXlD.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Problems with Maildir and files moving from new/ to cur/

[Carl Worth]

On Tue, 9 Feb 2010 10:38:04 -0500, Brett Viren brett.vi...@gmail.com wrote:
 The problem I have is that this race condition means that sometimes
 notmuch will index a message as being under the Maildir/.topic/new/
 subdirectory, I then read it and it is moved to Maildir/.topic/cur/
 (I think that is what is happening).  Then when I do a search, notmuch
 returns a file that is no longer around.

The problem here is due to some drifting assumptions.

When I made the notmuch new command, I was assuming a mailstore that
wouldn't change except for new messages being added, (such that it
likely wouldn't be inconvenient to run notmuch new when that mail was
added).

But now that we have support within notmuch for a mailstore that does
change, (with messages being deleted and renamed), then notmuch new is
too blunt a tool for what you want here.

One option would be to implement some new interface in notmuch for
indexing specific file paths. Then you could arrange for that to be
called when your mail client does the renaming, (either by modifying the
mail client itself or by hooking into something like inotify).

 This may not be an issue with notmuch, per se, but does anyone have
 any suggestions to make this work more smoothly?

Otherwise, the only way I see for you to get the behavior you want
without having to write any new code is to just run notmuch new;
notmuch search foo whenever you want to search. That's not ideal, but
might be a usable workaround for now as it would hopefully add just a
second or two to your search times.

-Carl


pgpdOFOwSkfTn.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] viewing text/html (inline or otherwise)

[Alexander Botero-Lowry]

On Tue, 09 Feb 2010 16:22:56 -0800, Carl Worth cwo...@cworth.org wrote:
 On Tue, 09 Feb 2010 21:28:25 +1100, Alex Ghitza aghi...@gmail.com wrote:
  Ideally, I'd like to be able to see what's hidden behind the 
  Non-text part: text/html, and if it could happen inline that would be
  great.  I would also entertain the idea of opening an external browser
  window, if that's the way this has to go.
 
 We actually had some support for inline viewing of HTML message parts
 for a while. I reverted the code only because it was slowing down
 rendering of non-HTML messages. And I did that with the expectation that
 the code would appear again shortly with the obvious optimization to not
 do any extra work for non-HTML messages.
EBUSY...

I'll get around to it, I continue to run ancient notmuch with my patch
still in place though because I find it basically unuseable without it,
so I hope to get some free time to pull the change back up and add the
optimization (which is to check the type of the mime part before trying
to do an mm-display-parts on it, so that you save the time of the
dissection if it's not needed).

alex
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Reintroduce HTML inlining, with a much needed optimization

[Alexander Botero-Lowry]

Now instead of requiring every single message be parsed, we now check
the Content-type in the parsed headers and only do HTML inlining if it's
text/html
---
 notmuch.el |   54 --
 1 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 6f69001..b49d4d1 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -133,6 +133,8 @@ remaining lines into a button.)
 (defvar notmuch-show-id-regexp \\(id:[^ ]*\\))
 (defvar notmuch-show-depth-match-regexp  depth:\\([0-9]*\\).*match:\\([01]\\) 
)
 (defvar notmuch-show-filename-regexp filename:\\(.*\\)$)
+(defvar notmuch-show-contentype-regexp Content-type: \\(.*\\))
+
 (defvar notmuch-show-tags-regexp (\\([^)]*\\))$)
 
 (defvar notmuch-show-parent-buffer nil)
@@ -713,20 +715,44 @@ is what to put on the button.
 (defun notmuch-show-markup-part (beg end depth)
   (if (re-search-forward notmuch-show-part-begin-regexp nil t)
   (progn
-   (forward-line)
-   (let ((beg (point-marker)))
- (re-search-forward notmuch-show-part-end-regexp)
- (let ((end (copy-marker (match-beginning 0
-   (goto-char end)
-   (if (not (bolp))
-   (insert \n))
-   (indent-rigidly beg end depth)
-   (notmuch-show-markup-citations-region beg end depth)
-   ; Advance to the next part (if any) (so the outer loop can
-   ; determine whether we've left the current message.
-   (if (re-search-forward notmuch-show-part-begin-regexp nil t)
-   (beginning-of-line)
-(goto-char end)))
+(let (mime-message mime-type)
+  (save-excursion
+(re-search-forward notmuch-show-contentype-regexp end t)
+(setq mime-type (car (split-string (buffer-substring 
+(match-beginning 1) (match-end 
1))
+
+  (if (equal mime-type text/html)
+  (let ((filename (notmuch-show-get-filename)))
+(with-temp-buffer
+  (insert-file-contents filename nil nil nil t)
+  (setq mime-message (mm-dissect-buffer)
+  (forward-line)
+  (let ((beg (point-marker)))
+(re-search-forward notmuch-show-part-end-regexp)
+(let ((end (copy-marker (match-beginning 0
+  (goto-char end)
+  (if (not (bolp))
+  (insert \n))
+  (indent-rigidly beg end depth)
+  (if (not (eq mime-message nil))
+  (save-excursion
+(goto-char beg)
+(forward-line -1)
+(let ((handle-type (mm-handle-type mime-message))
+  mime-type)
+  (if (sequencep (car handle-type))
+  (setq mime-type (car handle-type))
+(setq mime-type (car (car (cdr handle-type
+)
+  (if (equal mime-type text/html)
+  (mm-display-part mime-message
+)
+  (notmuch-show-markup-citations-region beg end depth)
+  ; Advance to the next part (if any) (so the outer loop can
+  ; determine whether we've left the current message.
+  (if (re-search-forward notmuch-show-part-begin-regexp nil t)
+  (beginning-of-line)
+(goto-char end
 
 (defun notmuch-show-markup-parts-region (beg end depth)
   (save-excursion
-- 
1.6.5.2

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] notmuch: Respect maildir message flags

[Tim Stoakes]

Michiel Buddingh'(mich...@michielbuddingh.net)@061209-20:55:

...
 A new patch is attached.  Apologies for the rather verbose Maildir
 handling logic, but I couldn't find a way to minimize the calls to
 is_maildir that was both neat and readable.


Hi notmuch-ers,

My apologies for dredging up an old thread. I don't want to restart the
religious war over whether notmuch should respect Maildir flags -
suffice to say that *I* want that, and the patch posted by Michiel
seemed to be the best way to make that happen.

Since it no longer applies cleanly, I've ported it forward to
79d3f9773c58d6fd7113871362687d8cfc0b1a59, to save someone else the
trouble. It works for me, but that's all the testing I've done.

Tim

-- 
Tim Stoakes



---
 notmuch-new.c |   86 -
 1 files changed, 85 insertions(+), 1 deletions(-)

diff --git a/notmuch-new.c b/notmuch-new.c
index f25c71f..3264653 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -39,6 +39,7 @@ typedef struct {
 int total_files;
 int processed_files;
 int added_messages;
+int tag_maildir;
 struct timeval tv_start;
 
 _filename_list_t *removed_files;
@@ -169,6 +170,60 @@ _entries_resemble_maildir (struct dirent **entries, int 
count)
 return 0;
 }
 
+/* Tag new mail according to its Maildir attribute flags.
+ *
+ * Test if the mail file's filename contains any of the
+ * standard Maildir attributes, and translate these to
+ * the corresponding standard notmuch tags.
+ *
+ * If the message is not marked as 'seen', or if no
+ * flags are present, tag as 'inbox, unread'.
+ */
+static void
+derive_tags_from_maildir_flags (notmuch_message_t *message,
+   const char * path)
+{
+int seen = FALSE;
+int end_of_flags = FALSE;
+size_t l = strlen(path);
+
+/* Non-experimental message flags start with this */
+char * i = strstr(path, :2,);
+i = (i) ? i : strstr(path, !2,); /* This format is used on VFAT */
+if (i != NULL) {
+   i += 3;
+   for (; i  (path + l)  !end_of_flags; i++) {
+   switch (*i) {
+   case 'F' :
+   notmuch_message_add_tag (message, flagged);
+   break;
+   case 'R': /* replied */
+   notmuch_message_add_tag (message, answered);
+   break;
+   case 'D':
+   notmuch_message_add_tag (message, draft);
+   break;
+   case 'S': /* seen */
+   seen = TRUE;
+   break;
+   case 'T': /* trashed */
+   notmuch_message_add_tag (message, deleted);
+   break;
+   case 'P': /* passed */
+   notmuch_message_add_tag (message, forwarded);
+   break;
+   default:
+   end_of_flags = TRUE;
+   break;
+   }
+   }
+}
+
+if (i == NULL || !seen) {
+   tag_inbox_and_unread (message);
+}
+}
+
 /* Examine 'path' recursively as follows:
  *
  *   o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ -222,6 +277,7 @@ add_files_recursive (notmuch_database_t *notmuch,
 notmuch_filenames_t *db_subdirs = NULL;
 struct stat st;
 notmuch_bool_t is_maildir, new_directory;
+int maildir_detected = -1;
 
 if (stat (path, st)) {
fprintf (stderr, Error reading directory %s: %s\n,
@@ -301,6 +357,28 @@ add_files_recursive (notmuch_database_t *notmuch,
continue;
}
 
+   /* If this directory is a Maildir folder, we need to
+* ignore any subdirectories marked tmp/, and scan for
+* Maildir attributes on messages contained in the sub-
+* directories 'new' and 'cur'. */
+   if (maildir_detected != 0 
+   entry-d_type == DT_DIR 
+   ((strcmp (entry-d_name, tmp) == 0) ||
+(strcmp (entry-d_name, new) == 0) ||
+(strcmp (entry-d_name, cur) == 0))) {
+
+if (maildir_detected == -1) {
+  maildir_detected = _entries_resemble_maildir(fs_entries, num_fs_entries);
+}
+if (maildir_detected == 1) {
+  if (strcmp (entry-d_name, tmp) == 0) {
+continue;
+  } else {
+state-tag_maildir = TRUE;
+  }
+}
+  }
+
next = talloc_asprintf (notmuch, %s/%s, path, entry-d_name);
status = add_files_recursive (notmuch, next, state);
if (status  ret == NOTMUCH_STATUS_SUCCESS)
@@ -412,7 +490,12 @@ add_files_recursive (notmuch_database_t *notmuch,
/* success */
case NOTMUCH_STATUS_SUCCESS:
state-added_messages++;
-   tag_inbox_and_unread (message);
+   if (state-tag_maildir) {
+   derive_tags_from_maildir_flags (message,
+   entry-d_name);
+   } else {
+   tag_inbox_and_unread (message);
+   }
break;
/* Non-fatal issues (go on to 

Re: [notmuch] patchwork test instance

[martin f krafft]

also sprach martin f krafft madd...@madduck.net [2010.02.02.1131 +1300]:
 I investigated some patch/issue trackers over the weekend. Here's my
 summary/reply.
 
 The executive summary is that
 http://patchwork.madduck.net/project/notmuch/list/ now exists.
 I have not really used it for anything real, so if some of you feel
 inclined to give it a shot, sign up and triage away! Feedback
 welcome.

Are people actually using it? I know that merging patches is
impossible, and that sucks, but otherwise: is this something to keep
around, or should I take the site offline again?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
time flies like an arrow. fruit flies like a banana.
   -- groucho marx
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] emacs: Move emacs UI (currently just one file) to subdirectory.

[david]

From: David Bremner brem...@unb.ca

Add emacs/Makefile.local and emacs/Makefile. Move emacs targets into
emacs/Makefile.local, but leave the byte compilation rule in the top
level Makefile.

---

I decided to put the actual targets for byte compilation and installation in
emacs/Makefile.local. This seems more modular to me.

 Makefile   |1 +
 Makefile.local |   10 --
 emacs/Makefile |7 +++
 emacs/Makefile.local   |   19 +++
 notmuch.el = emacs/notmuch.el |0
 5 files changed, 27 insertions(+), 10 deletions(-)
 create mode 100644 emacs/Makefile
 create mode 100644 emacs/Makefile.local
 rename notmuch.el = emacs/notmuch.el (100%)

diff --git a/Makefile b/Makefile
index 64b9d4a..bd8f50a 100644
--- a/Makefile
+++ b/Makefile
@@ -38,6 +38,7 @@ include Makefile.config
 
 include lib/Makefile.local
 include compat/Makefile.local
+include emacs/Makefile.local
 include Makefile.local
 
 # The user has not set any verbosity, default to quiet mode and inform the
diff --git a/Makefile.local b/Makefile.local
index 04bac83..8431eba 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -1,5 +1,3 @@
-emacs: notmuch.elc
-
 notmuch_client_srcs =  \
$(notmuch_compat_srcs)  \
debugger.c  \
@@ -35,14 +33,6 @@ install: all notmuch.1.gz
install notmuch $(DESTDIR)$(prefix)/bin/
install -m0644 notmuch.1.gz $(DESTDIR)$(prefix)/share/man/man1/
 
-install-emacs: install emacs
-   for d in $(DESTDIR)/$(emacs_lispdir) ; \
-   do \
-   install -d $$d ; \
-   done ;
-   install -m0644 notmuch.el $(DESTDIR)$(emacs_lispdir)
-   install -m0644 notmuch.elc $(DESTDIR)$(emacs_lispdir)
-
 install-desktop:
install -d $(DESTDIR)$(desktop_dir)
desktop-file-install --mode 0644 --dir $(DESTDIR)$(desktop_dir) 
notmuch.desktop
diff --git a/emacs/Makefile b/emacs/Makefile
new file mode 100644
index 000..b6859ea
--- /dev/null
+++ b/emacs/Makefile
@@ -0,0 +1,7 @@
+# See Makfefile.local for the list of files to be compiled in this
+# directory.
+all:
+   $(MAKE) -C .. all
+
+.DEFAULT:
+   $(MAKE) -C .. $@
diff --git a/emacs/Makefile.local b/emacs/Makefile.local
new file mode 100644
index 000..c6ca142
--- /dev/null
+++ b/emacs/Makefile.local
@@ -0,0 +1,19 @@
+dir=emacs
+emacs_sources= \
+   $(dir)/notmuch.el
+
+emacs_bytecode=$(subst .el,.elc,$(emacs_sources))
+
+emacs: $(emacs_bytecode)
+
+install-emacs: install emacs
+   for d in $(DESTDIR)/$(emacs_lispdir) ; \
+   do \
+   install -d $$d ; \
+   done ;
+   for f in $(emacs_sources) $(emacs_bytecode); \
+   do \
+   install -m0644 $$f $(DESTDIR)$(emacs_lispdir) ;\
+   done;
+
+CLEAN := $(CLEAN) $(emacs_bytecode)
diff --git a/notmuch.el b/emacs/notmuch.el
similarity index 100%
rename from notmuch.el
rename to emacs/notmuch.el
-- 
1.6.5

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] viewing text/html (inline or otherwise)

[Keith Packard]

On Tue, 09 Feb 2010 16:22:56 -0800, Carl Worth cwo...@cworth.org wrote:

 I know that Keith is using a little script he wrote so that he can hit
 '|' on a message and pipe it to his script. The script then uses a
 utility, (munpack?) to extract all the various MIME parts to a temporary
 directory and then run a web broswer on that directory. Perhaps Keith
 would be so kind as to share that script with the community here.

It's not much of a script, I call it 'view-html'

#!/bin/sh
dir=`mktemp -d`
trap rm -r $dir 0
cat $@  $dir/msg
if munpack -C $dir -t  $dir/msg 21 | grep 'Did not find'; then
sed -n '/[Hh][Tt][Mm][Ll]/,$p' $dir/msg  $dir/part1.html
rm $dir/msg
fi
for i in $dir/part*; do
if grep -q -i -e 'html' -e 'text/html' $i; then
iceweasel $i 
sleep 3
exit 0
fi
done

Note that if iceweasel isn't already running, it seems to shut down when
the script exits. I don't know why.

-- 
keith.pack...@intel.com


pgptnCaumKUr1.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch