Plans for the 0.2 release (this week)
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 , that's not pretty... nor readable. /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
here's what's going wrong. Look at the To: line... /D On Fri, 09 Apr 2010 20:06:09 -0700, 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? Let's test that here... > > -Carl > > PS. How about this for something interesting from Unicode: > > ? Definition in English: do not know, to know nothing about, quickly; > fast, sharp; keen Non-text part: application/pgp-signature -- Dirk Hohndel Intel Open Source Technology Center
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) +1 /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
> 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? Let's test that here... -Carl PS. How about this for something interesting from Unicode: ? Definition in English: do not know, to know nothing about, quickly; fast, sharp; keen -- 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/20100409/f9fa2828/attachment.pgp>
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: > > > No patch yet, just asking if this is a good idea or not. Yes. A fine idea. > I think it's a very good idea. But it should be something that includes > the other components of how you send email... > > Like > > User-Aget: Emacs 23 Message-mode / notmuch-0.1.1 A quick grep through some of my recent mails does show precedent for this kind of thing: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.90 (gnu/linux) Unsurprisingly, these suer-agent strings can become arbitrarily unwieldy: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0pre Thunderbird/3.0.4 Or extremely simple: User-Agent: Sup/0.11 I don't see the advantage of duplicating the name and version in the parenthesized comment, but here's an idea that looks useful: User-Agent: Loom/3.14 (http://gmane.org/) So I propose something like: User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) If anybody wants to start assembling a patch to generate that, that would be great. -Carl -- 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/20100409/8afe7571/attachment.pgp>
[RFC] reordering and cleanup of thread authors
On Sat, 10 Apr 2010 03:53:59 +0200, Michal Sojka wrote: > 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. That's a great idea. I'll update the patch to do that. /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH] Derive version numbers from git
On Thu, 08 Apr 2010 13:49:22 +0200, Michal Sojka wrote: > On Wed, 07 Apr 2010, Carl Worth wrote: > I have modified the patch slightly and I think that it could solve the > above points. The release process should be modified this way: you skip > point 5 (increment the notmuch version in Makefile.local) and in point > 6, you run 'make release VERSION=X.Y'. Looks great. I've pushed that now and updated the instructions in RELEASING. It occurs to me that I'm already updating the version in the NEWS file, so the next step would be to just make "make release" get it from there. But in the meantime, having these nice git-describe-generated version numbers will be quite handy (86 commits since 0.1 already, wow!). So, thanks! -Carl -- 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/20100409/c7d97b79/attachment-0001.pgp>
[PATCH] Have notmuch count default to showing the total.
On Thu, 8 Apr 2010 15:39:38 -0400, 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. How much syntax should count require to print all messages? [*] I've pushed this out now, along with some followups to provide support for all commands to accept "*" as a special case that matches all messages. Thanks, -Carl [*] id:h2x87b3a4191004091228nae33f127le9754973709de659 at mail.gmail.com [0] -- 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/20100409/8a4006c2/attachment.pgp>
[PATCH] Have notmuch count default to showing the total.
On Fri, 09 Apr 2010 10:19:47 -0700, Dirk Hohndel wrote: > On Fri, 09 Apr 2010 15:01:35 +0200, "Sebastian Spaeth" SSpaeth.de> wrote: > > 1) I often want to know how many mails are in my db. "notmuch count" or > > "notmuch count *" is the intuitive syntax I would use for that. Right > > now there is no way as far as I can see. > > I use "notmuch count To" - not very intuitive, though. Unfortunately, this doesn't give the desired result. Think Shakespearean and you can get an accurate count though: notmuch count to be or not to be -Carl OK, we need a simpler search syntax than that... -- 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/20100409/34915629/attachment.pgp>
[notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id
On Fri, 09 Apr 2010 10:01:09 -0400, Jesse Rosenthal wrote: > Great to hear! Sorry I've been off of email, and still only have > 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 do remember seeing several versions of this patch. And I *think* that I did reply v4. > id:876359cz16.fsf at jhu.edu Looking at this patch carefully, I don't see any difference compared to what I applied in commit 9bee20aed34a9ed035b1a0dc89de89af1c65fd1b It seems to work for me on current master when called interactively. But do let me know if there are any additional changes I should apply here. -Carl -- 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/20100409/45d20b5e/attachment.pgp>
[PATCH] Have notmuch count default to showing the total.
On Sat, Apr 10, 2010 at 05:28:32AM +1000, Anthony Towns wrote: > What's wrong with having them inconsistent in this one respect? > > $ notmuch count > 96632 > $ notmuch search > Error: notmuch search requires at least one search term. > > ...seems pretty logical behaviour to me? My thoughts exactly :) -- Mike Kelly
[PATCH] Have notmuch count default to showing the total.
On Sat, 10 Apr 2010 05:28:32 +1000, Anthony Towns wrote: > 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. This seems very logical and intuitive behavior in my opinion. I would *not* expect them to show help messages in these cases. "notmuch help foo" is much more intuitive. 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/20100409/7fdc2777/attachment-0001.pgp>
[PATCH] Next attempt to get guessing of From addresses correct in replies
We now go through the following searches in order:
0) one of the users addresses was in a To: or Cc: header
1) check for an Envelope-to: header that matches one of the addresses
2) check for an X-Original-To: header that matches one of the addresses
3) check for a (for ) clause in Received: headers
4) check for the domain part of known email addresses in the
'by' part of Received headers
Finally, if none of these work, we give up and use the primary email address.
Signed-off-by: Dirk Hohndel
---
lib/message-file.c | 35 ++-
notmuch-reply.c| 128 +++
2 files changed, 122 insertions(+), 41 deletions(-)
diff --git a/lib/message-file.c b/lib/message-file.c
index 0c152a3..0114761 100644
--- a/lib/message-file.c
+++ b/lib/message-file.c
@@ -209,15 +209,21 @@ copy_header_unfolding (header_value_closure_t *value,
/* As a special-case, a value of NULL for header_desired will force
* the entire header to be parsed if it is not parsed already. This is
- * used by the _notmuch_message_file_get_headers_end function. */
+ * used by the _notmuch_message_file_get_headers_end function.
+ *
+ * WARNING - if the caller is asking for a header that could occur
+ * multiple times than they MUST first call this function with a
+ * a value of NULL for header_desired to ensure that all of the
+ * headers are parsed and concatenated before a match is returned
+ */
const char *
notmuch_message_file_get_header (notmuch_message_file_t *message,
const char *header_desired)
{
int contains;
-char *header, *decoded_value;
+char *header, *decoded_value, *header_sofar, *combined_header;
const char *s, *colon;
-int match;
+int match,newhdr,hdrsofar;
static int initialized = 0;
if (! initialized) {
@@ -312,20 +318,27 @@ notmuch_message_file_get_header (notmuch_message_file_t
*message,
NEXT_HEADER_LINE (>value);
- if (header_desired == 0)
+ if (header_desired == NULL)
match = 0;
else
match = (strcasecmp (header, header_desired) == 0);
decoded_value = g_mime_utils_header_decode_text (message->value.str);
- if (g_hash_table_lookup (message->headers, header) == NULL) {
- /* Only insert if we don't have a value for this header, yet.
-* This way we always return the FIRST instance of any header
-* we search for
-* FIXME: we should be returning ALL instances of a header
-*or at least provide a way to iterate over them
-*/
+ header_sofar = (char *)g_hash_table_lookup (message->headers, header);
+ if (header_sofar == NULL) {
+ /* Only insert if we don't have a value for this header, yet. */
g_hash_table_insert (message->headers, header, decoded_value);
+ } else {
+ /* not sure this makes sense for all headers that can occur
+* multiple times, but for now just concatenate headers
+*/
+ newhdr = strlen(decoded_value);
+ hdrsofar = strlen(header_sofar);
+ combined_header = xmalloc(hdrsofar + newhdr + 2);
+ strncpy(combined_header,header_sofar,hdrsofar);
+ *(combined_header+hdrsofar) = ' ';
+ strncpy(combined_header+hdrsofar+1,decoded_value,newhdr+1);
+ g_hash_table_insert (message->headers, header, combined_header);
}
if (match)
return decoded_value;
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 39377e1..91a2094 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -285,33 +285,100 @@ add_recipients_from_message (GMimeMessage *reply,
static const char *
guess_from_received_header (notmuch_config_t *config, notmuch_message_t
*message)
{
-const char *received,*primary;
-char **other;
-char *by,*mta,*ptr,*token;
+const char *received,*primary,*by;
+char **other,*tohdr;
+char *mta,*ptr,*token;
char *domain=NULL;
char *tld=NULL;
const char *delim=". \t";
size_t i,other_len;
+const char *to_headers[] = {"Envelope-to", "X-Original-To"};
+
+primary = notmuch_config_get_user_primary_email (config);
+other = notmuch_config_get_user_other_email (config, _len);
+
+/* sadly, there is no standard way to find out to which email
+ * address a mail was delivered - what is in the headers depends
+ * on the MTAs used along the way. So we are trying a number of
+ * heuristics which hopefully will answer this question.
+
+ * We only got here if none of the users email addresses are in
+ * the To: or Cc: header. From here we try the following in order:
+ * 1) check for an Envelope-to: header
+ * 2) check for an X-Original-To: header
+ * 3) check for a (for ) clause in Received: headers
+ * 4) check for the domain part of known email addresses in the
+ *'by' part of Received headers
+ * If
[PATCH] Have notmuch count default to showing the total.
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). But let me express support (It's notmuch worth, I know (haha)) for this patch. I think it makes lots of sense: 1) I often want to know how many mails are in my db. "notmuch count" or "notmuch count *" is the intuitive syntax I would use for that. Right now there is no way as far as I can see. 2) Search terms filter out things. The empty search term stands therefore for all my mails. It is consistent to have the search term '' represent all my mail. 3) I don't expect a help text for "notmuch count" just as I don't expect a help text for "notmuch log", we are very explicit about "notmuch help" and "notmuch help count" in many parts of our documentation. I'm using this and find it very handy. Sebastian
Initial attempt at a "merge window" for notmuch
On Fri, 9 Apr 2010 11:29:20 -0500, Carl Worth wrote:
> On Fri, 09 Apr 2010 09:23:27 -0700, Carl Worth wrote:
> > 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.
> ...
> > I'm not sure how to best provide the ability to express the result
> > I want here.
>
> 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) )
Isn't that close to what you're asking for?
It seems easy enough, and making the set:( explicit keeps you from
inventing a new quoting syntax if you tried to say
set:"tag:notmuch and "
then users get to play shell-quote-mambo to actually use this outside of
a client if they want (or think they want) quotes used in their search.
You can reuse the "and" and "or" term for set math, unless you are
averse to overloading, then isect, union are explicit enough about the
terms that you could infer the "set:" term for searches:
tag:notmuch and isect not ( tag:postponed or tag:merged )
But at the cost of introducing a new order of ops hierarchy. I'm not
sure if you want to go there either.
Just thinking about completeness, I wonder if there are some searches
for threads that aren't currently available.
You could introduce a search modifier that would allow you to treat a
tag on a message in a thread as a tag on the entire thread, so that if
you have tag:mute on on message and tag:merged on another message in the
same thread, currently that does match:
tag:merged and not tag:mute
But maybe you wanted only the THREADS instead of THREAD CONTAINS
searching.
I guess we're hampered by the fact that a thread object isn't a separate
object from the messages which comprise it's conversation, so we can't
look at the tags on a thread separately from the tags on messages in the
thread. And maybe we don't want to.
Actually, this is where we differ slightly from gmail. They have tags
on threads, and unread tags on messages.
I don't know that there's value in distinguishing between tags on a
thread and tags on a message in a thread when there isn't an object in
the mailstore that actually corresponds to a thread.
Hmmm, this isn't clear enough, so I'll just stop the rambling, but let
it stand.
-Mark
P.S. Sometimes I write a long note and don't get to the last sentence
for an hour or two. I can be funny that way.
[PATCH] Have notmuch count default to showing the total.
On Fri, 9 Apr 2010 14:28:32 -0500, Anthony Towns wrote: > [0] Not much, afaics! [1] > [1] Man, what are the chances that will ever get old? [0] Thanks AJ, I like it! -Mark
Plans for the 0.2 release (this week)
On Fri, Apr 9, 2010 at 00:03, Jameson Rollins wrote: > Presumably others must be annoyed about having to manually "read" and > archive all their sent mail, unless there's some other way that people > having been dealing with this that I'm not aware of. I haven't switched over to notmuch properly yet, but in my initial import of my mail I made a couple of patches to notmuch new that let me get the tags right first. One was to make: notmuch new --initial-tags=list,unread set the initial tags for newly found messages to "list" and "unread" instead of the default "inbox" and "unread". The other was to make: find Mail/.Saved/ -type f | notmuch new --initial-tags=archived --file-list only process the mail files listed on stdin (via find), and give them the explicit tags I specify. That way I could import all my existing archived mail without it appearing in my inbox or as unread. Unfortunately the second one ended up complicated and a bit slow (I think because I'm doing a talloc() for every line on stdin, and talloc_free() by context every time the base directory changes; that sort of behaviour was necessary in order to do duplicate checking in a sane way) But anyway, that would let you do: find Mail/.Drafts/ -type f | notmuch new --initial-tags=draft --file-list notmuch new to get drafts correctly tagged. (I don't have the patches handy at the moment; but can certainly dig them up if there's interest) Cheers, aj -- Anthony Towns
[PATCH] Add 'G' keybinding to folder and search view that triggers external poll
The new functions first check if an external poll script has been defined in the variable 'notmuch-external-refresh-script and if yes, runs that script before executing the existing refresh function (which is bound to '=') This can be used to have 'G' mimic the mutt behavior of polling an external mail server - or if the mail polling is already automatic, it can trigger the call to notmuch new and any necessary automatic tagging of new email. Signed-off-by: Dirk Hohndel --- emacs/notmuch.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..a56b949 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -260,6 +260,7 @@ For a mouse binding, return nil." (define-key map "s" 'notmuch-search) (define-key map "o" 'notmuch-search-toggle-order) (define-key map "=" 'notmuch-search-refresh-view) +(define-key map "G" 'notmuch-poll-and-search-refresh-view) (define-key map "t" 'notmuch-search-filter-by-tag) (define-key map "f" 'notmuch-search-filter) (define-key map [mouse-1] 'notmuch-search-show-thread) @@ -747,6 +748,17 @@ same relative position within the new buffer." (goto-char (point-min)) )) +(defun notmuch-poll-and-search-refresh-view () + "Run external script to import mail and refresh the current view. + +Checks if the variable 'notmuch-external-refresh-script is defined +and runs the external program defined it provides. Then calls +notmuch-search-refresh-view to refresh the current view." + (interactive) + (if (boundp 'notmuch-external-refresh-script) + (call-process notmuch-external-refresh-script nil nil)) + (notmuch-search-refresh-view)) + (defun notmuch-search-toggle-order () "Toggle the current search order. @@ -801,6 +813,7 @@ current search results AND that are tagged with the given tag." (define-key map ">" 'notmuch-folder-last) (define-key map "<" 'notmuch-folder-first) (define-key map "=" 'notmuch-folder) +(define-key map "G" 'notmuch-poll-and-folder) (define-key map "s" 'notmuch-search) (define-key map [mouse-1] 'notmuch-folder-show-search) (define-key map (kbd "RET") 'notmuch-folder-show-search) @@ -919,6 +932,17 @@ Currently available key bindings: (if search (notmuch-search (cdr search) notmuch-search-oldest-first +(defun notmuch-poll-and-folder () + "Run external script to import mail and refresh the folder view. + +Checks if the variable 'notmuch-external-refresh-script is defined +and runs the external program defined it provides. Then calls +notmuch-folder to refresh the current view." + (interactive) + (if (boundp 'notmuch-external-refresh-script) + (call-process notmuch-external-refresh-script nil nil)) + (notmuch-folder)) + ;;;###autoload (defun notmuch-folder () "Show the notmuch folder view and update the displayed counts." -- 1.6.6.1 -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On 2010-04-08, micah anderson wrote: > On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth wrote: > > For the upcoming 0.2 release, here are some things that I would like to > > have in place: > > > > * Changes to indexing, (addition of body:, folder:, list:, etc.). This > > is stuff that I'll work on. > > Also, fwiw, the folder: indexing is probably the new feature that I'm > most eagerly awaiting. I've got all these ideas for ways to handle sent > mail and drafts if we can get this working. +1 on folder: capability! micah -- 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/20100409/87775488/attachment.pgp>
[RFC] reordering and cleanup of thread authors
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? 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...
Suggestions?
/D
--
Dirk Hohndel
Intel Open Source Technology Center
[PATCH] Have notmuch count default to showing the total.
On Fri, 09 Apr 2010 15:01:35 +0200, "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). > > But let me express support (It's notmuch worth, I know (haha)) for this > patch. I think it makes lots of sense: > > 1) I often want to know how many mails are in my db. "notmuch count" or > "notmuch count *" is the intuitive syntax I would use for that. Right > now there is no way as far as I can see. I use "notmuch count To" - not very intuitive, though. > 2) Search terms filter out things. The empty search term stands > therefore for all my mails. It is consistent to have the search term '' > represent all my mail. Actually, I'd like to disagree. A search argument of '' should get you a help text. A search argument of '*' should give you all email. > 3) I don't expect a help text for "notmuch count" just as I don't expect > a help text for "notmuch log", we are very explicit about "notmuch help" > and "notmuch help count" in many parts of our documentation. My main concern here is that once you have a gazzillion emails, typing notmuch search with no argument over a slow link (or using it from within a gui by mistake) could really cause a lot of unnecessary compute / data transfer. So I'd rather have a special character be the one that triggers that behavior. /D -- Dirk Hohndel Intel Open Source Technology Center
Plans for the 0.2 release (this week)
On Fri, 09 Apr 2010 09:35:07 +0200, "Sebastian Spaeth" wrote: > On 2010-04-09, Michal Sojka wrote: > > "Decode headers in reply" > > (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another > > patch, which is quite essential to me. Am I the only one here, who needs > > to reply to messages with non-ASCII characters? > > Nope, and it looks currently very ugly. Having a good solution for that > problem would be nice indeed. > > Perhaps Carl should get more N?rw?g?a? friends, :-). Or G?rm?n or ?? Yes, I ran into that myself as my brother's first name is J?rgen and he complained about my emails to him suddenly being mangled... But then, Sebastian doesn't even spell his own last name correctly :-) /D -- Dirk Hohndel Intel Open Source Technology Center
[notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
On Wed, 07 Apr 2010 14:10:38 -0700, Carl Worth wrote: > On Tue, 16 Feb 2010 19:07:40 -0500, Jesse Rosenthal > wrote: > I think this feature is very useful, and that the region is definitely > an appropriate way to implement it, (doing region-based operations is > very natural for emacs users). Mutt-style marking could be implemented > as well, but that would be separate I think. Great -- never sure if my intuitive use corresponds with that of others. > I also don't like the duplication of code in > notmuch-search-add-tag-thread and notmuch-search-add-tag-region, (and > the same in the remove case). Fortunately, I think this easy to avoid by > simply making notmuch-search-add-tag-thread call: > >(notmuch-search-add-tag-region tag (point) (point)) > > and the same in the remove case. Good idea. > > But I haven't pushed this patch yet for a flaw in the case of selecting > beyond the last thread, (such as selecting to the line that includes the > "End of search results). If I try an operation on that line, it will act > like it works, (it displays the new tags by all threads), but then a > refresh makes them all disappear again. Presumably the "notmuch tag" > command is failing, this isn't being noticed, and the code marches on to > update the representation of the tags. Good point, and shouldn't be too hard to fix. It seems like it could be done either (a) at the lisp level (filtering out the blank entries), or (b) at the literal buffer level (having a step that sets point-max for the region appropriately). The choice (a) seems clearer in an abstract way, but has the downside of needing to be repeated twice (both for database tagging, and for rewriting the tags on the screen). I'll play with both and see which is clearer. Best, Jesse
[notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id
On Wed, 07 Apr 2010 10:46:01 -0700, Carl Worth wrote: > A very lovely change, Jesse! Thanks for this (which is now pushed). And > again, thanks to Sebastian for guiding the patch through the file > renaming. Great to hear! Sorry I've been off of email, and still only have 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: id:876359cz16.fsf at jhu.edu Sorry for posting numerous versions. Quite embarassing. The only difference, as you'll see, is how it deals with the case when buffer-name is not given to notmuch-show as an argument. Thanks for all the pushes, and apologies for the trouble. Best, Jesse
[notmuch] [Sebastian Spaeth] Pull requests
On Fri, 09 Apr 2010, Sebastian Spaeth wrote:
> On 2010-04-08, Michal Sojka wrote:
> > I think that the patch you sent was not the latest version. The latest
> > is in id:1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz, but it
> > is not rebased to the current master.
>
> Not sure what I am doing wrong, but with this patch even after a
> dump/delete/new/restore. I get
>
> ./notmuch count to:
> 11788
> ./notmuch count folder:
> 247
> ./notmuch count folder:inbox
> 0
Hi Sebastian,
I do not have time to help you with this right now, but you can try the
following patch to debug what's happening. It should apply on top of
your issue28-search-folder-name branch.
-Michal
diff --git a/notmuch-new.c b/notmuch-new.c
index e787407..ebeb287 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -416,6 +416,7 @@ add_files_recursive (notmuch_database_t *notmuch,
case NOTMUCH_STATUS_SUCCESS:
state->added_messages++;
tag_inbox_and_unread (message);
+ printf("DBG: Added new message: folder=%s message=%s\n", folder,
next);
break;
/* Non-fatal issues (go on to next file) */
case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID:
Plans for the 0.2 release (this week)
On 2010-04-09, Michal Sojka wrote: > "Decode headers in reply" > (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another > patch, which is quite essential to me. Am I the only one here, who needs > to reply to messages with non-ASCII characters? Nope, and it looks currently very ugly. Having a good solution for that problem would be nice indeed. Perhaps Carl should get more N?rw?g?a? friends, :-). spaetz
[notmuch] [Sebastian Spaeth] Pull requests
On 2010-04-08, Michal Sojka wrote: > I think that the patch you sent was not the latest version. The latest > is in id:1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz, but it > is not rebased to the current master. Not sure what I am doing wrong, but with this patch even after a dump/delete/new/restore. I get ./notmuch count to: 11788 ./notmuch count folder: 247 ./notmuch count folder:inbox 0 My folders have no weird naming, they are e.g.: /home/spaetz/mail/INBOX/cur/1258732076_0.22934.spaetz-macbook,U=468,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S Sebastian
Initial attempt at a "merge window" for notmuch
On Fri, 09 Apr 2010 09:23:27 -0700, Carl Worth wrote:
> 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.
...
> I'm not sure how to best provide the ability to express the result
> I want here.
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.
-Carl
-- 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/20100409/614ad6ad/attachment.pgp>
Initial attempt at a "merge window" for notmuch
I want to figure out how to make a release process that will work for notmuch. An idea I have now is to use a date-based "merge window" during which features are nominated for the release. So I took a window starting at my original request for 0.2 features until now. In our current (lame) syntax for specifying date ranges, that gives me a search string of: tag:notmuch and 1270678364..1270828505 and not (tag:merged or tag:postponed) What I want to do now is to work through this list and tag things as either "merged" or "postponed" until my list is empty. That should give a good indication that we've actually got all the features we want. (We'll still need something more for tracking bugs, of course.) Here's the current list: [22/22] Carl Worth, James... Plans for the 0.2 release (this week) [2/6] Carl Worth, Micha... Notmuch release 0.1 now available [2/4] Dirk Hohndel, Car... [PATCH] Fix code extracting the MTA from Received: headers [1/2] Mike Kelly, Carl ... [PATCH] Fix the default value for --includedir. [2/5] David Edmondson, ... [notmuch] [PATCH] notmuch.el: 'F' in search mode takes us to a list of folders. [2/2] Sebastian Spaeth,... RFC: User-Agent header [1/30] Aneesh Kumar K.V,... [notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages [3/10] Sebastian Spaeth,... [notmuch] [Sebastian Spaeth] Pull requests [5/5] Michal Sojka [PATCH 0/4] Mailstore abstraction v4 [2/2] Michal Sojka [PATCH] Mailstore abstraction v4 - part 2 (maildir synchronization) [2/2] Mike Kelly, Sebas... [PATCH] Have notmuch count default to showing the total. [3/3] Mike Kelly [PATCH 1/3] Initial support for maildir flags. [1/2] Dirk Hohndel, Mic... [RFC] reordering and cleanup of thread authors [1/10] Jesse Rosenthal, ... [notmuch] [PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id [1/11] Jesse Rosenthal, ... [notmuch] [PATCH] notmuch.el: add functionality to add or remove tags by region. Of course, just looking at this list makes me want many more features (but they are too late for this merge window): 1. Real support for date-range-based searches 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. 3. Ability to easily post search results to a web page. I'd like people to be able to easily view a web page with three lists on it for tracking the upcoming release: "proposed features", "merged features", and "postponed features". 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. So I want the set of threads which have a message of "tag:inbox" and subtract from that the set of threads which have a message of "tag:muted". Note that this result is different than what we can currently compute which is a set of threads containing messages that match "tag:inbox and not tag:muted". This will return threads that I have muted when new messages arrive to the thread after I added the muted tag to the older messages. So we do need some new support here. 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. I'm not sure how to best provide the ability to express the result I want here. But clearly, we want to come up with a syntax that's powerful enough to capture these kinds of things. (And I think this will go beyond the search capabilities of most email systems that I'm aware of.) -Carl -- 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/20100409/a636756d/attachment.pgp>
[RFC] reordering and cleanup of thread authors
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.
Hi Dirk,
thanks for the patch. It is a very interesting feature. See my comments
below.
>
> [...]
>
> +/*
> + * 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? 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.
-Michal
> + /* we have to make changes, so let's get a temp copy */
> + authorscopy = strdup(thread->authors);
> + if (authorscopy == NULL)
> + return;
> + /* nmstart is the offset into where the non-matched authors start */
> + nmstart = thread->nonmatched_authors - thread->authors;
> + /* copy this author and add the "| " - the if clause above tells us
> there's more */
> + strncpy(thread->nonmatched_authors,author,author_len);
> + strncpy(thread->nonmatched_authors+author_len,"| ",2);
> + thread->nonmatched_authors += author_len+2;
> + if (idx > 0) {
> + /* we are actually moving authors around, not just changing the
> separator
> +* first copy the authors that came BEFORE our author */
> + strncpy(thread->nonmatched_authors, authorscopy+nmstart, idx-2);
> + /* finally, if there are authors AFTER our author, copy those */
> + if(author_len+nmstart+idx < authors_len) {
> + strncpy(thread->nonmatched_authors + idx - 2,", ",2);
> + strncpy(thread->nonmatched_authors + idx, authorscopy+nmstart + idx
> + author_len + 2,
> + authors_len - (nmstart + idx + author_len + 2));
> + }
> + }
> + free(authorscopy);
> +} else {
> + thread->nonmatched_authors += author_len;
> +}
> +return;
> +}
Plans for the 0.2 release (this week)
On Wed, 07 Apr 2010, Carl Worth wrote: > * Anything else that people want, (especially things that already > exist and that you're already using). Support for maildir flags on > import would be great here. I'm still waiting to see a complete > solution I think. > > So keep the patches coming, and the pointers to patches that you want me > to look at. "Decode headers in reply" (id:1267602656-24940-1-git-send-email-sojkam1 at fel.cvut.cz) is another patch, which is quite essential to me. Am I the only one here, who needs to reply to messages with non-ASCII characters? -Michal
Plans for the 0.2 release (this week)
On Fri, 09 Apr 2010, Anthony Towns wrote: > On Fri, Apr 9, 2010 at 00:03, Jameson Rollins > wrote: > > Presumably others must be annoyed about having to manually "read" and > > archive all their sent mail, unless there's some other way that people > > having been dealing with this that I'm not aware of. > > I haven't switched over to notmuch properly yet, but in my initial > import of my mail I made a couple of patches to notmuch new that let > me get the tags right first. One was to make: > > notmuch new --initial-tags=list,unread > > set the initial tags for newly found messages to "list" and "unread" > instead of the default "inbox" and "unread". > > The other was to make: > > find Mail/.Saved/ -type f | notmuch new --initial-tags=archived > --file-list > > only process the mail files listed on stdin (via find), and give them > the explicit tags I specify. That way I could import all my existing > archived mail without it appearing in my inbox or as unread. Hmm, quite interesting feature. I think that several people asked for this in the past. I'd be happy to see the patches. -Michal
Re: [RFC] reordering and cleanup of thread authors
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.
Hi Dirk,
thanks for the patch. It is a very interesting feature. See my comments
below.
[...]
+/*
+ * 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? 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.
-Michal
+ /* we have to make changes, so let's get a temp copy */
+ authorscopy = strdup(thread-authors);
+ if (authorscopy == NULL)
+ return;
+ /* nmstart is the offset into where the non-matched authors start */
+ nmstart = thread-nonmatched_authors - thread-authors;
+ /* copy this author and add the | - the if clause above tells us
there's more */
+ strncpy(thread-nonmatched_authors,author,author_len);
+ strncpy(thread-nonmatched_authors+author_len,| ,2);
+ thread-nonmatched_authors += author_len+2;
+ if (idx 0) {
+ /* we are actually moving authors around, not just changing the
separator
+* first copy the authors that came BEFORE our author */
+ strncpy(thread-nonmatched_authors, authorscopy+nmstart, idx-2);
+ /* finally, if there are authors AFTER our author, copy those */
+ if(author_len+nmstart+idx authors_len) {
+ strncpy(thread-nonmatched_authors + idx - 2,, ,2);
+ strncpy(thread-nonmatched_authors + idx, authorscopy+nmstart + idx
+ author_len + 2,
+ authors_len - (nmstart + idx + author_len + 2));
+ }
+ }
+ free(authorscopy);
+} else {
+ thread-nonmatched_authors += author_len;
+}
+return;
+}
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [Sebastian Spaeth] Pull requests
On 2010-04-08, Michal Sojka wrote: I think that the patch you sent was not the latest version. The latest is in id:1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz, but it is not rebased to the current master. Not sure what I am doing wrong, but with this patch even after a dump/delete/new/restore. I get ./notmuch count to: 11788 ./notmuch count folder: 247 ./notmuch count folder:inbox 0 My folders have no weird naming, they are e.g.: /home/spaetz/mail/INBOX/cur/1258732076_0.22934.spaetz-macbook,U=468,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [Sebastian Spaeth] Pull requests
On Fri, 09 Apr 2010, Sebastian Spaeth wrote: On 2010-04-08, Michal Sojka wrote: I think that the patch you sent was not the latest version. The latest is in id:1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz, but it is not rebased to the current master. Not sure what I am doing wrong, but with this patch even after a dump/delete/new/restore. I get ./notmuch count to: 11788 ./notmuch count folder: 247 ./notmuch count folder:inbox 0 Hi Sebastian, I do not have time to help you with this right now, but you can try the following patch to debug what's happening. It should apply on top of your issue28-search-folder-name branch. -Michal diff --git a/notmuch-new.c b/notmuch-new.c index e787407..ebeb287 100644 --- a/notmuch-new.c +++ b/notmuch-new.c @@ -416,6 +416,7 @@ add_files_recursive (notmuch_database_t *notmuch, case NOTMUCH_STATUS_SUCCESS: state-added_messages++; tag_inbox_and_unread (message); + printf(DBG: Added new message: folder=%s message=%s\n, folder, next); break; /* Non-fatal issues (go on to next file) */ case NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID: ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On 2010-04-08, micah anderson wrote: On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote: For the upcoming 0.2 release, here are some things that I would like to have in place: * Changes to indexing, (addition of body:, folder:, list:, etc.). This is stuff that I'll work on. Also, fwiw, the folder: indexing is probably the new feature that I'm most eagerly awaiting. I've got all these ideas for ways to handle sent mail and drafts if we can get this working. +1 on folder: capability! micah pgpgiiX8oXfoW.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Initial attempt at a merge window for notmuch
I want to figure out how to make a release process that will work for notmuch. An idea I have now is to use a date-based merge window during which features are nominated for the release. So I took a window starting at my original request for 0.2 features until now. In our current (lame) syntax for specifying date ranges, that gives me a search string of: tag:notmuch and 1270678364..1270828505 and not (tag:merged or tag:postponed) What I want to do now is to work through this list and tag things as either merged or postponed until my list is empty. That should give a good indication that we've actually got all the features we want. (We'll still need something more for tracking bugs, of course.) Here's the current list: [22/22] Carl Worth, James... Plans for the 0.2 release (this week) [2/6] Carl Worth, Micha... Notmuch release 0.1 now available [2/4] Dirk Hohndel, Car... [PATCH] Fix code extracting the MTA from Received: headers [1/2] Mike Kelly, Carl ... [PATCH] Fix the default value for --includedir. [2/5] David Edmondson, ... [notmuch] [PATCH] notmuch.el: 'F' in search mode takes us to a list of folders. [2/2] Sebastian Spaeth,... RFC: User-Agent header [1/30] Aneesh Kumar K.V,... [notmuch] [PATCH] notmuch: Add Maildir directory name as tag name for messages [3/10] Sebastian Spaeth,... [notmuch] [Sebastian Spaeth] Pull requests [5/5] Michal Sojka [PATCH 0/4] Mailstore abstraction v4 [2/2] Michal Sojka [PATCH] Mailstore abstraction v4 - part 2 (maildir synchronization) [2/2] Mike Kelly, Sebas... [PATCH] Have notmuch count default to showing the total. [3/3] Mike Kelly [PATCH 1/3] Initial support for maildir flags. [1/2] Dirk Hohndel, Mic... [RFC] reordering and cleanup of thread authors [1/10] Jesse Rosenthal, ... [notmuch] [PATCH] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id [1/11] Jesse Rosenthal, ... [notmuch] [PATCH] notmuch.el: add functionality to add or remove tags by region. Of course, just looking at this list makes me want many more features (but they are too late for this merge window): 1. Real support for date-range-based searches 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. 3. Ability to easily post search results to a web page. I'd like people to be able to easily view a web page with three lists on it for tracking the upcoming release: proposed features, merged features, and postponed features. 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. So I want the set of threads which have a message of tag:inbox and subtract from that the set of threads which have a message of tag:muted. Note that this result is different than what we can currently compute which is a set of threads containing messages that match tag:inbox and not tag:muted. This will return threads that I have muted when new messages arrive to the thread after I added the muted tag to the older messages. So we do need some new support here. 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. I'm not sure how to best provide the ability to express the result I want here. But clearly, we want to come up with a syntax that's powerful enough to capture these kinds of things. (And I think this will go beyond the search capabilities of most email systems that I'm aware of.) -Carl pgpR8Y5t0wRxn.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Have notmuch count default to showing the total.
On Fri, 09 Apr 2010 15:01:35 +0200, Sebastian Spaeth sebast...@sspaeth.de 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). But let me express support (It's notmuch worth, I know (haha)) for this patch. I think it makes lots of sense: 1) I often want to know how many mails are in my db. notmuch count or notmuch count * is the intuitive syntax I would use for that. Right now there is no way as far as I can see. I use notmuch count To - not very intuitive, though. 2) Search terms filter out things. The empty search term stands therefore for all my mails. It is consistent to have the search term '' represent all my mail. Actually, I'd like to disagree. A search argument of '' should get you a help text. A search argument of '*' should give you all email. 3) I don't expect a help text for notmuch count just as I don't expect a help text for notmuch log, we are very explicit about notmuch help and notmuch help count in many parts of our documentation. My main concern here is that once you have a gazzillion emails, typing notmuch search with no argument over a slow link (or using it from within a gui by mistake) could really cause a lot of unnecessary compute / data transfer. So I'd rather have a special character be the one that triggers that behavior. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Initial attempt at a merge window for notmuch
On Sat, Apr 10, 2010 at 02:23, Carl Worth cwo...@cworth.org 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 a...@erisian.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [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 sojk...@fel.cvut.cz 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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Derive version numbers from git
On Thu, 08 Apr 2010 13:49:22 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: On Wed, 07 Apr 2010, Carl Worth wrote: I have modified the patch slightly and I think that it could solve the above points. The release process should be modified this way: you skip point 5 (increment the notmuch version in Makefile.local) and in point 6, you run 'make release VERSION=X.Y'. Looks great. I've pushed that now and updated the instructions in RELEASING. It occurs to me that I'm already updating the version in the NEWS file, so the next step would be to just make make release get it from there. But in the meantime, having these nice git-describe-generated version numbers will be quite handy (86 commits since 0.1 already, wow!). So, thanks! -Carl pgpdpwy7lDzus.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] reordering and cleanup of thread authors
On Sat, 10 Apr 2010 03:53:59 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: 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. That's a great idea. I'll update the patch to do that. /D -- Dirk Hohndel Intel Open Source Technology Center ___ 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 hohn...@infradead.org wrote: On Thu, 08 Apr 2010 10:26:01 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: No patch yet, just asking if this is a good idea or not. Yes. A fine idea. I think it's a very good idea. But it should be something that includes the other components of how you send email... Like User-Aget: Emacs 23 Message-mode / notmuch-0.1.1 A quick grep through some of my recent mails does show precedent for this kind of thing: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.90 (gnu/linux) Unsurprisingly, these suer-agent strings can become arbitrarily unwieldy: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0pre Thunderbird/3.0.4 Or extremely simple: User-Agent: Sup/0.11 I don't see the advantage of duplicating the name and version in the parenthesized comment, but here's an idea that looks useful: User-Agent: Loom/3.14 (http://gmane.org/) So I propose something like: User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) If anybody wants to start assembling a patch to generate that, that would be great. -Carl pgpQ3ZqA8oamV.pgp Description: PGP signature ___ 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 cwo...@cworth.org wrote: So I propose something like: User-Agent: Notmuch/0.2 (http://notmuchmail.org) Emacs/23.1.1 (gnu/linux) +1 /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
here's what's going wrong. Look at the To: line... /D On Fri, 09 Apr 2010 20:06:09 -0700, Carl n∅tmuch 䚳 Worth cwo...@cworth.org wrote: On Fri, 09 Apr 2010 09:35:07 +0200, Sebastian Spaeth sebast...@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? Let's test that here... -Carl PS. How about this for something interesting from Unicode: 䚳 Definition in English: do not know, to know nothing about, quickly; fast, sharp; keen Non-text part: application/pgp-signature -- Dirk Hohndel Intel Open Source Technology Center ___ 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:44:02 -0700, Dirk Hohndel hohn...@infradead.org wrote: here's what's going wrong. Look at the To: line... Carl =?UTF-8?b?buKIhXRtdWNoIOSasw==?= Worth cwo...@cworth.org, that's not pretty... nor readable. /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
