[notmuch] loss of duplicate messages
On Fri, 05 Feb 2010 11:31:34 -0500, Jameson Rollins wrote: > I'm noticing that notmuch is either not syncing, or not returning in > searches, duplicate messages that have identical bodies but different > headers. This is indeed the correct behaviour of notmuch. There has been some discussion on it in the past, I believe with proposals to track both messages and show only one; but I don't think I've seen proponents of showing both duplicate messages. Personally I'd find it rather annoying if I'd see messages twice. But I do see the value in being sure that your mail gets delivered through the list. I believe the solution I've seen discussed was for notmuch to somehow determine which of the duplicates holds the most information (which would be the one through the list, not the one directly to you). On the other hand, enough mailing lists destroy this behaviour, see: the thread [notmuch] [PATCH (rebased)] Handle message renames in mail spool, around id:87y6lir37f.fsf at vertex.dottedmag -- - Marten
Re: [notmuch] loss of duplicate messages
On Fri, 05 Feb 2010 11:31:34 -0500, Jameson Rollins wrote: > I'm noticing that notmuch is either not syncing, or not returning in > searches, duplicate messages that have identical bodies but different > headers. This is indeed the correct behaviour of notmuch. There has been some discussion on it in the past, I believe with proposals to track both messages and show only one; but I don't think I've seen proponents of showing both duplicate messages. Personally I'd find it rather annoying if I'd see messages twice. But I do see the value in being sure that your mail gets delivered through the list. I believe the solution I've seen discussed was for notmuch to somehow determine which of the duplicates holds the most information (which would be the one through the list, not the one directly to you). On the other hand, enough mailing lists destroy this behaviour, see: the thread [notmuch] [PATCH (rebased)] Handle message renames in mail spool, around id:87y6lir37f@vertex.dottedmag -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] New wiki instance on the notmuchmail.org website
On Wed, 03 Feb 2010 08:47:41 -0800, Carl Worth wrote: > See this page for details (particularly the "security" and > "infelicities" sections): > > http://ikiwiki.info/tips/untrusted_git_push/ Ah. Probably this section: So, unless you have the attachment plugin turned on, non-page files cannot be added. And if it's turned on, whatever allowed_attachments checks you have configured will also check files pushed into git. since I was trying to add some screenshots of the Emacs interface. It makes perfect sense not to enable this plugin though, given the security implications (people could potentially upload mp3's as png's etc). Let me know if I should send you the commit off-list or if you don't mind enabling the attachment plugin for eg common image filetypes. -- - Marten
[notmuch] New wiki instance on the notmuchmail.org website
On Wed, 03 Feb 2010 09:36:52 -0500, Matthew Gregg wrote: > Like this? http://notmuchmail.org/recentchanges/ No, more like this: http://git.notmuchmail.org/git/notmuch-wiki -- - Marten
[notmuch] New wiki instance on the notmuchmail.org website
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth wrote: > The benefit is that there's now a git repository for the website, (with > source in markdown format), and more importantly, the git repository > will accept a "git push" without any authentication necessary. Carl, I'm getting To git://notmuchmail.org/git/notmuch-wiki ! [remote rejected] master -> master (pre-receive hook declined) upon pushing. Some part of the "without any authentication" is not working, I suspect. :) -- - Marten
[notmuch] New wiki instance on the notmuchmail.org website
On Wed, 03 Feb 2010 08:23:18 -0500, micah anderson wrote: > I don't know ikiwiki that well, but I imagine there is a way (probably > via a git post-commit hook) to email changes that have been pushed. This > might be a good way to keep up with what people are changing on the > site, although sending it to this list might be too much, perhaps > another mailing list for those gluttons who would like to see this? Wouldn't RSS from gitweb be sufficient? There's already RSS for notmuch.git, I expect it'd be trivial to publish the same for notmuch-wiki.git. -- - Marten
Re: [notmuch] New wiki instance on the notmuchmail.org website
On Wed, 03 Feb 2010 08:47:41 -0800, Carl Worth wrote: > See this page for details (particularly the "security" and > "infelicities" sections): > > http://ikiwiki.info/tips/untrusted_git_push/ Ah. Probably this section: So, unless you have the attachment plugin turned on, non-page files cannot be added. And if it's turned on, whatever allowed_attachments checks you have configured will also check files pushed into git. since I was trying to add some screenshots of the Emacs interface. It makes perfect sense not to enable this plugin though, given the security implications (people could potentially upload mp3's as png's etc). Let me know if I should send you the commit off-list or if you don't mind enabling the attachment plugin for eg common image filetypes. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] New wiki instance on the notmuchmail.org website
On Wed, 03 Feb 2010 09:36:52 -0500, Matthew Gregg wrote: > Like this? http://notmuchmail.org/recentchanges/ No, more like this: http://git.notmuchmail.org/git/notmuch-wiki -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] New wiki instance on the notmuchmail.org website
On Tue, 02 Feb 2010 23:44:56 -0800, Carl Worth wrote: > The benefit is that there's now a git repository for the website, (with > source in markdown format), and more importantly, the git repository > will accept a "git push" without any authentication necessary. Carl, I'm getting To git://notmuchmail.org/git/notmuch-wiki ! [remote rejected] master -> master (pre-receive hook declined) upon pushing. Some part of the "without any authentication" is not working, I suspect. :) -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] New wiki instance on the notmuchmail.org website
On Wed, 03 Feb 2010 08:23:18 -0500, micah anderson wrote: > I don't know ikiwiki that well, but I imagine there is a way (probably > via a git post-commit hook) to email changes that have been pushed. This > might be a good way to keep up with what people are changing on the > site, although sending it to this list might be too much, perhaps > another mailing list for those gluttons who would like to see this? Wouldn't RSS from gitweb be sufficient? There's already RSS for notmuch.git, I expect it'd be trivial to publish the same for notmuch-wiki.git. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] patchwork test instance (was: Git feature branch)
On Tue, 2 Feb 2010 11:31:12 +1300, martin f krafft wrote: > Arguably, being patch-centric means that a project has a higher > barrier of entry, but it also means that if someone wants something, > they know that they'll have to somehow end up with a patch. The way > this happens on Git is that you either write it yourself and bring > it up to discussion (which is what patchwork facilitates), or > constructively theorise the functionality until someone else > submits a patch. And don't forget, if you really want something on the longterm todo list, you can always send in a patch for the TODO file. ;) -- - Marten
Re: [notmuch] patchwork test instance (was: Git feature branch)
On Tue, 2 Feb 2010 11:31:12 +1300, martin f krafft wrote: > Arguably, being patch-centric means that a project has a higher > barrier of entry, but it also means that if someone wants something, > they know that they'll have to somehow end up with a patch. The way > this happens on Git is that you either write it yourself and bring > it up to discussion (which is what patchwork facilitates), or > constructively theorise the functionality until someone else > submits a patch. And don't forget, if you really want something on the longterm todo list, you can always send in a patch for the TODO file. ;) -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Introducing notmuchsync
On Tue, 19 Jan 2010 14:37:03 +0100, "Sebastian Spaeth" wrote: > - Move read files from 'new' to 'cur' folder. At what point is that >moving typically done in Maildir? When the user has actually looked >at the mail? Yes, exactly that. -- - Marten
Re: [notmuch] Introducing notmuchsync
On Tue, 19 Jan 2010 14:37:03 +0100, "Sebastian Spaeth" wrote: > - Move read files from 'new' to 'cur' folder. At what point is that >moving typically done in Maildir? When the user has actually looked >at the mail? Yes, exactly that. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Introducing notmuchsync
On Mon, 18 Jan 2010 16:12:28 +0100, "Sebastian Spaeth" wrote: > What does it do? > > - Synchronizes the "S" flag with the "unread" tag (1-way). The > synchronization direction is decided by using either --sync (change > maildir flags according to notmuch) or --revsync (change notmuch tags > according to maildir). By default it always checks the mails from the > previous 30 > days (but can also do --all mails if you have plenty of RAM and time). > - Deletes all mail files that have the "delete" tag > - Quiet/normal/verbose logging Excellent. Sounds like nearly exactly what I thought about doing last weekend, except that I couldn't find a nice Ruby library quickly and then my attention-span was over :) Also, I'm curious as to Carl's opinion to this, but as far as I'm concerned, not everything about notmuch needs to be coded in C. Obviously, things interacting with the database directly need to, but if it could be built upon the notmuch C-based CLI commands, and be fast enough, would that be eligible to make it into the repository? -- - Marten
Re: [notmuch] Introducing notmuchsync
On Mon, 18 Jan 2010 16:12:28 +0100, "Sebastian Spaeth" wrote: > What does it do? > > - Synchronizes the "S" flag with the "unread" tag (1-way). The > synchronization direction is decided by using either --sync (change > maildir flags according to notmuch) or --revsync (change notmuch tags > according to maildir). By default it always checks the mails from the > previous 30 > days (but can also do --all mails if you have plenty of RAM and time). > - Deletes all mail files that have the "delete" tag > - Quiet/normal/verbose logging Excellent. Sounds like nearly exactly what I thought about doing last weekend, except that I couldn't find a nice Ruby library quickly and then my attention-span was over :) Also, I'm curious as to Carl's opinion to this, but as far as I'm concerned, not everything about notmuch needs to be coded in C. Obviously, things interacting with the database directly need to, but if it could be built upon the notmuch C-based CLI commands, and be fast enough, would that be eligible to make it into the repository? -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] keeping a copy of sent mail locally
On Mon, 21 Dec 2009 21:08:22 +1100, Alex Ghitza wrote: > 2. of course, filenames need to be unique. Do we want/have to follow > the maildir file naming conventions listed at > http://cr.yp.to/proto/maildir.html > or is it enough to use the Emacs lisp make-temp-file? I'd very much prefer a real Maildir, because that would sync back correctly with OfflineIMAP etc. -- - Marten
Re: [notmuch] keeping a copy of sent mail locally
On Mon, 21 Dec 2009 21:08:22 +1100, Alex Ghitza wrote: > 2. of course, filenames need to be unique. Do we want/have to follow > the maildir file naming conventions listed at > http://cr.yp.to/proto/maildir.html > or is it enough to use the Emacs lisp make-temp-file? I'd very much prefer a real Maildir, because that would sync back correctly with OfflineIMAP etc. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] keeping a copy of sent mail locally
On Sat, 19 Dec 2009 21:02:18 -0800, Keith Packard wrote: > We actually want to let the user *select* an email address from the > config file, and then automagically set the bcc: flag as > appropriate. Without that, I'd end up bcc'ing all of my mail through my > home address, which would end up sending work email unencrypted to my > house. Sub-optimal There's a message-send-hook, which we should probably use. Something like: (add-hook 'message-send-hook 'notmuch-always-bcc-sender) (defun notmuch-always-bcc-sender () (message-add-header (concat "Bcc: " (message-fetch-field "From" Though I've just scrabbled this together from the docs, I think it should work (haven't tried it though). -- - Marten
Re: [notmuch] keeping a copy of sent mail locally
On Sat, 19 Dec 2009 21:02:18 -0800, Keith Packard wrote: > We actually want to let the user *select* an email address from the > config file, and then automagically set the bcc: flag as > appropriate. Without that, I'd end up bcc'ing all of my mail through my > home address, which would end up sending work email unencrypted to my > house. Sub-optimal There's a message-send-hook, which we should probably use. Something like: (add-hook 'message-send-hook 'notmuch-always-bcc-sender) (defun notmuch-always-bcc-sender () (message-add-header (concat "Bcc: " (message-fetch-field "From" Though I've just scrabbled this together from the docs, I think it should work (haven't tried it though). -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Store the size of the file for each message
On Fri, 18 Dec 2009 21:24:10 -0800, Carl Worth wrote: > Currently we're replicating all of our documentation both in the man > page and in the output from "notmuch help". It's annoying to have to > add everything in two places, but I don't have a good idea for making > that sharable yet. > > Anyone have a solution here? Something like "git help add" just opens the manpage for git-add. Can't we do the same here? -- - Marten
Re: [notmuch] [PATCH] Store the size of the file for each message
On Fri, 18 Dec 2009 21:24:10 -0800, Carl Worth wrote: > Currently we're replicating all of our documentation both in the man > page and in the output from "notmuch help". It's annoying to have to > add everything in two places, but I don't have a good idea for making > that sharable yet. > > Anyone have a solution here? Something like "git help add" just opens the manpage for git-add. Can't we do the same here? -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] automatically assigning tags to new messages?
On Fri, 18 Dec 2009 22:21:54 +1100, Alex Ghitza wrote: > I heard about notmuch mail a few days ago and I started playing with > it. So far, it makes me very happy, but there are some things that I > need to learn how to do. I'll start with the most important one: > tagging incoming messages automatically. I've got a script somewhere which I invoke after each mail sync. I'll give some examples from that for your list below. > What is the recommended way of achieving this? There is a variety of > things that I would like to automatically do to incoming mail: > - if it comes from a mailing list (e.g. notmuch), tag it +notmuch and > +unread, but not +inbox notmuch tag +list +notmuch -inbox to:notmuch at notmuchmail.organd not tag:notmuch and tag:inbox > - if it's one of the numerous pointless weekly newsletters that I'm > getting from my university, tag it +unimelb, but not +unread or > +inbox notmuch tag +unimelb -unread -inbox to:foo and not tag:unimelb and tag:unread and tag:inbox > - if it is coming from me, tag it +sent, but not +unread or +inbox Not quite sure. Currently I'm not doing this, don't know if this is possible within a single incantation of notmuch-tag. I think you probably need a first search to get message ids, and then tag only those message ids (doing it like the others above would tag all messages in the thread with sent, which is probably not what you want). -- - Marten
Re: [notmuch] automatically assigning tags to new messages?
On Fri, 18 Dec 2009 22:21:54 +1100, Alex Ghitza wrote: > I heard about notmuch mail a few days ago and I started playing with > it. So far, it makes me very happy, but there are some things that I > need to learn how to do. I'll start with the most important one: > tagging incoming messages automatically. I've got a script somewhere which I invoke after each mail sync. I'll give some examples from that for your list below. > What is the recommended way of achieving this? There is a variety of > things that I would like to automatically do to incoming mail: > - if it comes from a mailing list (e.g. notmuch), tag it +notmuch and > +unread, but not +inbox notmuch tag +list +notmuch -inbox to:notmuch@notmuchmail.organd not tag:notmuch and tag:inbox > - if it's one of the numerous pointless weekly newsletters that I'm > getting from my university, tag it +unimelb, but not +unread or > +inbox notmuch tag +unimelb -unread -inbox to:foo and not tag:unimelb and tag:unread and tag:inbox > - if it is coming from me, tag it +sent, but not +unread or +inbox Not quite sure. Currently I'm not doing this, don't know if this is possible within a single incantation of notmuch-tag. I think you probably need a first search to get message ids, and then tag only those message ids (doing it like the others above would tag all messages in the thread with sent, which is probably not what you want). -- - Marten ___ 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 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
[notmuch] [patch] store folder information
On Tue, 15 Dec 2009 13:16:35 +0100, Ruben Pollan wrote: > The patch works fine for me. I like it handles nicely the .foo.bar > directories > so I can do searches for "folder:foo" and for "folder:bar". > > Reviewed-by: Ruben Pollan Second that, and I actually think it's a nicer solution than automatically adding tags based on folder. Reviewed-by: Marten Veldthuis -- - Marten
[notmuch] Threading
On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth wrote: > But I still have a hard time justifying user operations to manipulate > threading. The whole point of threading is to make it faster to process > and read messages. But manual operations like joining and splitting > threads seem like the user just doing more work, and that *after* having > read the messages. So that seems mostly backwards to me. By the way, Outlook & Exchange suck (or at least some versions do), and don't seem to generate In-Reply-To and References: headers. Just got a mail which prompted me to write this mail. I'd really like to be able to join messages in a case like this. -- - Marten
Re: [notmuch] [patch] store folder information
On Tue, 15 Dec 2009 13:16:35 +0100, Ruben Pollan wrote: > The patch works fine for me. I like it handles nicely the .foo.bar > directories > so I can do searches for "folder:foo" and for "folder:bar". > > Reviewed-by: Ruben Pollan Second that, and I actually think it's a nicer solution than automatically adding tags based on folder. Reviewed-by: Marten Veldthuis -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Threading
On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth wrote: > But I still have a hard time justifying user operations to manipulate > threading. The whole point of threading is to make it faster to process > and read messages. But manual operations like joining and splitting > threads seem like the user just doing more work, and that *after* having > read the messages. So that seems mostly backwards to me. By the way, Outlook & Exchange suck (or at least some versions do), and don't seem to generate In-Reply-To and References: headers. Just got a mail which prompted me to write this mail. I'd really like to be able to join messages in a case like this. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] RFC: output json from notmuch?
Excerpts from David Bremner's message of Mon Dec 14 00:21:02 +0100 2009: > So, do people think this is a reasonable idea to persue? JSON was actually the first thing I thought of when I first saw the output of notmuch-show. I think it's a much more natural fit for notmuch than say, sexps, since most languages will have libraries for JSON, which will be nicer to interfaces other than the emacs one. -- - Marten
Re: [notmuch] RFC: output json from notmuch?
Excerpts from David Bremner's message of Mon Dec 14 00:21:02 +0100 2009: > So, do people think this is a reasonable idea to persue? JSON was actually the first thing I thought of when I first saw the output of notmuch-show. I think it's a much more natural fit for notmuch than say, sexps, since most languages will have libraries for JSON, which will be nicer to interfaces other than the emacs one. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] reading with multiple MUAs from MailDir
Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: > Is there a workaround? For now, you can do notmuch dump somefile mv Mail/.notmuch /tmp notmuch new notmuch restore somefile Which will re-index all your mail, and restore your tags, as far as the messages are still called the same. Deleted messages will disappear from the library, and moved messages remain in the inbox. Still a pain in the ass, but at least it gets rid of all those errors. - Marten -- - Marten
Re: [notmuch] reading with multiple MUAs from MailDir
Excerpts from Dirk Hohndel's message of Fri Dec 11 07:11:04 +0100 2009: > Is there a workaround? For now, you can do notmuch dump somefile mv Mail/.notmuch /tmp notmuch new notmuch restore somefile Which will re-index all your mail, and restore your tags, as far as the messages are still called the same. Deleted messages will disappear from the library, and moved messages remain in the inbox. Still a pain in the ass, but at least it gets rid of all those errors. - Marten -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Threading
On Thu, 10 Dec 2009 09:39:48 -0800, Carl Worth wrote: > I think the right answer here is to fix the input that notmuch is > getting. Just ensure that each message has a proper In-Reply-To header > and all should be fine. On a related note, what about communicating with people who press reply on an existing message, change the subject and start a new mail thread. Most mail clients will still insert the In-Reply-To header, which in this case is just wrong. Ofcourse, it's their fault, but one can't educate the entire world. Is there anything like mutt has, to break a thread at the current message? -- - Marten
Re: [notmuch] Threading
On Thu, 10 Dec 2009 09:39:48 -0800, Carl Worth wrote: > I think the right answer here is to fix the input that notmuch is > getting. Just ensure that each message has a proper In-Reply-To header > and all should be fine. On a related note, what about communicating with people who press reply on an existing message, change the subject and start a new mail thread. Most mail clients will still insert the In-Reply-To header, which in this case is just wrong. Ofcourse, it's their fault, but one can't educate the entire world. Is there anything like mutt has, to break a thread at the current message? -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Quick thoughts on a notmuch daemon
On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner wrote: > > On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth wrote: > It might be a bit blue sky, but if this daemon could (optionally) talk > IMAP and translate tags into folders on the fly, this would be very > useful for people who need imap access to their mail as well as from an > custom notmuch client. For me, my IMAP needs are pretty much limited to my iPhone. I'm making do for now, but to make notmuch viable in the long term, what I'd need is: * notmuch shouldn't choke on mails I had in notmuch's database, and then marked read or deleted on my iPhone (which renames them in the maildir). This is coming with the moving/deleting patches. * notmuch should sync back read/unread state to maildir * notmuch should move read stuff out of my inbox. It would be acceptable if it moved everything into a designated archive folder unless it had the 'inbox' tag assigned, in which case it moved it there. Note that we have the moving/deleting patches, then this could even be done as a script and some searches. With this, my inbox would be usable from my iPhone. -- - Marten
Re: [notmuch] Quick thoughts on a notmuch daemon
On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner wrote: > > On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth wrote: > It might be a bit blue sky, but if this daemon could (optionally) talk > IMAP and translate tags into folders on the fly, this would be very > useful for people who need imap access to their mail as well as from an > custom notmuch client. For me, my IMAP needs are pretty much limited to my iPhone. I'm making do for now, but to make notmuch viable in the long term, what I'd need is: * notmuch shouldn't choke on mails I had in notmuch's database, and then marked read or deleted on my iPhone (which renames them in the maildir). This is coming with the moving/deleting patches. * notmuch should sync back read/unread state to maildir * notmuch should move read stuff out of my inbox. It would be acceptable if it moved everything into a designated archive folder unless it had the 'inbox' tag assigned, in which case it moved it there. Note that we have the moving/deleting patches, then this could even be done as a script and some searches. With this, my inbox would be usable from my iPhone. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH (rebased)] Handle message renames in mail spool
On Fri, 04 Dec 2009 16:39:50 -0800, Carl Worth wrote: > But when viewing an actual message, I'm still planning on having notmuch > just return an arbitrary filename from the list of filenames associated > with that message. Does anyone see any problem with that? Can you think > of a case where you'd really care about seeing one or the other of > a particular duplicated message? As long as it's deterministic. But if you don't display the first filename received, couldn't you exploit this by spoofing message ids? -- - Marten
Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool
On Fri, 04 Dec 2009 16:39:50 -0800, Carl Worth wrote: > But when viewing an actual message, I'm still planning on having notmuch > just return an arbitrary filename from the list of filenames associated > with that message. Does anyone see any problem with that? Can you think > of a case where you'd really care about seeing one or the other of > a particular duplicated message? As long as it's deterministic. But if you don't display the first filename received, couldn't you exploit this by spoofing message ids? -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Recent (and forthcoming) improvements to the emacs interface
On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth wrote: > * Much nicer looking presentation, (no more ugly reverse-video or > underlines on the message summary line). > > * More reliable message-visibility buttons, (using RET in the first > column of a message-summary line now works). Not sure what happened, but: Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts From: camalot at picnicpark.org To: notmuch at notmuchmail.org Cc: Keith Amidon Bcc: Date: Fri, 27 Nov 2009 05:30:10 -0800 now collapses into: Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts From: Keith Amidon on my system (notice the From: header). -- - Marten
Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface
On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth wrote: > * Much nicer looking presentation, (no more ugly reverse-video or > underlines on the message summary line). > > * More reliable message-visibility buttons, (using RET in the first > column of a message-summary line now works). Not sure what happened, but: Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts From: cama...@picnicpark.org To: notmuch@notmuchmail.org Cc: Keith Amidon Bcc: Date: Fri, 27 Nov 2009 05:30:10 -0800 now collapses into: Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from notmuch-show-view-all-mime-parts From: Keith Amidon on my system (notice the From: header). -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
Excerpts from Carl Worth's message of Wed Dec 02 22:36:13 +0100 2009: > As a side-note, I would recommend against making your auto-tagging > scripts process only new messages. You can get a much more reliable > setup by having your auto-tagging scripts apply to the global > database. And this is not inefficient at all if you simply ensure that > you only match messages which need the tag added. I can see one clear case where that would become a problem: mistaggings. If I set up something so that in 99% of the cases, it'd tag new mail correctly with say "inbox unread mytag", I could quickly pick the mistagged ones out and remove the offending tag. If you do it like above however, the autotag script would come merrily along and retag them. -- - Marten
Re: [notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.
Excerpts from Carl Worth's message of Wed Dec 02 22:36:13 +0100 2009: > As a side-note, I would recommend against making your auto-tagging > scripts process only new messages. You can get a much more reliable > setup by having your auto-tagging scripts apply to the global > database. And this is not inefficient at all if you simply ensure that > you only match messages which need the tag added. I can see one clear case where that would become a problem: mistaggings. If I set up something so that in 99% of the cases, it'd tag new mail correctly with say "inbox unread mytag", I could quickly pick the mistagged ones out and remove the offending tag. If you do it like above however, the autotag script would come merrily along and retag them. -- - Marten ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Add tests to configure script to detect strndup and getline
On Mon, Nov 23, 2009 at 12:14:15PM -0600, Jeffrey C. Ollie wrote:
> cat > Makefile.config < prefix = /usr/local
> bash_completion_dir = /etc/bash_completion.d
>-CFLAGS += ${have_valgrind}
>+CFLAGS += ${have_valgrind} ${strndup} ${getline}
> EOF
This doesn't seem to do much for me, they don't seem to end up in the args
passed to g++. I'm no Makefile wizard, so I got notmuch finally compiling by
simply copy/pasting the ${strndup} and ${getline} from Makefile.config to
Makefile:
# Now smash together user's values with our extra values
override CFLAGS += $(WARN_FLAGS) $(extra_cflags) -Dstrndup=_notmuch_strndup
-Dgetline=_notmuch_getline
override CXXFLAGS += $(WARN_FLAGS) $(extra_cflags) $(extra_cxxflags)
-Dstrndup=_notmuch_strndup -Dgetline=_notmuch_getline
--
- Marten
[notmuch] [PATCH] notmuch-new: Remove the tiresome joke from the output.
On Fri, Nov 27, 2009 at 05:46:32AM -0800, Carl Worth wrote:
>> -} else {
>> -printf ("No new mail---and that's not much.\n");
>> }
>
>Shouldn't we still print *something* here, though ("No new mail")?
>Imagine the new user trying to ensure "notmuch new" is working---and
>let's say it's not, (due to the current symlink bug or so). A silent
>success here won't make it clear whether "notmuch new" has actually done
>anything or not.
Yes, at first I thought I'd read the patch wrong... I think you definately
want some output, just not the joke. Don't worry, it *was* funny the first
time.
--
- Marten
Re: [notmuch] [PATCH] Add tests to configure script to detect strndup and getline
On Mon, Nov 23, 2009 at 12:14:15PM -0600, Jeffrey C. Ollie wrote:
cat > Makefile.config <
This doesn't seem to do much for me, they don't seem to end up in the args
passed to g++. I'm no Makefile wizard, so I got notmuch finally compiling by
simply copy/pasting the ${strndup} and ${getline} from Makefile.config to
Makefile:
# Now smash together user's values with our extra values
override CFLAGS += $(WARN_FLAGS) $(extra_cflags) -Dstrndup=_notmuch_strndup
-Dgetline=_notmuch_getline
override CXXFLAGS += $(WARN_FLAGS) $(extra_cflags) $(extra_cxxflags)
-Dstrndup=_notmuch_strndup -Dgetline=_notmuch_getline
--
- Marten
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] notmuch-new: Remove the tiresome joke from the output.
On Fri, Nov 27, 2009 at 05:46:32AM -0800, Carl Worth wrote:
-} else {
- printf ("No new mail---and that's not much.\n");
}
Shouldn't we still print *something* here, though ("No new mail")?
Imagine the new user trying to ensure "notmuch new" is working---and
let's say it's not, (due to the current symlink bug or so). A silent
success here won't make it clear whether "notmuch new" has actually done
anything or not.
Yes, at first I thought I'd read the patch wrong... I think you definately
want some output, just not the joke. Don't worry, it *was* funny the first
time.
--
- Marten
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
