Address completion
On Tue, 20 Apr 2010 23:33:11 +0200, "Sebastian Spaeth" wrote: > Oh my goodness. I just tried > http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el > together with the latest version of my "addrlookup" tool (which does the > same as jkr's notmuch_addresses.py) and it just works, even in current > cworth/master. > > Address completion for to: and cc: headers based on my notmuch database, > sweet! Thanks David. I only need to reverse the sort order of addrlookup > as this uses most-to-least likely (which is more intuitive than eudc's > least-to-most likely sort order). > > BTW, addrlookup now first tries to find matches that I previously sent > mails to and failing that it will try to find matches for all from: > addresses that match the search. BTW: your version fails badly with the "Last, First" (including quotes) names that Exchange produces... I get First" Not ideal :-) /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010, David Edmondson wrote: > On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka > wrote: > > > I'm puzzled why you chose to pass a filename as the argument to 'cat' > > > rather than a message id (id:foo at bar.com)? > > > > The reason is that I want be able to distinguish between several > > messages with the same id. > > It strikes me that notmuch is not well suited to this in general. For > example, how would you find the filenames for the two messages with the > same message id? Currently, it is probably not possible but I can imagine that "notmuch show" will output all file names associated with the message id and user could select between them if he needs. M.
[PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 13:13:36 +0200, Michal Sojka wrote: > On Tue, 20 Apr 2010, David Edmondson wrote: > > On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka > > wrote: > > > > I'm puzzled why you chose to pass a filename as the argument to 'cat' > > > > rather than a message id (id:foo at bar.com)? > > > > > > The reason is that I want be able to distinguish between several > > > messages with the same id. > > > > It strikes me that notmuch is not well suited to this in general. For > > example, how would you find the filenames for the two messages with the > > same message id? > > Currently, it is probably not possible but I can imagine that "notmuch > show" will output all file names associated with the message id and user > could select between them if he needs. If the filenames are really 'unique message identifiers' and may not work when passed to open(2), then I don't have a problem. dme. -- David Edmondson, http://dme.org
[PATCH 1/2] Add 'cat' subcommand
On 20.4.2010 09:21, David Edmondson wrote: > On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojka wrote: >> This command dumps a raw message identified by a filename to the >> standard output. It allows MUAs to access the messages for piping, >> attachment manipulation, etc. in the same way as it is done in >> notmuch-show-mode (through notmuch show subcommand). This will simplify >> the MUAs when they need to operate with a remote database. > > I'm puzzled why you chose to pass a filename as the argument to 'cat' > rather than a message id (id:foo at bar.com)? The reason is that I want be able to distinguish between several messages with the same id. Consider a message sent to a list. One copy is stored in your sent folder and one in another folder. You may want to investigate the Received headers the latter message. You would not be happy if, after pressing 'V', notmuch shows you the message in sent folder without any headers. The same holds for pipe command. I think that the message you pipe to some command should be exactly the same you see in your client. On 20.4.2010 10:09, Sebastian Spaeth wrote: > I agree, especially as some people want to introduce abstract mailstores > which might not even have the concept of a file name :). OK, maybe file name is not the proper name for it :-). In my abstract mail stores, I use the "file name" just as an unique identifier of the message. Michal
[PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka wrote: > > I'm puzzled why you chose to pass a filename as the argument to 'cat' > > rather than a message id (id:foo at bar.com)? > > The reason is that I want be able to distinguish between several > messages with the same id. It strikes me that notmuch is not well suited to this in general. For example, how would you find the filenames for the two messages with the same message id? dme. -- David Edmondson, http://dme.org
[PATCH 1/2] Add 'cat' subcommand
> I'm puzzled why you chose to pass a filename as the argument to 'cat' > rather than a message id (id:foo at bar.com)? I agree, especially as some people want to introduce abstract mailstores which might not even have the concept of a file name :). Passing a message-id seems more useful. Sebastian
"bouncing" messages
On 2010-04-20, micah anderson wrote: > It would be great if this became a key to make this easier. In mutt, > that key is 'b', which prompts you who you should send the message > to. That key is already bound to showing the body in notmuch, but I'm > sure there are other options. I'm pretty sure, we can get a nice keybinding that invokes message mode's "message-resend" function or something similar. The only disadvantag is that it asks for the mail address in the minibuffer, not using mail tab-completion mechansisms. Sebastian
The archive operation should only archive open messages
- "Carl Worth" a ?crit : > Once we fix that, I think we can go back to having tag operations > only > affect matched messages in the search view, and I agree that this > will > be extremely convenient. > What about using prefixes to each command, the way Gnus does it*? For instance, 'd' should tag the matched messages, "D" or all messages in the thread. Same for show mode: for instance 'd' for all matched messages , "D" for all messages in the thread, and "C-d" for the current message only. Matthieu * All Gnus key chains that begin with "T" affect the current thread.
[PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka wrote:
> The reason is that I want be able to distinguish between several
> messages with the same id. Consider a message sent to a list. One copy
> is stored in your sent folder and one in another folder. You may want to
> investigate the Received headers the latter message. You would not be
> happy if, after pressing 'V', notmuch shows you the message in sent
> folder without any headers.
I think this is actually a problem with notmuch, and something that I
have complained about in the past. It was previously dismissed, but I
still think that it's something we should address. Notmuch should not
irrevocably hide messages, just because they cursorily look like a
another similar but distinct message.
What are ways that we can avoid this? Could notmuch append a string to
the message id in the database for the different messages that share an
id? Something like "id:foo at bar.com{0}", "id:foo at bar.com{1}", etc?
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/20100420/96bfc301/attachment-0001.pgp>
[PATCH 2/2] emacs: Access raw messages through cat subcommand
The following commands now access the messages via the cat subcommand: view/save attachments, view raw message and pipe message to command. With this patch, it is straightforward to use notmuch emacs interface with a remote database accessed over SSH. To do this, it is sufficient to redefine notmuch-command variable to contain the name of a script containing: ssh user at host notmuch "$@" If the ssh client has enabled connection sharing (ControlMaster option in OpenSSH), the emacs interface is almost as responsive as with local invocation. Signed-off-by: Michal Sojka --- emacs/notmuch-show.el | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 81276d9..29a726e 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -328,7 +328,11 @@ buffer." (defun notmuch-show-view-raw-message () "View the raw email of the current message." (interactive) - (view-file (notmuch-show-get-filename))) + (let ((filename (notmuch-show-get-filename))) +(let ((buf (get-buffer-create (concat "*notmuch-raw-" filename "*" + (switch-to-buffer buf) + (save-excursion + (call-process notmuch-command nil t nil "cat" filename) (defmacro with-current-notmuch-show-message ( body) "Evaluate body with current buffer set to the text of current message" @@ -336,7 +340,7 @@ buffer." (let ((filename (notmuch-show-get-filename))) (let ((buf (generate-new-buffer (concat "*notmuch-msg-" filename "*" (with-current-buffer buf - (insert-file-contents filename nil nil nil t) + (call-process notmuch-command nil t nil "cat" filename) , at body) (kill-buffer buf) @@ -390,7 +394,8 @@ current email message as stdin. Anything printed by the command to stdout or stderr will appear in the *Messages* buffer." (interactive "sPipe message to command: ") (apply 'start-process-shell-command "notmuch-pipe-command" "*notmuch-pipe*" -(list command " < " (shell-quote-argument (notmuch-show-get-filename) +(list notmuch-command "cat" + (shell-quote-argument (notmuch-show-get-filename)) " | " command))) (defun notmuch-show-move-to-current-message-summary-line () "Move to the beginning of the one-line summary of the current message. -- 1.7.0.4
"bouncing" messages
On Tue, 20 Apr 2010 10:07:21 +0200, "Sebastian Spaeth" wrote: > On 2010-04-20, micah anderson wrote: > I'm pretty sure, we can get a nice keybinding that invokes message mode's > "message-resend" function or something similar. The only disadvantag is > that it asks for the mail address in the minibuffer, not using mail > tab-completion mechansisms. That's not so tragic, especially considering the nice integration it provides. But that said, it must be possible to get bbdb message completion in the minibuffer as well, right? Has anyone looked into that? 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/20100420/bcb92133/attachment.pgp>
[PATCH] json: Avoid calling strlen(NULL)
> There's already a check in json_quote_chararray for len==0, so it > might be sensible to say: > > return (json_quote_chararray (ctx, str, str != NULL ? strlen (str) : 0)); > > OTOH, the code in json_quote_array to deal with that does the same > thing (returns a literal string containing two quote marks), which > seems wrong -- the normal code path is to talloc to get a newly > allocated, editable string, that might be talloc_free'd later, > wouldn't it make more sense just to let the str==NULL / len==0 > behaviour fall through into the normal case code? Yes, that's the correct analysis. Thanks so much. > commit 5b93a488221b50c02db18d86a550cb3c038c00da > Author: Anthony > Date: Tue Apr 6 18:10:39 2010 +1000 > > json: Avoid calling strlen(NULL), and always return a newly > talloced array. I've pushed this out now, (separated into two pieces). -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/20100420/8b505c7f/attachment.pgp>
[PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojka wrote: > This command dumps a raw message identified by a filename to the > standard output. It allows MUAs to access the messages for piping, > attachment manipulation, etc. in the same way as it is done in > notmuch-show-mode (through notmuch show subcommand). This will simplify > the MUAs when they need to operate with a remote database. I'm puzzled why you chose to pass a filename as the argument to 'cat' rather than a message id (id:foo at bar.com)? Removing knowledge of filenames (or that anything is stored as a file) from the UI seems like a good idea. dme. -- David Edmondson, http://dme.org
pull request
On Mon, 19 Apr 2010 11:07:40 -0700, Carl Worth wrote: > > commit 8586a86b9dd4ed2406a2fbda6c08bdc6a598cfd8 > > debian: git should ignore packaging intermediate files > > I committed an alternate version of this, (with a new debian/.gitignore > file). I used more wildcarding too. And I couldn't actually find how to > make all these files appear. If you need more ignores, just let me know > (and let me know what commands trigger those, since I'm curious). >From memory I ran 'debuild'. > > commit 53c4e64943d09b07e75c9258fc9f954c87a490d6 > > json: Avoid calling strlen(NULL) > > That commit message describes this hunk of the patch: > > > +if (str == NULL) > > + str = ""; > > + > > return (json_quote_chararray (ctx, str, strlen (str))); > > But this other hunk looks independent. What's going on here? > > > -if (len == 0) > > - return (char *)"\"\""; > > - > > So I haven't committed this piece yet. The second chunk was intended to cover a similar case (len == 0), but becomes unnecessary after the first chunk. At least, that's what I convinced myself after the conversation with Anthony Towns (id:h2y87b3a4191004060117v5421db8ejbe3030d0626e7440 at mail.gmail.com). dme. -- David Edmondson, http://dme.org
Difference between search and filter
Hi, GNU Emacs interface comes with 2 functions I am not sure I am using correctly. What's the difference between searching and filtering exactly (s and f) ? It seems to me that they deserve the same purpose. Regards, Xavier
[PATCH 2/2] emacs: Access raw messages through cat subcommand
The following commands now access the messages via the cat subcommand: view/save attachments, view raw message and pipe message to command. With this patch, it is straightforward to use notmuch emacs interface with a remote database accessed over SSH. To do this, it is sufficient to redefine notmuch-command variable to contain the name of a script containing: ssh u...@host notmuch $@ If the ssh client has enabled connection sharing (ControlMaster option in OpenSSH), the emacs interface is almost as responsive as with local invocation. Signed-off-by: Michal Sojka sojk...@fel.cvut.cz --- emacs/notmuch-show.el | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 81276d9..29a726e 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -328,7 +328,11 @@ buffer. (defun notmuch-show-view-raw-message () View the raw email of the current message. (interactive) - (view-file (notmuch-show-get-filename))) + (let ((filename (notmuch-show-get-filename))) +(let ((buf (get-buffer-create (concat *notmuch-raw- filename * + (switch-to-buffer buf) + (save-excursion + (call-process notmuch-command nil t nil cat filename) (defmacro with-current-notmuch-show-message (rest body) Evaluate body with current buffer set to the text of current message @@ -336,7 +340,7 @@ buffer. (let ((filename (notmuch-show-get-filename))) (let ((buf (generate-new-buffer (concat *notmuch-msg- filename * (with-current-buffer buf - (insert-file-contents filename nil nil nil t) + (call-process notmuch-command nil t nil cat filename) ,@body) (kill-buffer buf) @@ -390,7 +394,8 @@ current email message as stdin. Anything printed by the command to stdout or stderr will appear in the *Messages* buffer. (interactive sPipe message to command: ) (apply 'start-process-shell-command notmuch-pipe-command *notmuch-pipe* -(list command(shell-quote-argument (notmuch-show-get-filename) +(list notmuch-command cat + (shell-quote-argument (notmuch-show-get-filename)) | command))) (defun notmuch-show-move-to-current-message-summary-line () Move to the beginning of the one-line summary of the current message. -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] Add 'cat' subcommand
This command dumps a raw message identified by a filename to the
standard output. It allows MUAs to access the messages for piping,
attachment manipulation, etc. in the same way as it is done in
notmuch-show-mode (through notmuch show subcommand). This will simplify
the MUAs when they need to operate with a remote database.
Signed-off-by: Michal Sojka sojk...@fel.cvut.cz
---
NEWS |3 +++
notmuch-client.h |3 +++
notmuch-show.c | 39 +++
notmuch.c|4
4 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/NEWS b/NEWS
index eba0fd5..1a81e64 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+A new subcommand 'cat' was added, which simplifies use of Emacs
+interface with remote database (accessed over SSH).
+
Notmuch 0.2 (2010-04-16)
This is the second release of the notmuch mail system, with actual
diff --git a/notmuch-client.h b/notmuch-client.h
index d36b9ec..0efc41c 100644
--- a/notmuch-client.h
+++ b/notmuch-client.h
@@ -111,6 +111,9 @@ int
notmuch_search_tags_command (void *ctx, int argc, char *argv[]);
int
+notmuch_cat_command (void *ctx, int argc, char *argv[]);
+
+int
notmuch_part_command (void *ctx, int argc, char *argv[]);
const char *
diff --git a/notmuch-show.c b/notmuch-show.c
index 76873a1..bade9bb 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -504,6 +504,45 @@ notmuch_show_command (void *ctx, unused (int argc), unused
(char *argv[]))
}
int
+notmuch_cat_command (void *ctx, unused (int argc), unused (char *argv[]))
+{
+int i;
+FILE *file;
+const char *filename;
+size_t size;
+char buf[4096];
+
+(void)ctx;
+
+for (i = 0; i argc argv[i][0] == '-'; i++) {
+ fprintf (stderr, Unrecognized option: %s\n, argv[i]);
+ return 1;
+}
+
+argc -= i;
+argv += i;
+
+if (argc == 0) {
+ fprintf (stderr, Error: No filename given\n);
+ return 1;
+}
+filename = argv[0];
+
+file = fopen (filename, r);
+if (file == NULL) {
+ fprintf (stderr, Error: Cannot open %s: %s\n, filename, strerror
(errno));
+ return 1;
+}
+while (!feof (file)) {
+ size = fread(buf, 1, sizeof(buf), file);
+ fwrite (buf, size, 1, stdout);
+}
+fclose (file);
+
+return 0;
+}
+
+int
notmuch_part_command (void *ctx, unused (int argc), unused (char *argv[]))
{
notmuch_config_t *config;
diff --git a/notmuch.c b/notmuch.c
index 0eea5e1..477d746 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -296,6 +296,10 @@ command_t commands[] = {
\tcontain tags only from messages that match the search-term(s).\n
\n
\tIn both cases the list will be alphabetically sorted. },
+{ cat, notmuch_cat_command,
+ path,
+ Dump raw message identified by path to standard output.,
+ },
{ part, notmuch_part_command,
--part=num search-terms,
Output a single MIME part of a message.,
--
1.7.0.4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: The archive operation should only archive open messages
- Carl Worth cwo...@cworth.org a écrit : Once we fix that, I think we can go back to having tag operations only affect matched messages in the search view, and I agree that this will be extremely convenient. What about using prefixes to each command, the way Gnus does it*? For instance, 'd' should tag the matched messages, D or all messages in the thread. Same for show mode: for instance 'd' for all matched messages , D for all messages in the thread, and C-d for the current message only. Matthieu * All Gnus key chains that begin with T affect the current thread. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bouncing messages
On 2010-04-20, micah anderson wrote: It would be great if this became a key to make this easier. In mutt, that key is 'b', which prompts you who you should send the message to. That key is already bound to showing the body in notmuch, but I'm sure there are other options. I'm pretty sure, we can get a nice keybinding that invokes message mode's message-resend function or something similar. The only disadvantag is that it asks for the mail address in the minibuffer, not using mail tab-completion mechansisms. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] Add 'cat' subcommand
I'm puzzled why you chose to pass a filename as the argument to 'cat' rather than a message id (id:f...@bar.com)? I agree, especially as some people want to introduce abstract mailstores which might not even have the concept of a file name :). Passing a message-id seems more useful. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] Add 'cat' subcommand
On 20.4.2010 09:21, David Edmondson wrote: On Tue, 20 Apr 2010 09:16:32 +0200, Michal Sojkasojk...@fel.cvut.cz wrote: This command dumps a raw message identified by a filename to the standard output. It allows MUAs to access the messages for piping, attachment manipulation, etc. in the same way as it is done in notmuch-show-mode (through notmuch show subcommand). This will simplify the MUAs when they need to operate with a remote database. I'm puzzled why you chose to pass a filename as the argument to 'cat' rather than a message id (id:f...@bar.com)? The reason is that I want be able to distinguish between several messages with the same id. Consider a message sent to a list. One copy is stored in your sent folder and one in another folder. You may want to investigate the Received headers the latter message. You would not be happy if, after pressing 'V', notmuch shows you the message in sent folder without any headers. The same holds for pipe command. I think that the message you pipe to some command should be exactly the same you see in your client. On 20.4.2010 10:09, Sebastian Spaeth wrote: I agree, especially as some people want to introduce abstract mailstores which might not even have the concept of a file name :). OK, maybe file name is not the proper name for it :-). In my abstract mail stores, I use the file name just as an unique identifier of the message. Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: I'm puzzled why you chose to pass a filename as the argument to 'cat' rather than a message id (id:f...@bar.com)? The reason is that I want be able to distinguish between several messages with the same id. It strikes me that notmuch is not well suited to this in general. For example, how would you find the filenames for the two messages with the same message id? dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010, David Edmondson wrote: On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: I'm puzzled why you chose to pass a filename as the argument to 'cat' rather than a message id (id:f...@bar.com)? The reason is that I want be able to distinguish between several messages with the same id. It strikes me that notmuch is not well suited to this in general. For example, how would you find the filenames for the two messages with the same message id? Currently, it is probably not possible but I can imagine that notmuch show will output all file names associated with the message id and user could select between them if he needs. M. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 13:13:36 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: On Tue, 20 Apr 2010, David Edmondson wrote: On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: I'm puzzled why you chose to pass a filename as the argument to 'cat' rather than a message id (id:f...@bar.com)? The reason is that I want be able to distinguish between several messages with the same id. It strikes me that notmuch is not well suited to this in general. For example, how would you find the filenames for the two messages with the same message id? Currently, it is probably not possible but I can imagine that notmuch show will output all file names associated with the message id and user could select between them if he needs. If the filenames are really 'unique message identifiers' and may not work when passed to open(2), then I don't have a problem. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] Add 'cat' subcommand
On Tue, 20 Apr 2010 12:14:56 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
The reason is that I want be able to distinguish between several
messages with the same id. Consider a message sent to a list. One copy
is stored in your sent folder and one in another folder. You may want to
investigate the Received headers the latter message. You would not be
happy if, after pressing 'V', notmuch shows you the message in sent
folder without any headers.
I think this is actually a problem with notmuch, and something that I
have complained about in the past. It was previously dismissed, but I
still think that it's something we should address. Notmuch should not
irrevocably hide messages, just because they cursorily look like a
another similar but distinct message.
What are ways that we can avoid this? Could notmuch append a string to
the message id in the database for the different messages that share an
id? Something like id:f...@bar.com{0}, id:f...@bar.com{1}, etc?
jamie.
pgpSBn8GiJwLB.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] json: Avoid calling strlen(NULL)
There's already a check in json_quote_chararray for len==0, so it might be sensible to say: return (json_quote_chararray (ctx, str, str != NULL ? strlen (str) : 0)); OTOH, the code in json_quote_array to deal with that does the same thing (returns a literal string containing two quote marks), which seems wrong -- the normal code path is to talloc to get a newly allocated, editable string, that might be talloc_free'd later, wouldn't it make more sense just to let the str==NULL / len==0 behaviour fall through into the normal case code? Yes, that's the correct analysis. Thanks so much. commit 5b93a488221b50c02db18d86a550cb3c038c00da Author: Anthony a...@erisian.com.au Date: Tue Apr 6 18:10:39 2010 +1000 json: Avoid calling strlen(NULL), and always return a newly talloced array. I've pushed this out now, (separated into two pieces). -Carl pgpisC3A1kRaE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Address completion
Oh my goodness. I just tried http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el together with the latest version of my addrlookup tool (which does the same as jkr's notmuch_addresses.py) and it just works, even in current cworth/master. Address completion for to: and cc: headers based on my notmuch database, sweet! Thanks David. I only need to reverse the sort order of addrlookup as this uses most-to-least likely (which is more intuitive than eudc's least-to-most likely sort order). BTW, addrlookup now first tries to find matches that I previously sent mails to and failing that it will try to find matches for all from: addresses that match the search. It would be trivial to include cworth's 3rd pass (or rather the 1st one) of checking entries with an address book tag first. Which would satisfy his entry in the notmuch TODO :-). which tag would make most sense? And if a message had such a tag, would that mean the to: or the from: is in the address book? Carl? It's your idea :-) Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Address completion
On Tue, 20 Apr 2010 23:33:11 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: Oh my goodness. I just tried http://github.com/dme/notmuch/raw/dme-play/emacs/notmuch-address.el together with the latest version of my addrlookup tool (which does the same as jkr's notmuch_addresses.py) and it just works, even in current cworth/master. Address completion for to: and cc: headers based on my notmuch database, sweet! Thanks David. I only need to reverse the sort order of addrlookup as this uses most-to-least likely (which is more intuitive than eudc's least-to-most likely sort order). BTW, addrlookup now first tries to find matches that I previously sent mails to and failing that it will try to find matches for all from: addresses that match the search. BTW: your version fails badly with the Last, First (including quotes) names that Exchange produces... I get First em...@add.res Not ideal :-) /D -- Dirk Hohndel Intel Open Source Technology Center ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
