[notmuch] [PATCH (rebased)] Handle message renames in mail spool

2009-12-16 Thread Michael Alan Dorman
> I'd had much better luck matching List-Id than matching addresses in
> recent years.  YMMV.

As long as you're not CC:d, you're fine.  If you're CC:'d, well, Mailman
is more brain-dead than you could imagine.

Mike.


[notmuch] [PATCH (rebased)] Handle message renames in mail spool

2009-12-16 Thread Bdale Garbee
On Thu, 2009-12-17 at 06:01 +0600, Mikhail Gusarov wrote:
> Twas brillig at 16:51:17 16.12.2009 UTC-07 when bdale at gag.com did gyre and 
> gimble:
> 
>  >> But the above sounds like the List-Id header is unreliable enough to
>  >> be useless.
> 
>  BG> FWIW, that does not match my experience.
> 
> Yeah. This mail just arrived to my "main" folder instead of "notmuch"
> one, as you kept me in CC and hence Mailman did not send the copy with
> List-Id to me.
> 
> Please read the whole thread.

I did.  I guess I've just been lucky enough to mostly participate in
lists run with other software than Mailman or whose admins didn't leave
this default behavior in place...  [sigh]

I will, very unhappily, concede the point.

Bdale




[notmuch] [PATCH (rebased)] Handle message renames in mail spool

2009-12-16 Thread Bdale Garbee
On Fri, 2009-12-04 at 10:35 -0800, Carl Worth wrote:

> But the above sounds like the List-Id header is unreliable enough to be
> useless. 

FWIW, that does not match my experience.

> Any reason not to just use something like
> to:notmuch at notmuchmail to match messages sent to a list like this one?

I'd had much better luck matching List-Id than matching addresses in
recent years.  YMMV.

Bdale




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

2009-12-16 Thread Marten Veldthuis
On Wed, 16 Dec 2009 09:18:16 -0400, David Bremner  wrote:
> 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. I'd hate to finally
> have Xapian issue 350 fixed, only to take an equivalent hit by rewriting
> the message. Maybe it is not that slow.

If it is, maybe we could do the sync-back by renaming notmuch-new to
notmuch-sync, and doing it there.

-- 
- Marten


[notmuch] notmuch dependencies

2009-12-16 Thread Carl Worth
On Wed, 16 Dec 2009 18:51:31 +, blank blank  
wrote:
> Is notmuch supposed to be a console MUA?

I'm not sure what you mean by "console MUA". But I can describe what
notmuch is, (which is a variety of things).

Notmuch is a library and command-line interface for archiving and
searching mail. It has interfaces implemented within text editors, (such
as emacs and vim), so those can run in a console. There are also some
in-progress interfaces, some of which are console-based (like a curses
interface), and some of which are graphical (such as a GTK+
interface). There's also talk of interfacing notmuch to existing
graphical interfaces.

> Is there a reason it depends on tons and tons of GNOME libraries?

I'm not sure I follow this either. Other than using Xapian for the core
indexing and searching, notmuch depends on GMime (a library written in C
for parsing MIME messages). GMime in turn depends on glib, which is a
dependency I'm not thrilled with, but I also don't think is accurately
described as "tons of tons of GNOME libraries".

If you'd be interested in rewriting the MIME-parsing portions of GMime
to have fewer dependencies, or suggest a similar library with fewer
dependencies for use in notmuch, then I'd be happy to look at
that.

> Sup doesn't.

Sup is using Rmail, (a ruby-based library), for similar functionality to
what notmuch is getting from GMime. If that's a better fit for what
you'd like in the runtime-dependencies of your mail system, by all
means, please feel free to use Sup.

> Is notmuch going to be a "gnome cli tool" or what?

For the third time, I'm afraid I just don't understand your
question. I'd be happy to try to answer it, but I'm not sure what it
is. What does the phrase "gnome cli tool" even mean?

-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/20091216/82702209/attachment.pgp>


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

2009-12-16 Thread David Bremner
On Tue, 15 Dec 2009 19:54:11 -0500, Alec Berryman  wrote:

> There are security concerns (need to strip incoming messages of tags so
> no one tags your mail for you), privacy concerns (if you forward the
> entire message as an attachment, may want to strip tags), and space
> concerns (how many flags?), but I think they can be worked around.

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. I'd hate to finally
have Xapian issue 350 fixed, only to take an equivalent hit by rewriting
the message. Maybe it is not that slow.

d


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

2009-12-16 Thread Marten Veldthuis
On Wed, 16 Dec 2009 09:18:16 -0400, David Bremner da...@tethera.net wrote:
 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. I'd hate to finally
 have Xapian issue 350 fixed, only to take an equivalent hit by rewriting
 the message. Maybe it is not that slow.

If it is, maybe we could do the sync-back by renaming notmuch-new to
notmuch-sync, and doing it there.

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


Re: [notmuch] wish: syncable/immutable threads

2009-12-16 Thread Carl Worth
On Tue, 15 Dec 2009 17:23:59 -0400, David Bremner brem...@unb.ca wrote:
 I then try to visit these threads on a different machine, but of course
 that thread id doesn't exist there, since the database was reindexed and
 tags reimported.

Ah, good point.

I've wanted reproducible thread IDs also for a similar reason. I
anticipate writing a tool to create HTML versions of the archives of
mailing lists. In this case I want to have thread IDs in URLs and I want
those URLs to be persistent even if I re-build the index from scratch.
(For this case, I'd also like to have small thread IDs, such as
consecutive integers.)

 I don't know if it is in any way practical, but it would be nice from my
 point of view if thread id's were a property of the mail collection, or
 at least it was possible to dump and restore them.

I think it's quite practical. The easiest answer is probably to simply
include the thread ID in each line of the dump output. And then we
should ensure that thread IDs as well as tags are accounted for in the
design of any synchronization mechanism to support multiple notmuch
databases. One thing to consider is whether we want to continue to have
any amount of compatibility with the sup dump format

 If this is too much of a corner case, then I suspect I can work around
 it in the emacs client by calling search twice, first with an id in the
 thread.

That's almost similar to what sup does, which is to use a message ID of
a the first message encoutered in a thread as the thread ID. Doing that
alone doesn't help with the case of rebuilding the index on separate
machines since it makes the thread ID dependent on the order in which
messages are processed.

But yes, if you can make your links depend only on message IDs then you
can get reliable results even before we start including thread IDs in
the dump output. The result of notmuch show --entire-thread id:foo is
quite similar to the result of notmuch show thread:bar (for the
corresponding thread ID of course). It differs only in the match
field, which is used to determine which messages to open by default.

-Carl


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


Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

2009-12-16 Thread Bdale Garbee
On Fri, 2009-12-04 at 10:35 -0800, Carl Worth wrote:

 But the above sounds like the List-Id header is unreliable enough to be
 useless. 

FWIW, that does not match my experience.

 Any reason not to just use something like
 to:notm...@notmuchmail to match messages sent to a list like this one?

I'd had much better luck matching List-Id than matching addresses in
recent years.  YMMV.

Bdale


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


Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

2009-12-16 Thread Michael Alan Dorman
 I'd had much better luck matching List-Id than matching addresses in
 recent years.  YMMV.

As long as you're not CC:d, you're fine.  If you're CC:'d, well, Mailman
is more brain-dead than you could imagine.

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