[notmuch] loss of duplicate messages

2010-02-05 Thread Marten Veldthuis
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


[notmuch] New wiki instance on the notmuchmail.org website

2010-02-03 Thread Marten Veldthuis
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

2010-02-03 Thread Marten Veldthuis
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

2010-02-03 Thread Marten Veldthuis
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

2010-02-03 Thread Marten Veldthuis
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

2010-02-03 Thread Marten Veldthuis
On Wed, 03 Feb 2010 08:47:41 -0800, Carl Worth cwo...@cworth.org 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


[notmuch] patchwork test instance (was: Git feature branch)

2010-02-02 Thread Marten Veldthuis
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] Introducing notmuchsync

2010-01-19 Thread Marten Veldthuis
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

2010-01-19 Thread Marten Veldthuis
On Tue, 19 Jan 2010 14:37:03 +0100, Sebastian Spaeth sebast...@sspaeth.de 
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

2010-01-18 Thread Marten Veldthuis
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

2010-01-18 Thread Marten Veldthuis
On Mon, 18 Jan 2010 16:12:28 +0100, Sebastian Spaeth sebast...@sspaeth.de 
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

2009-12-21 Thread Marten Veldthuis
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

2009-12-21 Thread Marten Veldthuis
On Mon, 21 Dec 2009 21:08:22 +1100, Alex Ghitza aghi...@gmail.com 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

2009-12-20 Thread Marten Veldthuis
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] [PATCH] Store the size of the file for each message

2009-12-19 Thread Marten Veldthuis
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

2009-12-19 Thread Marten Veldthuis
On Fri, 18 Dec 2009 21:24:10 -0800, Carl Worth cwo...@cworth.org 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?

2009-12-18 Thread Marten Veldthuis
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?

2009-12-18 Thread Marten Veldthuis
On Fri, 18 Dec 2009 22:21:54 +1100, Alex Ghitza aghi...@gmail.com 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 :)]

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


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


[notmuch] Threading

2009-12-15 Thread Marten Veldthuis
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] Threading

2009-12-15 Thread Marten Veldthuis
On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth cwo...@cworth.org 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?

2009-12-14 Thread Marten Veldthuis
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?

2009-12-13 Thread Marten Veldthuis
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

2009-12-11 Thread Marten Veldthuis
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] Threading

2009-12-10 Thread Marten Veldthuis
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

2009-12-10 Thread Marten Veldthuis
On Thu, 10 Dec 2009 09:39:48 -0800, Carl Worth cwo...@cworth.org 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

2009-12-07 Thread Marten Veldthuis
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

2009-12-07 Thread Marten Veldthuis
On Mon, 07 Dec 2009 15:02:03 -0400, David Bremner da...@tethera.net wrote:
 
 On Thu, 03 Dec 2009 14:27:05 -0800, Carl Worth cwo...@cworth.org 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

2009-12-05 Thread Marten Veldthuis
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] Recent (and forthcoming) improvements to the emacs interface

2009-12-04 Thread Marten Veldthuis
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


[notmuch] [PATCH 0/4] Make tags applied by 'notmuch new' configurable.

2009-12-03 Thread Marten Veldthuis
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] Recent (and forthcoming) improvements to the emacs interface

2009-12-03 Thread Marten Veldthuis
On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth cwo...@cworth.org 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 ke...@nicira.com
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 ke...@nicira.com

on my system (notice the From: header).

-- 
- 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

2009-11-27 Thread Marten Veldthuis
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.

2009-11-27 Thread Marten Veldthuis
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] notmuch-new: Remove the tiresome joke from the output.

2009-11-27 Thread Marten Veldthuis

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