f course
be slow if your query matches a lot of messages. Could this be done
by asyncronously writing to the buffer somehow?
best,
/p
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signatur
TL;DR: I can haz regex pl0x?
I've updated the regex a bit to prevent it from choking on the whole
"parens in subject vs. parens around tags vs. parens around matching
Message-Id's" deal, but it still causes errors in the search buffer due
to the list of Message-Id's being cut off at a seemingly
LGTM.
Quoth Louis Rilling on Jul 12 at 12:41 am:
> notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> maildir directory "new/" to maildir directory "cur/", which makes messages
> lose
> their "new" status in the MUA. However some users want to keep this "new"
> status a
Quoth Louis Rilling on Jul 12 at 12:38 am:
> On 11/07/11 16:07 -0400, Austin Clements wrote:
> > I worry that this may compound the confusion caused by mutt's handling
> > of the new flag, but I suppose people aren't likely to manipulate any
> > of the other maildir-synchronized flags without also
On Mon, Jul 11, 2011 at 3:07 PM, Jason Woofenden wrote:
> notmuch search tag:foo is slow!
>
> (when my e-mail files are not already in the disk cache)
>
> I saw on my activity monitor applet that it was using mostly i/o,
> and started to wonder if it was opening every e-mail. I little work
> with
Quoth Pieter Praet on Jul 11 at 10:43 pm:
> TL;DR: I can haz regex pl0x?
Oof, what a pain. I'm happy to change the output format of search; I
hadn't realized how difficult it would be to parse. In fact, I'm not
sure it's even parsable by regexp, because the message ID's themselves
could contain
LGTM.
Quoth Louis Rilling on Jul 12 at 12:41 am:
> notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
> maildir directory "new/" to maildir directory "cur/", which makes messages
> lose
> their "new" status in the MUA. However some users want to keep this "new"
> status a
Quoth Louis Rilling on Jul 12 at 12:38 am:
> On 11/07/11 16:07 -0400, Austin Clements wrote:
> > I worry that this may compound the confusion caused by mutt's handling
> > of the new flag, but I suppose people aren't likely to manipulate any
> > of the other maildir-synchronized flags without also
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However
The for loop right after already does the job.
Signed-off-by: Louis Rilling
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..64b6cf8 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _
Hello,
Here is an alternative, as we discussed earlier. This is enough to keep me
using mutt's ability to show the "new" status, and to allow me to test notmuch
with my real emails. Altough my notmuch config uses
[new]
tags=new;
[maildir]
synchronize_flags=true
m
--
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/7b9a1fe2/attachment.pgp>
I worry that this may compound the confusion caused by mutt's handling
of the new flag, but I suppose people aren't likely to manipulate any
of the other maildir-synchronized flags without also marking the
message as seen. At any rate, the change is certainly correct
technically. A few nits below
one cannot simply ignore
them.
Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/0c5a127e/attachment.pgp>
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However
On 11/07/11 16:07 -0400, Austin Clements wrote:
> I worry that this may compound the confusion caused by mutt's handling
> of the new flag, but I suppose people aren't likely to manipulate any
> of the other maildir-synchronized flags without also marking the
> message as seen.
Even if they don't
not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/897a55e0/attachment.pgp>
xchange seem to handle tags just fine.
Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/8ad36281/attachment.pgp>
On Mon, Jul 11, 2011 at 3:07 PM, Jason Woofenden wrote:
> notmuch search tag:foo is slow!
>
> (when my e-mail files are not already in the disk cache)
>
> I saw on my activity monitor applet that it was using mostly i/o,
> and started to wonder if it was opening every e-mail. I little work
> with
Hi all,
I'm having a great time patching up the vim frontend, but I've got
an issue that is in the backend, and seems far above my head at
this point:
notmuch search tag:foo is slow!
(when my e-mail files are not already in the disk cache)
I saw on my activity monitor applet that it was using m
Hi Jason,
On Mon, Jul 11, 2011 at 03:07:21PM -0400, Jason Woofenden wrote:
> notmuch search tag:foo is slow!
>
yes, i've just used the vim ui for the first time and i agreee, its sluggish,
searching for * takes a while.
> (when my e-mail files are not already in the disk cache)
>
> I saw on my a
Add a new setting: g:notmuch_nicknames (dictionary)
When reformatting the list of senders in the search view, replace any names
matching keys in g:notmuch_nicknames with the corresponding values.
---
vim/plugin/notmuch.vim | 19 ++-
1 files changed, 18 insertions(+), 1 deletions
I implemented a feature I wanted: nicknames for the list of senders
on the search view.
At first I just added a setting with my full name and had it
replace that with "me". But then I figured it'd be better to allow
the user to specify a list of replacements, and instead made a more
general "nickn
Quoth Pieter Praet on Jul 11 at 10:43 pm:
> TL;DR: I can haz regex pl0x?
Oof, what a pain. I'm happy to change the output format of search; I
hadn't realized how difficult it would be to parse. In fact, I'm not
sure it's even parsable by regexp, because the message ID's themselves
could contain
On Mon, 11 Jul 2011 11:24:57 +0200, Felix Geller wrote:
> Hi Dmitry,
>
> thank you for the comments. I included an updated patch that also
> includes Daniel's comment regarding the default value.
>
Another thing that would be nice to have is a test for this feature.
Regards,
Dmitry
> I did
TL;DR: I can haz regex pl0x?
I've updated the regex a bit to prevent it from choking on the whole
"parens in subject vs. parens around tags vs. parens around matching
Message-Id's" deal, but it still causes errors in the search buffer due
to the list of Message-Id's being cut off at a seemingly
I worry that this may compound the confusion caused by mutt's handling
of the new flag, but I suppose people aren't likely to manipulate any
of the other maildir-synchronized flags without also marking the
message as seen. At any rate, the change is certainly correct
technically. A few nits below
Hi Felix.
On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller wrote:
> Hi,
>
> I added a variable to toggle message indentation in Emacs.
>
> Please let me know what you think.
>
I like the change. Though I do not think I would use it without
chronological sorting.
Comments on the code below.
---
NEWS | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index f3fefad..98a6b28 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,16 @@
+Notmuch 0.7 (-MM-DD)
+===
+New emacs-interface features
+
+Customizab
Julien Valroth reported on IRC that he had problems with the initial
call of 'notmuch new' crashing with
terminate called after throwing an instance of 'Xapian::InvalidArgumentError'
I confirmed that the following quick and dirty patch seems to fix the problem.
--- a/lib/Makefile.local
+++ b/li
ean)
> > +
> > (defcustom notmuch-show-indent-multipart nil
> >"Should the sub-parts of a multipart/* part be indented?"
> >;; dme: Not sure which is a good default.
> > @@ -237,8 +242,9 @@ unchanged ADDRESS if parsing fails."
> >"Insert a notmuch style headerline based on HEADERS for a
> > message at DEPTH in the current thread."
> >(let ((start (point)))
> > -(insert (notmuch-show-spaces-n depth)
> > - (notmuch-show-clean-address (plist-get headers :From))
> > +(when notmuch-show-indent-messages-in-thread
> > + (insert (notmuch-show-spaces-n depth)))
> > +(insert (notmuch-show-clean-address (plist-get headers :From))
> > " ("
> > date
> > ") ("
> > @@ -733,7 +739,8 @@ current buffer, if possible."
> > (setq content-end (point-marker))
> >
> > ;; Indent according to the depth in the thread.
> > -(indent-rigidly content-start content-end depth)
> > +(when notmuch-show-indent-messages-in-thread
> > + (indent-rigidly content-start content-end depth))
> >
> > (setq message-end (point-max-marker))
> >
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/2f498710/attachment.pgp>
Hi all,
I'm having a great time patching up the vim frontend, but I've got
an issue that is in the backend, and seems far above my head at
this point:
notmuch search tag:foo is slow!
(when my e-mail files are not already in the disk cache)
I saw on my activity monitor applet that it was using m
If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347 at megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.
Signed-off-by: Sebastian Spaeth
---
DO
If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347 at megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.
Signed-off-by: Sebastian Spaeth
---
Pa
Add a new setting: g:notmuch_nicknames (dictionary)
When reformatting the list of senders in the search view, replace any names
matching keys in g:notmuch_nicknames with the corresponding values.
---
vim/plugin/notmuch.vim | 19 ++-
1 files changed, 18 insertions(+), 1 deletions
I implemented a feature I wanted: nicknames for the list of senders
on the search view.
At first I just added a setting with my full name and had it
replace that with "me". But then I figured it'd be better to allow
the user to specify a list of replacements, and instead made a more
general "nickn
- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/894c58b8/attachment.pgp>
ean-address (plist-get headers :From))
" ("
date
") ("
@@ -733,7 +739,8 @@ current buffer, if possible."
(setq content-end (point-marker))
;; Indent according to the depth in the thread.
-(indent-rigidly content-start content-end depth)
+(when notmuch-show-indent-messages-in-thread
+ (indent-rigidly content-start content-end depth))
(setq message-end (point-max-marker))
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/c06d16f6/attachment.pgp>
: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/093d09f2/attachment.pgp>
t-rigidly content-start content-end depth))
(setq message-end (point-max-marker))
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 202 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/0b97f29c/attachment.pgp>
On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller wrote:
> I added a variable to toggle message indentation in Emacs.
Hi, Felix. Thanks for submitting this patch. I think it's a good idea.
I have a couple of comments below, a couple of which echo what Dmitry
has already pointed out.
> diff --gi
ion/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/e8af4a37/attachment.pgp>
On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth
wrote:
> The answer is that things are very implicit. notmuch.h speaks of
> strings but never mentions encodings
Much of this was intentional on my part.
For example, I intentionally avoided restrictions on what could be
stored as a tag in th
vailable
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110711/c0bb71c7/attachment.pgp>
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However
The for loop right after already does the job.
Signed-off-by: Louis Rilling
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..64b6cf8 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _
Hello,
Here is an alternative, as we discussed earlier. This is enough to keep me
using mutt's ability to show the "new" status, and to allow me to test notmuch
with my real emails. Altough my notmuch config uses
[new]
tags=new;
[maildir]
synchronize_flags=true
m
Hi all,
after I was notified about how notmuch's python bindings perform
differently depending on whether we hand it (byte-based) ASCII strings
or unicode, I tried to disentangle what encodings to expect and send it
to. The answer is that things are very implicit. notmuch.h speaks of
strings but ne
On Mon, 11 Jul 2011 15:22:24 +0200, Sebastian Spaeth
wrote:
> > Support for tags is mentioned in the RFC for IMAP, but it's optional. As
> > far as I know, must servers today support them though.
>
> I can't speak for Gmail, but all major servers, ie Cyrus, Dovecot, and
> even Exchange seem to h
On Wed, 06 Jul 2011 20:46:48 +0200, Daniel Schoepe
wrote:
> One problem is that maildir doesn't support tags, so we would have to
> switch to a format that does or somehow store them in the maildir, in
> which case we would also have to adapt offlineimap or a similar tool to
> sync tags as well.
---
NEWS | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index f3fefad..98a6b28 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,16 @@
+Notmuch 0.7 (-MM-DD)
+===
+New emacs-interface features
+
+Customizab
On Mon, 11 Jul 2011 13:55:24 +0400, Dmitry Kurochkin
wrote:
> On Mon, 11 Jul 2011 11:24:57 +0200, Felix Geller wrote:
> > Hi Dmitry,
> >
> > thank you for the comments. I included an updated patch that also
> > includes Daniel's comment regarding the default value.
> >
>
> Another thing that
On Mon, 11 Jul 2011 11:24:57 +0200, Felix Geller wrote:
> Hi Dmitry,
>
> thank you for the comments. I included an updated patch that also
> includes Daniel's comment regarding the default value.
>
Another thing that would be nice to have is a test for this feature.
Regards,
Dmitry
> I did
If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347@megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.
Signed-off-by: Sebastian Spaeth
---
DOH,
If we pass in an unicode instance as query string, we would probably get
weird behavior (and indeed do so, see mail
id:"20110707113700.GA16347@megatron"). If a unicode instance is passed
in, make sure we encode it properly to an utf-8 encoded byte string.
Signed-off-by: Sebastian Spaeth
---
Patri
On Thu, 7 Jul 2011 12:37:00 +0100, Patrick Totzke
wrote:
> Hi!
> Something strange goes on when I use unicode literals as querystrings:
> Database().create_query(u'teststring') yields different results than
> Database().create_query('teststring')..
>
> Now it should not be a problem to decode th
Hi Dmitry,
thank you for the comments. I included an updated patch that also
includes Daniel's comment regarding the default value.
I didn't change the "when" though--not because of personal reasons
;)--but because it is used for determining indentation of multi-parts.
Cheers,
Felix
On Mon,
Hi Felix,
On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller wrote:
> +(defcustom notmuch-show-indent-messages-in-thread nil
> + "Should the messages in a thread be indented according to their respective
> depth in the thread?"
> + :group 'notmuch
> + :type 'boolean)
> +
I think this should de
Hi Felix.
On Mon, 11 Jul 2011 10:42:04 +0200, Felix Geller wrote:
> Hi,
>
> I added a variable to toggle message indentation in Emacs.
>
> Please let me know what you think.
>
I like the change. Though I do not think I would use it without
chronological sorting.
Comments on the code below.
Hi,
I added a variable to toggle message indentation in Emacs.
Please let me know what you think.
Cheers,
Felix
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index a433dec..8101c27 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -90,6 +90,11 @@ any given message
Before they'd often miss the last line
---
vim/plugin/notmuch.vim | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index 2095547..12a0f88 100644
--- a/vim/plugin/notmuch.vim
+++ b/vim/plugin/notmuch.vim
@@ -747,8 +74
The vim front-end isn't written to handle nested parts.
This patch doesn't change that, it just changes the code to pretend that
multipart/* sections end immediately. This makes the parsing code think that
all sections are top-level, and are thus parsed well enough.
The lovely result of this is t
Also change a passed parameter to be consistent with the current binding. This
parameter appears to be unused.
---
vim/plugin/notmuch.vim |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vim/plugin/notmuch.vim b/vim/plugin/notmuch.vim
index e4b22d3..3982008 100644
--- a/
This patch rewrites the reformatting of the from list so it shows full
capitalized names when available (without truncating them as the old code did)
and removes the pipe characters that appear between some names.
The old code appears to assume from list (the list of senders in the thread)
coming
In vim, in the message view, space is supposed to remove the "unread" and
"inbox" tags, but was sometimes adding them instead.
This patch assures that they are always removed by this binding.
---
vim/plugin/notmuch.vim |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/vim/
OK, everybody, here's my first set of patches. They all cleanup the
vim front-end. I started with the little stuff, to get my feet wet.
Here's what's coming:
[PATCH 1/5] vim: fix space key: now archives (did opposite)
[PATCH 2/5] vim: fix from list reformatting in search view
[PATCH 3/5] vim: fix
66 matches
Mail list logo
