Initial attempt at a "merge window" for notmuch
On Fri, 09 Apr 2010, Mark Anderson wrote:
> On Fri, 9 Apr 2010 11:29:20 -0500, Carl Worth wrote:
> > Of course, it's the same set-theoretic operation I described earlier. I
> > want the set of threads having messages matching:
> >
> > tag:notmuch and
> >
> > intersected with the set of threads having messages matching:
> >
> > tag:notmuch and not ("merged" or "postponed")
> >
> > So I've got uses cases for set-difference and intersection already. Now
> > we just need some search syntax to express that.
> >
>
> Can we just start grouping with a set:( ) or { } on the command line?
> I'm guessing the parentheses are slightly easier.
>
>set:( tag:notmuch and )
> isect
>set:( tag:notmuch and not (tag:merged or tag:postponed) )
If we go in this direction, I think that the syntax should explicitely
state the it is the set of threads and not the set of messages. So maybe
something like
threads:( ... ) isect threads:( ... )
> Just thinking about completeness, I wonder if there are some searches
> for threads that aren't currently available.
I think that having a way for searching all threads started by a certain
person (e.g. project maintainer) would be very useful. For this we may
need some search operator for specifying the position of the message in
the thread. For example: notmuch search from:cworth and position:first.
In id:4b9d4e24.0f67f10a.31e3.adf7 at mx.google.com, Sandra asked for
something like: notmuch search not threads:( from:me and position:last )
-Michal
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010, Jameson Rollins wrote: > On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka > wrote: > > On Sat, 10 Apr 2010, Carl n?tmuch ? Worth wrote: > > > Are you all trying to show a problem here? All of the above comes > > > through fine. Perhaps it's only with non-ASCII in the From line being > > > replied to? > > > > Yes and also in Subject line. You can test this with > > id:87r5o1etjb.fsf at steelpick.localdomain. > > Again, this subject line shows up fine for me in notmuch-show in emacs. > I believe the non-ASCII characters in headers have to be escaped for > mail handlers to properly handle them, and the reader should translate. > I need to find a reference for this... Yes. It is displayed correctly in notmuch-show mode, but try to reply (press 'r') to the message and you will see. If you do not see it in emacs, try running notmuch reply id:87r5o1etjb.fsf at steelpick.localdomain and you will see the encoded headers. There is no problem with sending such a mail. All recipients will see the headers decoded correctly. The problem is, that I (the one who writes the reply) do not know what is written in subject and what are the names of non-ascii named recipients. If notmuch reply command decodes the headers, as implemented by the patch, then Emacs (or some other part of mail sending chain?) will encode the headers again before the message is actually sent. -Michal
RFC: User-Agent header
On Thu, 08 Apr 2010 08:12:47 -0700, Dirk Hohndel wrote: > On Thu, 08 Apr 2010 10:26:01 +0200, "Sebastian Spaeth" SSpaeth.de> wrote: > > notmuch is (mostly) not responsible for sending email. However, people > > using the emacs frontend use notmuch to create the reply. > > > > Am I the only one who is sometimes curious as to what mail agents others > > use? Would it be useful to insert a header to notmuch reply analog to: > > > > User-Agent: Mutt/1.5.13 (2006-08-11) > > > > We could reuse the same version string that we use for the release (or > > the git string that was used to build notmuch). I can use this to create > > nice stats :). > > > > No patch yet, just asking if this is a good idea or not. > > I think it's a very good idea. But it should be something that includes > the other components of how you send email... I totally agree with this and Carl's proposition is really what I would want to see. The only problem is: how do you implement a generic solution for all possible backends ? I know a possibility for mail-mode but I do not know how to do this for message-mode. And even If I'd know that's only targeted to GNU Emacs' users. Xavier
RFC: User-Agent header
On 2010-04-10, Carl Worth wrote: > So I propose something like: > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) That looks good to me. So I assume the correct strategy here would be to: 1) have notmuch reply insert a header: User-Agent: Notmuch/0.2 (http://notmuchmail.org) 2) have notmuch-reply.el (or whatever) add a setup mail hook that searches for an existing User-Agent header and appends " Emacs/23.1.1 (gnu/linux)" One issue is again, such a hook would be message mode specific, so gnus users might not appreciate that. Also when composing a message via c-x m this would not work. So perhaps an all lisp solution? Again, can we hijack message mode to add our own promotion header? Or has the time come for a notmuch-message-mode that somehow inherits from message mode? bremner said something about dynamic bindings that would allow that. Sebastian
[notmuch] Bulk message tagging
Hi, On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson wrote: > > I think that '*' is definitely an awesome command, but I wonder if we > shouldn't have another command for the notmuch-search buffer which means > 'tag all the threads that I can see in this buffer'. This is exactly what my initial post asked for. '*' is not totally satisfying for me due to the "limitations" you exposed. Though It is a good and acceptable workaround for me. As said, I just have to pay attention to redo my search query before pressing the '*' key. Xavier
Re: Initial attempt at a "merge window" for notmuch
On Sat, 10 Apr 2010 22:24:01 +0200, Michal Sojka wrote: > In id:4b9d4e24.0f67f10a.31e3.a...@mx.google.com, Sandra asked for > something like: notmuch search not threads:( from:me and position:last ) Naw, actually I forgot to follow that up. I was looking for it to work it already worked, I just had a little PEBKAC going on. Basically, what I wanted was to tag specific *messages* based on search criteria and I was under the impression that the system tagged *threads*, but after using it for a while, it seems that it does tag messages. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Initial attempt at a "merge window" for notmuch
On 2010-04-09, Carl Worth wrote: > > Here's the current list: Having such a list is great. So now we need to get you a key-binding that says, "take query xy results and stuff them into the wiki" (or some pastebin like service with a fixed URL). Looking forward to 0.2. Sebastian (THanks to the debian pkgs I can now use notmuch on my netbook which has not compiler installed. Very useful, thanks. Now the issue of syncing tags is becoming more pressing for me :-) )
Plans for the 0.2 release (this week)
On 2010-04-10, Carl n?tmuch ? Worth wrote: > Are you all trying to show a problem here? All of the above comes > through fine. Perhaps it's only with non-ASCII in the From line being > replied to? Let's test that here... I think there are 2 issues being discussed here. One is the encoding in the subject line (which does not look pretty in compose mail, but seems to be the standard). I did not refer to that. What I referred to was the json output as the encode_as_json_string (or however it is called), simply drops chars >127, leading to missing letters in e.g. the author names etc. I could see that in the web frontends that are making use of json already, and once (if?) emacs uses the json output too, this will become an issue there too. Certainly not urgent, but it looked quite weird in the web frontends. Sebastian
[notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id
On 2010-04-09, Jesse Rosenthal wrote: > sporadic access. However, one question: it looks like it was V2 of the > patch that you pushed -- was it? Unfortunately, there was a subtle bug > that kept on popping up (when you call notmuch-show interactively, which > rarely happens). Later in this same thread, I offered V4 (yep, there was > a problematic V3 too) which fixes this: I think I picked v4 for merging, however removing the comment (supercedes v1-3) from the commit messages. I hope that was ok with you. Sebastian
[notmuch] Debian package update ?
Hi Carl, On Wed, 07 Apr 2010 09:43:47 -0700, Carl Worth wrote: > On Mon, 05 Apr 2010 08:12:51 +0200, Xavier Maillard wrote: > > I feel like being far behind master with my current (official) > > Debian package. Is there any chance to get a more recent one soon ? > > I did update the Debian packaging yesterday, and uploaded new > packages. (The upload might take a while before it appears since it > added new libnotmuch1 and libnotmuch-dev packages that will have to be > approved.) Got it now ! Thank you very much. > It took me a while to get around to updating the Debian package because > the new library meant reworking the package a bit, I wanted to do an > actual tar-file release before a new package, etc. Like I said before, I wish I could have learnt how to package it by myself but, it is out of my knowledge :/ > With all of that stuff implemented now, it should be a very quick > process to update the packages in the future. So hopefully there won't > be much skew going forward. That's perfect ! I switched to a packaged distro just not to install every tarball possible everywhere into my root :) Xavier
Re: Initial attempt at a "merge window" for notmuch
On Fri, 09 Apr 2010, Mark Anderson wrote:
> On Fri, 9 Apr 2010 11:29:20 -0500, Carl Worth wrote:
> > Of course, it's the same set-theoretic operation I described earlier. I
> > want the set of threads having messages matching:
> >
> > tag:notmuch and
> >
> > intersected with the set of threads having messages matching:
> >
> > tag:notmuch and not ("merged" or "postponed")
> >
> > So I've got uses cases for set-difference and intersection already. Now
> > we just need some search syntax to express that.
> >
>
> Can we just start grouping with a set:( ) or { } on the command line?
> I'm guessing the parentheses are slightly easier.
>
>set:( tag:notmuch and )
> isect
>set:( tag:notmuch and not (tag:merged or tag:postponed) )
If we go in this direction, I think that the syntax should explicitely
state the it is the set of threads and not the set of messages. So maybe
something like
threads:( ... ) isect threads:( ... )
> Just thinking about completeness, I wonder if there are some searches
> for threads that aren't currently available.
I think that having a way for searching all threads started by a certain
person (e.g. project maintainer) would be very useful. For this we may
need some search operator for specifying the position of the message in
the thread. For example: notmuch search from:cworth and position:first.
In id:4b9d4e24.0f67f10a.31e3.a...@mx.google.com, Sandra asked for
something like: notmuch search not threads:( from:me and position:last )
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010, Jameson Rollins wrote: > On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka wrote: > > On Sat, 10 Apr 2010, Carl n∅tmuch 䚳 Worth wrote: > > > Are you all trying to show a problem here? All of the above comes > > > through fine. Perhaps it's only with non-ASCII in the From line being > > > replied to? > > > > Yes and also in Subject line. You can test this with > > id:87r5o1etjb@steelpick.localdomain. > > Again, this subject line shows up fine for me in notmuch-show in emacs. > I believe the non-ASCII characters in headers have to be escaped for > mail handlers to properly handle them, and the reader should translate. > I need to find a reference for this... Yes. It is displayed correctly in notmuch-show mode, but try to reply (press 'r') to the message and you will see. If you do not see it in emacs, try running notmuch reply id:87r5o1etjb@steelpick.localdomain and you will see the encoded headers. There is no problem with sending such a mail. All recipients will see the headers decoded correctly. The problem is, that I (the one who writes the reply) do not know what is written in subject and what are the names of non-ascii named recipients. If notmuch reply command decodes the headers, as implemented by the patch, then Emacs (or some other part of mail sending chain?) will encode the headers again before the message is actually sent. -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: User-Agent header
On Thu, 08 Apr 2010 08:12:47 -0700, Dirk Hohndel wrote: > On Thu, 08 Apr 2010 10:26:01 +0200, "Sebastian Spaeth" > wrote: > > notmuch is (mostly) not responsible for sending email. However, people > > using the emacs frontend use notmuch to create the reply. > > > > Am I the only one who is sometimes curious as to what mail agents others > > use? Would it be useful to insert a header to notmuch reply analog to: > > > > User-Agent: Mutt/1.5.13 (2006-08-11) > > > > We could reuse the same version string that we use for the release (or > > the git string that was used to build notmuch). I can use this to create > > nice stats :). > > > > No patch yet, just asking if this is a good idea or not. > > I think it's a very good idea. But it should be something that includes > the other components of how you send email... I totally agree with this and Carl's proposition is really what I would want to see. The only problem is: how do you implement a generic solution for all possible backends ? I know a possibility for mail-mode but I do not know how to do this for message-mode. And even If I'd know that's only targeted to GNU Emacs' users. Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Bulk message tagging
Hi, On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson wrote: > > I think that '*' is definitely an awesome command, but I wonder if we > shouldn't have another command for the notmuch-search buffer which means > 'tag all the threads that I can see in this buffer'. This is exactly what my initial post asked for. '*' is not totally satisfying for me due to the "limitations" you exposed. Though It is a good and acceptable workaround for me. As said, I just have to pay attention to redo my search query before pressing the '*' key. Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Debian package update ?
Hi Carl, On Wed, 07 Apr 2010 09:43:47 -0700, Carl Worth wrote: > On Mon, 05 Apr 2010 08:12:51 +0200, Xavier Maillard wrote: > > I feel like being far behind master with my current (official) > > Debian package. Is there any chance to get a more recent one soon ? > > I did update the Debian packaging yesterday, and uploaded new > packages. (The upload might take a while before it appears since it > added new libnotmuch1 and libnotmuch-dev packages that will have to be > approved.) Got it now ! Thank you very much. > It took me a while to get around to updating the Debian package because > the new library meant reworking the package a bit, I wanted to do an > actual tar-file release before a new package, etc. Like I said before, I wish I could have learnt how to package it by myself but, it is out of my knowledge :/ > With all of that stuff implemented now, it should be a very quick > process to update the packages in the future. So hopefully there won't > be much skew going forward. That's perfect ! I switched to a packaged distro just not to install every tarball possible everywhere into my root :) Xavier ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010, Carl n?tmuch ? Worth wrote: > > On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth" > SSpaeth.de> wrote: > > > On 2010-04-09, Michal Sojka wrote: > > > Perhaps Carl should get more N?rw?g?a? friends, :-). > > > > Or G?rm?n or ?? > > Are you all trying to show a problem here? All of the above comes > through fine. Perhaps it's only with non-ASCII in the From line being > replied to? Yes and also in Subject line. You can test this with id:87r5o1etjb.fsf at steelpick.localdomain. Michal
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 15:52:04 +0200, "Sebastian Spaeth" wrote: > frontends that are making use of json already, and once (if?) emacs uses > the json output too, this will become an issue there too. once, not if! jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100410/111461f0/attachment.pgp>
RFC: User-Agent header
On Fri, 09 Apr 2010 19:55:17 -0700, Carl Worth wrote: > So I propose something like: > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) The problem I see is that if we go with this proposal, our mail will have inconsistent User-Agent: header, depending on if the message was new or if it's a reply. Maybe that's not too big of an issue, though, since the in the reply case notmuch is generating some of the headers, whereas they're all generated by emacs in the new message case. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100410/ecaa859e/attachment.pgp>
Re: [PATCH] notmuch new --new-tags=tags...
On Sun, 11 Apr 2010 01:03:04 +1000, Anthony Towns wrote: > Hi *, > > The attached patch makes "notmuch new --new-tags=unread,new" set the > "unread" and "new" tags on any new mail it finds rather than "unread" > and "inbox". Or whatever other tags you happen to specify. I really like this - I have a similar patch that hardcodes a +new tag that I use to figure out which emails were imported during the last run of notmuch new - and that I then clear as the final step in my initial tagging script. But this is much cleaner and more generic. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] notmuch new --new-tags=tags...
On Sun, 11 Apr 2010 01:03:04 +1000, Anthony Towns wrote: > Hi *, > > The attached patch makes "notmuch new --new-tags=unread,new" set the > "unread" and "new" tags on any new mail it finds rather than "unread" > and "inbox". Or whatever other tags you happen to specify. I really like this - I have a similar patch that hardcodes a +new tag that I use to figure out which emails were imported during the last run of notmuch new - and that I then clear as the final step in my initial tagging script. But this is much cleaner and more generic. /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 09:06:54 -0400, Jameson Rollins wrote: > Again, this subject line shows up fine for me in notmuch-show in emacs. > I believe the non-ASCII characters in headers have to be escaped for > mail handlers to properly handle them, and the reader should translate. > I need to find a reference for this... I think this is the relevant RFC: http://tools.ietf.org/html/rfc5335 Basically, I think that emacs is doing the right thing here. This isn't a notmuch issue at all. The headers have to be encoded this way for the MTAs. Your reader (ie. emacs) should be doing the translation for you. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100410/9fdaf0d8/attachment.pgp>
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka wrote: > On Sat, 10 Apr 2010, Carl n?tmuch ? Worth wrote: > > Are you all trying to show a problem here? All of the above comes > > through fine. Perhaps it's only with non-ASCII in the From line being > > replied to? > > Yes and also in Subject line. You can test this with > id:87r5o1etjb.fsf at steelpick.localdomain. Again, this subject line shows up fine for me in notmuch-show in emacs. I believe the non-ASCII characters in headers have to be escaped for mail handlers to properly handle them, and the reader should translate. I need to find a reference for this... jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100410/14c96199/attachment.pgp>
Plans for the 0.2 release (this week)
On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel wrote: > On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel > wrote: > > > > here's what's going wrong. Look at the To: line... > > Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth , The To: line shows up fine in notmuch-show for me (in emacs). It only shows up like this when editing. I think this is actually a general mail issue, and is not a notmuch issue. I don't understand all the issues, but I think non-ASCII characters in headers have to be encoded, and that's what you're seeing. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100410/30ee3848/attachment-0001.pgp>
[PATCH] git: Ignore packaging intermediate files
commit c9ff373f8bdcc6b55c6df8e0d4582d459ef87c31 Author: David Edmondson Date: Sat Apr 10 09:02:32 2010 +0100 git: Ignore packaging intermediate files Modified .gitignore diff --git a/.gitignore b/.gitignore index 217440d..c685340 100644 --- a/.gitignore +++ b/.gitignore @@ -13,3 +13,27 @@ libnotmuch.so* .*.swp *.elc releases +/debian/files +/debian/libnotmuch-dev.debhelper.log +/debian/libnotmuch-dev.substvars +/debian/libnotmuch-dev/DEBIAN/control +/debian/libnotmuch-dev/DEBIAN/md5sums +/debian/libnotmuch-dev/usr/include/notmuch.h +/debian/libnotmuch-dev/usr/share/doc/libnotmuch-dev/changelog.Debian.gz +/debian/libnotmuch-dev/usr/share/doc/libnotmuch-dev/copyright +/debian/libnotmuch1.debhelper.log +/debian/libnotmuch1.postinst.debhelper +/debian/libnotmuch1.postrm.debhelper +/debian/libnotmuch1.substvars +/debian/libnotmuch1/DEBIAN/control +/debian/libnotmuch1/DEBIAN/md5sums +/debian/libnotmuch1/DEBIAN/postinst +/debian/libnotmuch1/DEBIAN/postrm +/debian/libnotmuch1/DEBIAN/shlibs +/debian/libnotmuch1/usr/share/doc/libnotmuch1/changelog.Debian.gz +/debian/libnotmuch1/usr/share/doc/libnotmuch1/copyright +/debian/notmuch.debhelper.log +/debian/notmuch.postinst.debhelper +/debian/notmuch.prerm.debhelper +/debian/notmuch.substvars +/debian/tmp/usr/include/notmuch.h dme. -- David Edmondson, http://dme.org
[PATCH] notmuch new --new-tags=tags...
Hi *,
The attached patch makes "notmuch new --new-tags=unread,new" set the
"unread" and "new" tags on any new mail it finds rather than "unread"
and "inbox". Or whatever other tags you happen to specify.
Signed-off-by: Anthony Towns
---
NEWS |3 +++
notmuch-new.c | 49 +
notmuch.1 | 19 ++-
notmuch.c |7 ++-
4 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/NEWS b/NEWS
index f29ac27..cbfae5a 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+The "notmuch new" command accepts a "--new-tags=tags..." option to override
+the default tags applied to new mail.
+
Notmuch 0.1 (2010-04-05)
This is the first release of the notmuch mail system.
diff --git a/notmuch-new.c b/notmuch-new.c
index 44b50aa..77c99e0 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -32,6 +32,11 @@ typedef struct _filename_list {
_filename_node_t **tail;
} _filename_list_t;
+typedef struct _tag_list {
+char *tag;
+struct _tag_list *next;
+} _tag_list_t;
+
typedef struct {
int output_is_a_tty;
int verbose;
@@ -41,6 +46,8 @@ typedef struct {
int added_messages;
struct timeval tv_start;
+_tag_list_t *new_msg_tags;
+
_filename_list_t *removed_files;
_filename_list_t *removed_directories;
} add_files_state_t;
@@ -93,11 +100,40 @@ _filename_list_add (_filename_list_t *list,
list->tail = &node->next;
}
+static _tag_list_t *
+_parse_tags (void *ctx, const char *orig_str)
+{
+_tag_list_t *tag_head = NULL, **tag_tail = &tag_head;
+char *dupe_str, *start, *comma;
+
+dupe_str = talloc_strdup(ctx, orig_str);
+start = dupe_str;
+
+do {
+ comma = strchr(start, ',');
+ if (comma)
+ *(comma++) = '\0';
+
+ if (*start != '\0') {
+ *tag_tail = talloc(dupe_str, _tag_list_t);
+ (*tag_tail)->tag = start;
+ (*tag_tail)->next = NULL;
+ tag_tail = &(*tag_tail)->next;
+ }
+
+ start = comma;
+} while (start);
+
+return tag_head;
+}
+
static void
-tag_inbox_and_unread (notmuch_message_t *message)
+tag_new_message (add_files_state_t *state, notmuch_message_t *message)
{
-notmuch_message_add_tag (message, "inbox");
-notmuch_message_add_tag (message, "unread");
+_tag_list_t *cur;
+for (cur = state->new_msg_tags; cur; cur = cur->next) {
+ notmuch_message_add_tag (message, cur->tag);
+}
}
static void
@@ -412,7 +448,7 @@ add_files_recursive (notmuch_database_t *notmuch,
/* success */
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
- tag_inbox_and_unread (message);
+ tag_new_message (state, message);
break;
/* Non-fatal issues (go on to next file) */
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
@@ -714,6 +750,7 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
struct stat st;
const char *db_path;
char *dot_notmuch_path;
+const char *new_msg_tags = "inbox,unread";
struct sigaction action;
_filename_node_t *f;
int renamed_files, removed_files;
@@ -726,12 +763,16 @@ notmuch_new_command (void *ctx, int argc, char *argv[])
for (i = 0; i < argc && argv[i][0] == '-'; i++) {
if (STRNCMP_LITERAL (argv[i], "--verbose") == 0) {
add_files_state.verbose = 1;
+ } else if (STRNCMP_LITERAL (argv[i], "--new-tags=") == 0) {
+ new_msg_tags = argv[i]+strlen("--new-tags=");
} else {
fprintf (stderr, "Unrecognized option: %s\n", argv[i]);
return 1;
}
}
+add_files_state.new_msg_tags = _parse_tags(ctx, new_msg_tags);
+
config = notmuch_config_open (ctx, NULL, NULL);
if (config == NULL)
return 1;
diff --git a/notmuch.1 b/notmuch.1
index 86830f4..3bab17c 100644
--- a/notmuch.1
+++ b/notmuch.1
@@ -85,7 +85,7 @@ The
command is used to incorporate new mail into the notmuch database.
.RS 4
.TP 4
-.B new
+.BR new " [options...]"
Find and import any new messages to the database.
@@ -109,6 +109,23 @@ whenever new mail is delivered and you wish to
incorporate it into the
database. These subsequent runs will be much quicker than the initial
run.
+Supported options for
+.B new
+include:
+.RS 4
+.TP 4
+.BR \-\-new\-tags= tags...
+
+Set the listed tags (separated by commas) on new messages
+instead of the default
+.B "inbox"
+and
+.B "unread"
+tags.
+
+.RE
+.RS 4
+
Invoking
.B notmuch
with no command argument will run
diff --git a/notmuch.c b/notmuch.c
index dcfda32..f7b16e3 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -126,7 +126,7 @@ command_t commands[] = {
"\tInvoking notmuch with no command argument will run setup if\n"
"\tthe setup command has not previously been completed." },
{ "new", notmuch_new_command,
- "[--verbose]",
+ "[--verbose] [--new-tags=inbox,unread]",
"Find and import new messages to the notmu
Re: RFC: User-Agent header
On Sat, 10 Apr 2010 16:00:49 +0200, "Sebastian Spaeth" wrote: > On 2010-04-10, Carl Worth wrote: > > So I propose something like: > > > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) > > That looks good to me. So I assume the correct strategy here would be > to: > > 1) have notmuch reply insert a header: > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) > > 2) have notmuch-reply.el (or whatever) add a setup mail hook that > searches for an existing User-Agent header and appends " Emacs/23.1.1 > (gnu/linux)" > > One issue is again, such a hook would be message mode > specific, so gnus users might not appreciate that. Also when composing a > message via c-x m this would not work. So perhaps an all lisp solution? > Again, can we hijack message mode to add our own promotion header? > Or has the time come for a notmuch-message-mode that somehow inherits > from message mode? bremner said something about dynamic bindings that > would allow that. I really think we need to investigate having a notmuch-message-mode as there are now a number of reasons to be able to customize things when the user is running notmuch. BTW: I don't think these are "promotion headers" - I relatively frequently want to check which email client someone else is using when I'm trying to figure out why things go wrong (incorrect mail headers, mangled spacing (in patches, for example), incorrect HTML messages, etc) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RFC: User-Agent header
On Sat, 10 Apr 2010 16:00:49 +0200, "Sebastian Spaeth" wrote: > On 2010-04-10, Carl Worth wrote: > > So I propose something like: > > > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) > > That looks good to me. So I assume the correct strategy here would be > to: > > 1) have notmuch reply insert a header: > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) > > 2) have notmuch-reply.el (or whatever) add a setup mail hook that > searches for an existing User-Agent header and appends " Emacs/23.1.1 > (gnu/linux)" > > One issue is again, such a hook would be message mode > specific, so gnus users might not appreciate that. Also when composing a > message via c-x m this would not work. So perhaps an all lisp solution? > Again, can we hijack message mode to add our own promotion header? > Or has the time come for a notmuch-message-mode that somehow inherits > from message mode? bremner said something about dynamic bindings that > would allow that. I really think we need to investigate having a notmuch-message-mode as there are now a number of reasons to be able to customize things when the user is running notmuch. BTW: I don't think these are "promotion headers" - I relatively frequently want to check which email client someone else is using when I'm trying to figure out why things go wrong (incorrect mail headers, mangled spacing (in patches, for example), incorrect HTML messages, etc) /D -- Dirk Hohndel Intel Open Source Technology Center
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 15:52:04 +0200, "Sebastian Spaeth" wrote: > On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote: > > Are you all trying to show a problem here? All of the above comes > > through fine. Perhaps it's only with non-ASCII in the From line being > > replied to? Let's test that here... > > I think there are 2 issues being discussed here. One is the encoding in > the subject line (which does not look pretty in compose mail, but seems > to be the standard). I did not refer to that. That's the issue I refer to. Yes, it needs to be decoded for the actual mail transport. But it should be displayed correctly not only in the summary view but also in the message buffer when responding to an email. > What I referred to was the json output as the encode_as_json_string (or > however it is called), simply drops chars >127, leading to missing > letters in e.g. the author names etc. I could see that in the web > frontends that are making use of json already, and once (if?) emacs uses > the json output too, this will become an issue there too. Separate issue that almost certainly has a different cause. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 15:52:04 +0200, "Sebastian Spaeth" wrote: > On 2010-04-10, Carl n?tmuch ? Worth wrote: > > Are you all trying to show a problem here? All of the above comes > > through fine. Perhaps it's only with non-ASCII in the From line being > > replied to? Let's test that here... > > I think there are 2 issues being discussed here. One is the encoding in > the subject line (which does not look pretty in compose mail, but seems > to be the standard). I did not refer to that. That's the issue I refer to. Yes, it needs to be decoded for the actual mail transport. But it should be displayed correctly not only in the summary view but also in the message buffer when responding to an email. > What I referred to was the json output as the encode_as_json_string (or > however it is called), simply drops chars >127, leading to missing > letters in e.g. the author names etc. I could see that in the web > frontends that are making use of json already, and once (if?) emacs uses > the json output too, this will become an issue there too. Separate issue that almost certainly has a different cause. /D -- Dirk Hohndel Intel Open Source Technology Center
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 09:05:00 -0400, Jameson Rollins wrote: > On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel > wrote: > > On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel > > wrote: > > > > > > here's what's going wrong. Look at the To: line... > > > > Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth , > > The To: line shows up fine in notmuch-show for me (in emacs). It only > shows up like this when editing. I think this is actually a general > mail issue, and is not a notmuch issue. I don't understand all the > issues, but I think non-ASCII characters in headers have to be encoded, > and that's what you're seeing. Yes, I understand the RFCs and encoding fairly well. That wasn't my point. The point is that for some reason we display the encoded text shown above in the Messages Mode buffer, instead of displaying the non-ASCII characters as we (IMHO) should. Maybe this is an issue of different versions of Emacs behaving slightly differently as Carl seems not to have this issue... I'm on GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.18.6) of 2010-01-14 on x86-02.phx2.fedoraproject.org /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 09:05:00 -0400, Jameson Rollins wrote: > On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel > wrote: > > On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel > > wrote: > > > > > > here's what's going wrong. Look at the To: line... > > > > Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth , > > The To: line shows up fine in notmuch-show for me (in emacs). It only > shows up like this when editing. I think this is actually a general > mail issue, and is not a notmuch issue. I don't understand all the > issues, but I think non-ASCII characters in headers have to be encoded, > and that's what you're seeing. Yes, I understand the RFCs and encoding fairly well. That wasn't my point. The point is that for some reason we display the encoded text shown above in the Messages Mode buffer, instead of displaying the non-ASCII characters as we (IMHO) should. Maybe this is an issue of different versions of Emacs behaving slightly differently as Carl seems not to have this issue... I'm on GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.18.6) of 2010-01-14 on x86-02.phx2.fedoraproject.org /D -- Dirk Hohndel Intel Open Source Technology Center
Re: Plans for the 0.2 release (this week)
On Sat, Apr 10, 2010 at 09:06:54AM -0400, Jameson Rollins wrote: > Again, this subject line shows up fine for me in notmuch-show in emacs. > I believe the non-ASCII characters in headers have to be escaped for > mail handlers to properly handle them, and the reader should translate. > I need to find a reference for this... http://tools.ietf.org/html/rfc2047 The problem is not the MTA, but the fact that the sender and recipient may be using different character sets. There is no way to decode it properly unless the sender specifies the character set. me ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Plans for the 0.2 release (this week)
On Sat, Apr 10, 2010 at 09:06:54AM -0400, Jameson Rollins wrote: > Again, this subject line shows up fine for me in notmuch-show in emacs. > I believe the non-ASCII characters in headers have to be escaped for > mail handlers to properly handle them, and the reader should translate. > I need to find a reference for this... http://tools.ietf.org/html/rfc2047 The problem is not the MTA, but the fact that the sender and recipient may be using different character sets. There is no way to decode it properly unless the sender specifies the character set. me
Re: RFC: User-Agent header
On 2010-04-10, Carl Worth wrote: > So I propose something like: > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) That looks good to me. So I assume the correct strategy here would be to: 1) have notmuch reply insert a header: User-Agent: Notmuch/0.2 (http://notmuchmail.org) 2) have notmuch-reply.el (or whatever) add a setup mail hook that searches for an existing User-Agent header and appends " Emacs/23.1.1 (gnu/linux)" One issue is again, such a hook would be message mode specific, so gnus users might not appreciate that. Also when composing a message via c-x m this would not work. So perhaps an all lisp solution? Again, can we hijack message mode to add our own promotion header? Or has the time come for a notmuch-message-mode that somehow inherits from message mode? bremner said something about dynamic bindings that would allow that. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 15:52:04 +0200, "Sebastian Spaeth" wrote: > frontends that are making use of json already, and once (if?) emacs uses > the json output too, this will become an issue there too. once, not if! jamie. pgpgzv5x4GFqI.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Initial attempt at a "merge window" for notmuch
On 2010-04-09, Carl Worth wrote: > > Here's the current list: Having such a list is great. So now we need to get you a key-binding that says, "take query xy results and stuff them into the wiki" (or some pastebin like service with a fixed URL). Looking forward to 0.2. Sebastian (THanks to the debian pkgs I can now use notmuch on my netbook which has not compiler installed. Very useful, thanks. Now the issue of syncing tags is becoming more pressing for me :-) ) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On 2010-04-10, Carl n∅tmuch 䚳 Worth wrote: > Are you all trying to show a problem here? All of the above comes > through fine. Perhaps it's only with non-ASCII in the From line being > replied to? Let's test that here... I think there are 2 issues being discussed here. One is the encoding in the subject line (which does not look pretty in compose mail, but seems to be the standard). I did not refer to that. What I referred to was the json output as the encode_as_json_string (or however it is called), simply drops chars >127, leading to missing letters in e.g. the author names etc. I could see that in the web frontends that are making use of json already, and once (if?) emacs uses the json output too, this will become an issue there too. Certainly not urgent, but it looked quite weird in the web frontends. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id
On 2010-04-09, Jesse Rosenthal wrote: > sporadic access. However, one question: it looks like it was V2 of the > patch that you pushed -- was it? Unfortunately, there was a subtle bug > that kept on popping up (when you call notmuch-show interactively, which > rarely happens). Later in this same thread, I offered V4 (yep, there was > a problematic V3 too) which fixes this: I think I picked v4 for merging, however removing the comment (supercedes v1-3) from the commit messages. I hope that was ok with you. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC: User-Agent header
On Fri, 09 Apr 2010 19:55:17 -0700, Carl Worth wrote: > So I propose something like: > > User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) The problem I see is that if we go with this proposal, our mail will have inconsistent User-Agent: header, depending on if the message was new or if it's a reply. Maybe that's not too big of an issue, though, since the in the reply case notmuch is generating some of the headers, whereas they're all generated by emacs in the new message case. jamie. pgpGFBomaiodG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 09:06:54 -0400, Jameson Rollins wrote: > Again, this subject line shows up fine for me in notmuch-show in emacs. > I believe the non-ASCII characters in headers have to be escaped for > mail handlers to properly handle them, and the reader should translate. > I need to find a reference for this... I think this is the relevant RFC: http://tools.ietf.org/html/rfc5335 Basically, I think that emacs is doing the right thing here. This isn't a notmuch issue at all. The headers have to be encoded this way for the MTAs. Your reader (ie. emacs) should be doing the translation for you. jamie. pgpiCWVE7GiB8.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010 11:02:19 +0200, Michal Sojka wrote: > On Sat, 10 Apr 2010, Carl n∅tmuch 䚳 Worth wrote: > > Are you all trying to show a problem here? All of the above comes > > through fine. Perhaps it's only with non-ASCII in the From line being > > replied to? > > Yes and also in Subject line. You can test this with > id:87r5o1etjb@steelpick.localdomain. Again, this subject line shows up fine for me in notmuch-show in emacs. I believe the non-ASCII characters in headers have to be escaped for mail handlers to properly handle them, and the reader should translate. I need to find a reference for this... jamie. pgpUdqBblXbQ1.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Fri, 09 Apr 2010 21:47:20 -0700, Dirk Hohndel wrote: > On Fri, 09 Apr 2010 21:44:02 -0700, Dirk Hohndel > wrote: > > > > here's what's going wrong. Look at the To: line... > > Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth , The To: line shows up fine in notmuch-show for me (in emacs). It only shows up like this when editing. I think this is actually a general mail issue, and is not a notmuch issue. I don't understand all the issues, but I think non-ASCII characters in headers have to be encoded, and that's what you're seeing. jamie. pgpUUFtN4YIj7.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Have notmuch count default to showing the total.
On Fri, Apr 9, 2010 at 23:01, Sebastian Spaeth wrote: > On 2010-04-08, Mike Kelly wrote: >> If no parameters are given to notmuch-count, or just '' or '*' are >> given, return the total number of messages in the database. > I know that cworth was concerned about this syntax on IRC as that would > mean that "notmuch show" would have to spew out all your emails in order > to remain consistent with the search term (he rather wanted to output a > help text if no search term was given). What's wrong with having them inconsistent in this one respect? [0] $ notmuch count 96632 $ notmuch search Error: notmuch search requires at least one search term. ...seems pretty logical behaviour to me? Cheers, aj [0] Not much, afaics! [1] [1] Man, what are the chances that will ever get old? [0] -- Anthony Towns
Initial attempt at a "merge window" for notmuch
On Sat, Apr 10, 2010 at 02:23, Carl Worth wrote: > 3. Ability to easily post search results to a web page. Isn't that a job for "noneatall" [0] -- maybe it just needs the ability to export to static pages, that can be rsync'ed somewhere? [0] http://github.com/dme/noneatall > 4. Fancy support for thread- vs. message-based search matches. > We've talked about supporting a "muted" tag to make obnoxious > threads disappear entirely. The idea we have there is a tag on a > message, and then support for searches which compute set-theoretic > operations based on sets of threads. Is that an argument for tags on a thread rather than a message? With a message mute tag, if you happen to delete the single message you've tagged muted (maybe you killfile the sender of that message), suddenly the whole thread reappears, which doesn't sound entirely desirable. > ?2. The ability to split a thread. > ? ? I know I argued against this previously, but I know that "Plans for > ? ? the 0.2 release" contains multiple independent topics, and I'd > ? ? really like to be able to track those separately. An MUA that did that well (or just effectively) would be massively fantastic. Perhaps you could do it by associating threads with any message, so if you've got an announcement A, with three followups, B, C and D, of which C and D are interesting and novel subthreads, you could have thread:1 start at A and include everything, thread:2 manually pointed at C and include both its parents (A) and any children, but not any siblings/cousins (B/D), and thread:3 manually pointed at D and behave likewise (including A, any responses to D, but not B, C or any replies to B or C). I don't know how you'd handle a mail, E, that came in that following up to C though -- do you just report thread:1 as having new mail, or just thread:2, or both of them? What if F comes in that simultaneously replies to E and D? (Personally, I could probably be comfortable with any of those behaviours) > ? ? For my merge window, I also want something that can't be obtained > ? ? today. I want to see all threads that contain at least one message > ? ? that matches my date range and at least one message that doesn't > ? ? have the "merged" or "postponed" tag. That is, I can merge a > ? ? feature and mark it "merged", but if someone replies later noticing > ? ? a defect in the patch I merged, then I want that thread to reappear > ? ? in my search results. But my current date restriction prevents > ? ? that. The above hypothetical features could let you do: # create new threads at messages that are marked as postponed or merged notmuch newthread -- not is:threadroot \( tag:merged or tag:postponed \) # assume threads get the same tags as their "root" message, so that # any messages in the above new threads will automagically match on # threadtag:merged or threadtag:postponed. Thus: notmuch search threadtag:merged 123456..123789 That's abusing subthreads as a poor man's set. Not really convinced that's a good idea, but what the hey... Something to think about maybe. Cheers, aj -- Anthony Towns
[RFC] reordering and cleanup of thread authors
On Fri, 09 Apr 2010, Dirk Hohndel wrote:
> On Fri, 09 Apr 2010 08:07:27 +0200, Michal Sojka
> wrote:
> > On Wed, 07 Apr 2010, Dirk Hohndel wrote:
> > >
> > > This is based in part on some discussion on IRC today.
> > > When a thread is displayed in the search results, previously the authors
> > > were always displayed in chronological order. But if only part of the
> > > thread matches the query, that may or may not be the intuitive thing to
> > > do.
> >
> > thanks for the patch. It is a very interesting feature.
>
> Thanks - I've been using it for a few days now and am fairly happy with
> it.
>
> > >
> > > +/*
> > > + * move authors of matched messages in the thread to
> > > + * the front of the authors list, but keep them in
> > > + * oldest first order within their group
> > > + */
> > > +static void
> > > +_thread_move_matched_author (notmuch_thread_t *thread,
> > > + const char *author)
> > > +{
> > > +char *authorscopy;
> > > +char *currentauthor;
> > > +int idx,nmstart,author_len,authors_len;
> > > +
> > > +if (thread->authors == NULL)
> > > + return;
> > > +if (thread->nonmatched_authors == NULL)
> > > + thread->nonmatched_authors = thread->authors;
> > > +author_len = strlen(author);
> > > +authors_len = strlen(thread->authors);
> > > +if (author_len == authors_len) {
> > > + /* just one author */
> > > + thread->nonmatched_authors += author_len;
> > > + return;
> > > +}
> > > +currentauthor = strcasestr(thread->authors, author);
> > > +if (currentauthor == NULL)
> > > + return;
> > > +idx = currentauthor - thread->nonmatched_authors;
> > > +if (idx < 0) {
> > > + /* already among matched authors */
> > > + return;
> > > +}
> > > +if (thread->nonmatched_authors + author_len < thread->authors +
> > > authors_len) {
> >
> > What does the above condition exactly mean?
>
> Eh - it's ugly.
>
> thread->authors + authors_len points to the trailing '\0' of the list of
> all my authors. At this point in the code we know that the current
> position of this author is at or after nonmatched_authors. So if
> nonmatched_authors + author_len is less than the end of the all authors
> that means that there was another author in the list behind this one -
> and we need to move things around.
>
> In the else clause we just move the pointer to nonmatched_authors to the
> end of this author.
>
> So yeah, ugly, should be rewritten to make it easier to understand (or
> at least commented better).
>
> > I was not able to decode it
> > and it seems to be wrong. I expect that the "|" is used to delimit
> > matched and non-matched authors. If I run notmuch search
> > thread:, which matches all messages in the thread, I see
> > all authors delimited by "|", which I consider wrong.
>
> Why do you think it's wrong?
Because I thought, that | was used as a delimiter between the two parts
of the list and not as a marker of matched authors.
> It's consistent. The thing that I actually DISlike about the current
> solution is that the last author has no delimiter (since there's no
> trailing ',' in the list and I didn't want to realloc the space for
> the authors string). So you can't tell with one glance if all authors
> match or all but the last one match. I haven't come up with a better
> visual way to indicate this...
I think that using | as a separator would help here. Let's say that
initially we have "Matched Author, Non Matched, Matched Again" we can
tranform this to "Matched Author, Matched Again| Non Matched". This way,
the length of the string remains the same. If there is no | after
transformation, we know that all authors matched because there is always
at least one mathed author in the search results.
-Michal
Re: Plans for the 0.2 release (this week)
On Sat, 10 Apr 2010, Carl n∅tmuch 䚳 Worth wrote: > > On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth" > > wrote: > > > On 2010-04-09, Michal Sojka wrote: > > > Perhaps Carl should get more Nørwég¡añ friends, :-). > > > > Or Görmän or 中文 > > Are you all trying to show a problem here? All of the above comes > through fine. Perhaps it's only with non-ASCII in the From line being > replied to? Yes and also in Subject line. You can test this with id:87r5o1etjb@steelpick.localdomain. Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] git: Ignore packaging intermediate files
commit c9ff373f8bdcc6b55c6df8e0d4582d459ef87c31 Author: David Edmondson Date: Sat Apr 10 09:02:32 2010 +0100 git: Ignore packaging intermediate files Modified .gitignore diff --git a/.gitignore b/.gitignore index 217440d..c685340 100644 --- a/.gitignore +++ b/.gitignore @@ -13,3 +13,27 @@ libnotmuch.so* .*.swp *.elc releases +/debian/files +/debian/libnotmuch-dev.debhelper.log +/debian/libnotmuch-dev.substvars +/debian/libnotmuch-dev/DEBIAN/control +/debian/libnotmuch-dev/DEBIAN/md5sums +/debian/libnotmuch-dev/usr/include/notmuch.h +/debian/libnotmuch-dev/usr/share/doc/libnotmuch-dev/changelog.Debian.gz +/debian/libnotmuch-dev/usr/share/doc/libnotmuch-dev/copyright +/debian/libnotmuch1.debhelper.log +/debian/libnotmuch1.postinst.debhelper +/debian/libnotmuch1.postrm.debhelper +/debian/libnotmuch1.substvars +/debian/libnotmuch1/DEBIAN/control +/debian/libnotmuch1/DEBIAN/md5sums +/debian/libnotmuch1/DEBIAN/postinst +/debian/libnotmuch1/DEBIAN/postrm +/debian/libnotmuch1/DEBIAN/shlibs +/debian/libnotmuch1/usr/share/doc/libnotmuch1/changelog.Debian.gz +/debian/libnotmuch1/usr/share/doc/libnotmuch1/copyright +/debian/notmuch.debhelper.log +/debian/notmuch.postinst.debhelper +/debian/notmuch.prerm.debhelper +/debian/notmuch.substvars +/debian/tmp/usr/include/notmuch.h dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
