micah | 2 Jan 19:16 2010
Picon

Queue updates to eliminate write-lock errors


I'm sure we are all seeing these occasionally:

notmuch-call-notmuch-process: A Xapian exception occurred opening database: Unable to get write lock
on .... : already locked

It happens when you try to make a change while 'notmuch new' is being
run, which is regularly. Typically a 'notmuch new' process doesn't take
that long (especially if you are running the newer xapian libraries that
fix that bug), but I still find that I am getting that error fairly
regularly. It could be because I have a somewhat slow laptop, which has
limited memory, CPU and a slow disk, so these updates take longer so I
hit that race more frequently than others.

In any case, I am sure people have figured out the best way to deal with
this already, just the work has to be done, but in case it hasn't been
floated yet, what about a queueing layer that accepts interactive
changes and attempts to apply them to the backend, backing off and
retrying until it can get the xapian lock. That way we can merrily go
along and make changes without hitting this locking problem. These
changes might have a minor delay before they are applied (until the
queue has been flushed), but it would be the same amount of time that we
have to wait now, just without the write-lock error.

micah
_______________________________________________
notmuch mailing list
notmuch@...
(Continue reading)

Erik Mackdanz | 3 Jan 23:00 2010
Picon

Attachments and URLs from vim plugin

From the Vim plugin, is there a way to:
	- save attachments?
	- pipe attachments to a viewer program?
	- extract URLs for piping to, say, urlview?

If these features don't exist yet, and if someone can point me in the 
direction of the "right" way to implement them, I could maybe bust out
some patches.

I think these are my remaining hang-ups before I can make a commitment.
I really look forward to using NotMuch.  I read about Sup with great
interest back in the day, but ultimately failed to install it, having no
experience (nor interest otherwise) in Ruby.

So, thanks for NotMuch!

--

-- 
Erik M.
Ruben Pollan | 5 Jan 16:33 2010
Picon

Re: [PATCH] Added regress option to tags iterator

On 19:16, Mon 21 Dec 09, Carl Worth wrote:
> On Mon, 21 Dec 2009 17:23:55 -0800, Carl Worth <cworth@...> wrote:
> >   New function		Corresponds to existing function (if any)
> >   ------------		-----------------------------------------
> >   move_to_first		<implicit in iterator creation>
> >   has_next		has_more
> >   move_to_next		advance
> > 
> >   move_to_last		<none>
> >   has_previous		<none>
> >   move_to_previous	<none>
> > 
> >   get			get
> > 
> > The semantics of those all seem clear enough to me. They provide what's
> > necessary for all three portions of a for loop, (in either direction),
> 
> Except that they don't. :-P
> 
> We don't want has_next and has_previous but something more like "has
> current", (perhaps to pair with get_current?).

Not sure if I understand that. Let's see if I understand well. move_to_first
(or move_to_last) will put the iterator in the first (or last) valid item.
move_to_next (and move_to_previous) will be able to reach an invalid item
outside the list. Is it like that?

In some implementations of iterators (like C++ STD) you can reach invalid items
only in one side of the list, at the end, but not at the beginning. Some people
get use to this idea, but should not be a big deal to do it different.
(Continue reading)

Carl Worth | 5 Jan 20:39 2010

Re: [PATCH] Added regress option to tags iterator

On Tue, 5 Jan 2010 16:33:32 +0100, Ruben Pollan <meskio@...> wrote:
> Not sure if I understand that. Let's see if I understand well. move_to_first
> (or move_to_last) will put the iterator in the first (or last) valid item.
> move_to_next (and move_to_previous) will be able to reach an invalid item
> outside the list. Is it like that?

Yes, that's the idea.

> In some implementations of iterators (like C++ STD) you can reach invalid items
> only in one side of the list, at the end, but not at the beginning. Some people
> get use to this idea, but should not be a big deal to do it different.

