[notmuch] [PATCH (rebased)] Handle message renames in mail spool
> 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
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
Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool
On Thu, 2009-12-17 at 06:01 +0600, Mikhail Gusarov wrote: > Twas brillig at 16:51:17 16.12.2009 UTC-07 when bd...@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 mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] notmuch dependencies
Is notmuch supposed to be a console MUA? Is there a reason it depends on tons and tons of GNOME libraries? Sup doesn't. Is notmuch going to be a "gnome cli tool" or what? _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/ -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091216/3c802e6e/attachment.htm>
Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool
> 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
[notmuch] [PATCH (rebased)] Handle message renames in mail spool
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
Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool
Twas brillig at 16:51:17 16.12.2009 UTC-07 when bd...@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. -- http://fossarchy.blogspot.com/ pgpVp2gZ1D0sj.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
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
[notmuch] notmuch and imap [musing, no code :)]
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
Re: [notmuch] notmuch dependencies
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 pgpERCnxTDWgA.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] notmuch dependencies
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 dependencies
Is notmuch supposed to be a console MUA? Is there a reason it depends on tons and tons of GNOME libraries? Sup doesn't. Is notmuch going to be a "gnome cli tool" or what? _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] wish: syncable/immutable threads
On Tue, 15 Dec 2009 17:23:59 -0400, David Bremner 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
[notmuch] notmuch and imap [musing, no code :)]
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 :)]
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 mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] notmuch and imap [musing, no code :)]
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
