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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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.
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
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
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
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
36 matches
Mail list logo
