On Thu, 25 Feb 2010 17:02:08 -0800, Carl Worth wrote:
> One distinction is that I have all of my "notmuch tag" commands operate
> globally rather than just on new messages. One of the things that really
> annoyed be about sup was that the support for automatic tagging worked
> as a hook on message
Excerpts from Arian Kuschki's message of Thu Feb 25 12:03:30 -0500 2010:
> On Sat 20, 12:34 -0500, Ben Gamari wrote:
>
> > The real problem is all notmuch calls are synchronous. Vim unfortunately
> > lacks the excellent asynchronous subprocess interface that emacs has.
> > Therefore, I'm afraid th
On Thu, 25 Feb 2010 17:02:08 -0800, Carl Worth wrote:
> One distinction is that I have all of my "notmuch tag" commands operate
> globally rather than just on new messages. One of the things that really
> annoyed be about sup was that the support for automatic tagging worked
> as a hook on message
Excerpts from Arian Kuschki's message of Thu Feb 25 12:03:30 -0500 2010:
> On Sat 20, 12:34 -0500, Ben Gamari wrote:
>
> > The real problem is all notmuch calls are synchronous. Vim unfortunately
> > lacks the excellent asynchronous subprocess interface that emacs has.
> > Therefore, I'm afraid th
On Sat 20, 12:34 -0500, Ben Gamari wrote:
> The real problem is all notmuch calls are synchronous. Vim unfortunately
> lacks the excellent asynchronous subprocess interface that emacs has.
> Therefore, I'm afraid the vim client is going to be just as unuable
> until someone has implemented asynchr
On Thu, 25 Feb 2010 16:25:16 -0500, James Vasile
wrote:
> I'm curious as to what people are doing in this regard.
I'm currently using a script that does tagging not entirely unlike
yours, (though my script isn't clever to retry a call to
notmuch---believe it or not I'm just calling it manually s
quot;tag:inbox AND tag:lca")
("meego" . "tag:inbox AND tag:meego")
("nickle" . "tag:inbox AND tag:nickle")
("pdx" . "tag:inbox AND tag:pdx")
("todo" . "tag:todo and not tag:cairo and not
tag:notmuch and not tag:intel")
("inteltodo" . "(tag:todo and tag:intel) or
tag:todo-intel")
("notmuchtodo" . "(tag:todo and tag:notmuch) or
tag:todo-notmuch")
("cairotodo" . "(tag:todo and tag:cairo) or
tag:todo-cairo")
))
-- 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/20100225/c9ddffa6/attachment.pgp>
Carl: The patch in the mail has problems; apparently I have to manually add
scissorlines to the mail for it
to be processed by git-am. I thought this was automatically added. (I hate the
git UI -- nothing is consistent,
concepts have different names, the definition of scissor lines is as precise
I'm slowly groping my way to using the notmuch emacs client as my
routine MUA. As I coerce it into tagging and displaying the way I want,
the next big question was automatically tagging things and getting them
in to notmuch.
I'm curious as to what people are doing in this regard.
My solution inv
I'm slowly groping my way to using the notmuch emacs client as my
routine MUA. As I coerce it into tagging and displaying the way I want,
the next big question was automatically tagging things and getting them
in to notmuch.
I'm curious as to what people are doing in this regard.
My solution inv
James Vasile(james at hackervisions.org)@240210-14:59:
> Can notmuch search for envelope-to:? Or for that matter, can it
> search for arbitrary headers?
>
> I get a lot of BCC mail. The envelope-to is a good way for me to know
> which of my various addresses was BCC'd.
I'm very new here, but I
On Thu, 25 Feb 2010 12:00:37 +1030, Tim Stoakes wrote:
> > I get a lot of BCC mail. The envelope-to is a good way for me to know
> > which of my various addresses was BCC'd.
>
> I'm very new here, but I think the answer is 'no' - notmuch only seems
> to index a few headers. Which is a pity - I u
On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins wrote:
> > 2. It removes the "inbox" and "unread" tags while adding the tag to
> >indicate deletion.
>
> Hey, Carl. Why is this last point important? [...]Why should it modify any
> other
> tags? A message/thread should be allowed to be b
I cannot comment on this patch, I just want to state that this
functionality can also be achieved with (id:87sk90ragj.fsf at jhu.edu)
"add functionality in notmuch search mode to add or remove tags by region"
and (id:1266408746-28549-1-git-send-email-Sebastian at SSpaeth.de)
"bind 'd' to new functi
On Wed, 24 Feb 2010 14:20:27 -0500, Jameson Rollins wrote:
> On Wed, 24 Feb 2010 10:26:47 -0800, Carl Worth wrote:
> > > It then checks the unread status in order to decide whether to proceed
> > > to the next again. So with your patch notmuch-show-next-unread-message
> > > will skip through all
On Wed, 24 Feb 2010 13:49:44 -0500, Jameson Rollins wrote:
> On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth wrote:
> > I think that's the open question still. How much of this kind of
> > functionality do we integrate into notmuch itself. I don't know the
> > answer to that question yet, but I'm
On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth wrote:
> On Mon, 18 Jan 2010 16:12:28 +0100, "Sebastian Spaeth" SSpaeth.de> wrote:
> >
> > - Synchronizes the "S" flag with the "unread" tag (1-way). The
> > synchronization direction is decided by using either --sync (change
> >
At Thu, 25 Feb 2010 11:53:14 +0100,
Sebastian Spaeth wrote:
>
> On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins finestructure.net> wrote:
> > > 2. It removes the "inbox" and "unread" tags while adding the tag to
> > >indicate deletion.
> >
> > Hey, Carl. Why is this last point important
tachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100225/d1283b69/attachment.pgp>
Carl: The patch in the mail has problems; apparently I have to manually add
scissorlines to the mail for it
to be processed by git-am. I thought this was automatically added. (I hate the
git UI -- nothing is consistent,
concepts have different names, the definition of scissor lines is as precise
At Thu, 25 Feb 2010 11:53:14 +0100,
Sebastian Spaeth wrote:
>
> On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins
> wrote:
> > > 2. It removes the "inbox" and "unread" tags while adding the tag to
> > >indicate deletion.
> >
> > Hey, Carl. Why is this last point important? [...]Why shoul
On Thu, 25 Feb 2010 12:00:37 +1030, Tim Stoakes wrote:
> > I get a lot of BCC mail. The envelope-to is a good way for me to know
> > which of my various addresses was BCC'd.
>
> I'm very new here, but I think the answer is 'no' - notmuch only seems
> to index a few headers. Which is a pity - I u
On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins
wrote:
> > 2. It removes the "inbox" and "unread" tags while adding the tag to
> >indicate deletion.
>
> Hey, Carl. Why is this last point important? [...]Why should it modify any
> other
> tags? A message/thread should be allowed to be
I cannot comment on this patch, I just want to state that this
functionality can also be achieved with (id:87sk90ragj@jhu.edu)
"add functionality in notmuch search mode to add or remove tags by region"
and (id:1266408746-28549-1-git-send-email-sebast...@sspaeth.de)
"bind 'd' to new function not
On Wed, 24 Feb 2010 14:20:27 -0500, Jameson Rollins
wrote:
> On Wed, 24 Feb 2010 10:26:47 -0800, Carl Worth wrote:
> > > It then checks the unread status in order to decide whether to proceed
> > > to the next again. So with your patch notmuch-show-next-unread-message
> > > will skip through al
On Wed, 24 Feb 2010 13:49:44 -0500, Jameson Rollins
wrote:
> On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth wrote:
> > I think that's the open question still. How much of this kind of
> > functionality do we integrate into notmuch itself. I don't know the
> > answer to that question yet, but I'm
On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth wrote:
> On Mon, 18 Jan 2010 16:12:28 +0100, "Sebastian Spaeth"
> wrote:
> >
> > - Synchronizes the "S" flag with the "unread" tag (1-way). The
> > synchronization direction is decided by using either --sync (change
> > maildir f
Hi Carl,
> Could you also write a commit message describing what the patch does?
> The easiest way for me to apply that would be if you would create a git
> commit, then run "git format-patch origin/master" and mail the resulting
> files, (the "git send-email" command can be used here, or you can
also sprach Carl Worth [2010.02.24.2008 +0100]:
> I agree that in its current form it's not useful, (it seems to be just a
> long list of the patches that have ever been submitted).
>
> I seem to recall Martin saying that patches that get accepted will be
> automatically detected and removed from
29 matches
Mail list logo