Yes, I've seen interfaces like that. They don't make sense to me since
then one direction or the other is much harder to iterate, (the
interface won't afford an easy for-loop-based iteration for example).

> So you are thinking in a function has_current showing if the current item is
> valid. Am I right?

Right. So example code using this would be:

	for (notmuch_messages_to_first (messages);
             notmuch_messages_has_current (messages);
             notmuch_messages_to_next (messages))
	{
		notmuch_message_t *message;

		message = notmuch_messages_get_current (messages);

		...
(Continue reading)

Ruben Pollan | 6 Jan 10:08 2010
Picon

Re: [PATCH] Added regress option to tags iterator

On 11:39, Tue 05 Jan 10, Carl Worth wrote:
> Right. So example code using this would be:
> 
> 	for (notmuch_messages_to_first (messages);
>              notmuch_messages_has_current (messages);
>              notmuch_messages_to_next (messages))
> 	{
> 		notmuch_message_t *message;
> 
> 		message = notmuch_messages_get_current (messages);
> 
> 		...
> 	}
> 
> And for iterating in the opposite direction it's very similar:
> 
> 	for (notmuch_messages_to_last (messages);
>              notmuch_messages_has_current (messages);
>              notmuch_messages_to_previous (messages))
> 	{
> 		notmuch_message_t *message;
> 
> 		message = notmuch_messages_get_current (messages);
> 
> 		...
> 	}
> 
> Note that if you couldn't get the iterator to point to an invalid item
> before the first, then this second loop would have to look very
> different.
(Continue reading)

martin f krafft | 8 Jan 03:56 2010
Picon

indexing encrypted messages (was: OpenPGP support)

also sprach Jameson Graef Rollins <jrollins@...>
[2009.11.26.1901 +1300]:
> I would really like to start using notmuch with emacs beyond just
> testing, but I really need to be able to handle/read/send mail with
> PGP/MIME encoded attachments.  Do folks have any suggestions on how to
> handle this?  Is there a separate emacs mode that people use for
> signing/verifying/{de,en}crypting mail buffers, or is this something
> that is going to have to be integrated into the notmuch mode?  I guess
> the notmuch-show mode at least will need to do some verifying and
> decrypting.

How about indexing GPG-encrypted messages?

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

"a scientist once wrote that all truth passes through three stages:
 first it is ridiculed, then violently opposed and eventually,
 accepted as self-evident."
                                                       -- schopenhauer

spamtraps: madduck.bogus@...
_______________________________________________
notmuch mailing list
notmuch@...
http://notmuchmail.org/mailman/listinfo/notmuch
martin f krafft | 8 Jan 03:56 2010
Picon

Re: Quick thoughts on a notmuch daemon

also sprach Carl Worth <cworth@...> [2009.12.08.2001 +1300]:
> One concept in notmuch (compared to sup) is to (eventually) avoid people
> having to go through that pain by their current mail client becoming
> "notmuch enabled". For me, I had always liked composing email in emacs,
> so I just have to add notmuch support to the existing emacs
> message-mode.
> 
> Hopefully people working on other email interfaces will do similar
> things, (would be great to have Anjal and Thunderbird get some notmuch
> support for example).
> 
> I definitely didn't like that with sup, to get all the global-search and
> tagging features one had to accept the curses UI as well.

I am a bit late to the party, but re: this thread [0], I would
suggest to go the way of a fuse filesystem. That's effectively
a daemon, but one which also bridges a chasm between notmuch and all
kinds of existing mail tools, including IMAP servers, by way of the
standard filesystem interface.

0. http://notmuchmail.org/pipermail/notmuch/2009/000782.html

I don't want to harp on this too much right now for I have not yet
fully understood notmuch, but the basic idea would be that you'd
have ~/mail provided by notmuch-fuse-daemon, and there'd be a tool
like notmuch-fuse-cli with which you can add virtual folders, e.g.

  notmuch-fuse-cli new debianmail 'from:debian OR to:debian'

and that would create ~/mail/debianmail with mode 555 (since you
(Continue reading)

martin f krafft | 8 Jan 04:00 2010
Picon

Re: notmuch and imap [musing, no code :)]

also sprach David Bremner <david@...> [2009.12.17.0218 +1300]:
> I agree that the labels-in-headers approach has some nice
> advantages.  I haven't thought through merging of tag lists, but
> maybe that is no worse than other approaches.  One thing that
> worries me a bit is that notmuch updates tags often, and each of
> these updates would require rewriting the message, at least in the
> obvious implementation.

If we separated implicit and explicit tags, then that issue would
not exist, and from all I can tell, only the privacy issues, and the
risk of losing mail when files are rewritten persist.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

DISCLAIMER: this entire message is privileged communication, intended
for the sole use of its recipients only. If you read it even though
you know you aren't supposed to, you're a poopy-head.

spamtraps: madduck.bogus@...
_______________________________________________
notmuch mailing list
notmuch@...
http://notmuchmail.org/mailman/listinfo/notmuch
martin f krafft | 8 Jan 04:12 2010
Picon

Re: Threading

also sprach Carl Worth <cworth@...> [2009.12.11.0639 +1300]:
> On Wed, 9 Dec 2009 16:21:34 -0700, Mark Anderson <markr.anderson@...> wrote:
> > I was wondering if there's a way in notmuch to group un-associated
> > threads into a single thread.
> 
> There's certainly nothing like that in notmuch currently.
> 
> Sup had user-level functionality in the interface for stitching
> messages into a single thread, and I definitely think that that
> doesn't make any sense.

Why doesn't it make sense? Mutt does it too, and stitching means
actually (re)writing In-Reply-To and References headers.

I think this is one of the most useful "productivity features" in
mutt.

I also think that threading is a preference thing. As Carl said in
a later message:

> Just this morning I sent a mail to the notmuch list, which was
> a reply, (and legitimately so), but also potentially of interest
> to everyone on the list, (since it was regarding a bug fix
> unrelated to the original topic of the thread I was replying to).
> 
> So I was stuck on whether I should break the thread or not, (at
> the sending end). I guess I could have just sent a quick "this is
> pushed" reply, and independently composed a separate message
> telling people about the fix.
> 
(Continue reading)

Mike Hommey | 8 Jan 09:06 2010

Re: Quick thoughts on a notmuch daemon

On Fri, Jan 08, 2010 at 03:56:20PM +1300, martin f krafft wrote:
> These ideas are not new, and I've written about them before:
> 
> http://madduck.net/blog/2007.07.24:a-user-space-filesystem-for-mail-labeling/
> 
> notmuch seems an excellent base for implementing such a filesystem.
> I will try to make time before LCA to get up to speed on fuse, then
> maybe Carl and Micah and I (and whoever else will be in Wellington)
> can hack this up in a few hours and over a few beers.
> 
> If this resonates, or you want to work on this too, let's hear from
> you!

I'm in \o_ (though I won't be in Wellington). I've been thinking about a
fuse filesystem on top of notmuch for a while.

Mike

Gmane