About the json output and the number of results shown.
I've had other problems attempting to use the JSON interface recently. For starters, if I'm simply trying to retrieve a single message, the interface is rather awkard. I seem to need to do something like: my $json = `notmuch show --format=json id:$message_id`; my $parsed_json = decode_json($json); my $message = $parsed_json->[0][0][0]; And, when I'm doing my search earlier to even find those message ids, I need to do a check to `notmuch count` first to see if I'll even get any results, because the 0 result case is not valid JSON. Of course, any feedback, like "you're doing it wrong" would be helpful. My script is available at: http://git.pioto.org/gitweb?p=pioto-scripts.git;a=blob;f=mail/notmuch-poll.pl;hb=master -- Mike Kelly
About the json output and the number of results shown.
Hi, The notmuch command line tool has an option that seems very interesting to me: --output=json In several languages, and especially in python, json is as easy to parse as: >>> res = json.load(stream) If your stream contains valid json, you then get all your data in res and you can immediately use it. With notmuch, some commands can bring a lot of results, and can take some time to return. That is why when I began to write a curse interface to notmuch, I added a mechanism to spawn these commands in background and gather the results asynchronously. Sadly, this makes me unable to use the built-in python json parser: As long as the output has not finished, the data on the stream is not valid json since it lacks at least the closing bracket '}'. As a consequence, I find easier not to use json and parse the data as it arrives. So I am wondering: what is the point of having a tool that is able to output json and ending in not using it? Is there a solution to make the json output more useable? One solution I've been thinking about would be to add an option: the range of results to show (something like --range=25:50). Is it doable easily? I mean: if results are not guaranteed to be in a given order, that would obviously be an issue. Same if finding the results 25:50 is exactly as long as finding the results 1:50. Otherwise, if it is doable, I guess this mail is a feature request. In any case, do you have any proposal for making sense of this json output without modifications in the notmuch CLI? Cheers, Christophe-Marie Duquesne
[PATCH] Have to configure and build inside the source directory.
On Tue, 11 Jan 2011, Thomas Schwinge wrote:
> From: Thomas Schwinge
>
> Signed-off-by: Thomas Schwinge
>
> ---
> configure | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/configure b/configure
> index c58dd0f..b5e446c 100755
> --- a/configure
> +++ b/configure
> @@ -188,6 +188,17 @@ developers. Then, please email those details to the
> Notmuch list
> (notmuch at notmuchmail.org) so that we can hopefully make future
> versions of notmuch easier for you to use.
>
> +EOF
> +
> +if ! { : < configure; } 2> /dev/null; then
I think that "if ! test -f configure; then" be more readable.
-Michal
Tag changes not persisted in message view
On Sun, 09 Jan 2011, G?nter Ladwig wrote: > Hi, > > I installed notmuch yesterday and imported an account with about 9000 > mails. The import worked fine and the Emacs client shows all messages. > > However, I ran into an problem with changing tags in the message view: I > noticed that mails were not marked as read (i.e., their unread tag was > not removed) after reading them in the message view. After some > experimentation I can say that adding or removing tags in the message > view does not work at all (neither manually nor implicitly through > reading or archiving). While the UI is updated (i.e., the tags shown in > the headers), the changes are not persisted. Neither the search results > view nor the command line client show the changes made in the message > view. After reopening a message, the tags will again appear as before. Hi, It seems like the tags are not updated in the database, but only in the UI where the update is done independently of database. Do you see some error messages in the minibuffer when you change the tags? For example: A Xapian exception occurred opening database: Unable to get write lock on : already locked > Changing tags from the search results view or the command line works > fine, even though it is slow (I think this is caused by that Xapian bug > I saw some references to). Adding and removing tags in the message view > is however instantaneous (although ineffective), which seems to indicate > that Xapian was not called (or incorrectly). You can check which commands are invoked from emacs UI by having this script --8<---cut here---start->8--- #!/bin/sh echo "$@" >> /tmp/notmuch-ui.log notmuch "$@" --8<---cut here---end--->8--- and running emacs like emacs --eval '(setq notmuch-command "/path/to/the/script")' The commands invoked by the UI can be found in /tmp/notmuch-ui.log. Check whether the tagging commands work if you run them manually. > I'm using the latest version from the git repository (although I tried > 0.5 as well, without any difference). I'm on Mac OS with Cocoa Emacs > 23.2.1 (tried the console version as well). I also tried a pristine > Emacs configuration to remove interference with other Emacs packages, > but no such luck. Here's output from configure: > > Checking for Xapian development files... Yes (1.0.15). This seems to be quite old version of Xapian. I'm not aware of any API incompatibilities in the versions, but you may try a newer version (1.2.x). -Michal
[ANN] notmuch-deliver
Out of curiosity, has anyone considered using inotify to monitor maildirs for new mail to hand to notmuch? For systems supporting inotify (or equivalents), this would have the advantage of being compatible with any delivery mechanism, be it a mail server, procmail, or emacs fcc'ing a maildir. On Mon, Nov 8, 2010 at 12:50 PM, Carl Worth wrote: > On Wed, 26 May 2010 17:01:34 +0300, Ali Polatel wrote: > > notmuch-deliver is a maildir delivery tool for notmuch mail indexer. It > > reads from standard input, delivers the mail to the specified maildir > > and adds it to the notmuch database. This is meant as a convenient > > alternative to running notmuch new after mail delivery. > > Thanks for sharing this, Ali. > > What's the best way to advertise this to potential users? > > Should we include a separate utils directory in the notmuch repository > with auxiliary programs like this? > > Or should we implement this functionality within the notmuch binary > itself? > > I'm open to suggestions. > > If nothing else, the notmuchmail.org web page should grow a section to > point to auxiliary programs like this that users might find helpful. > > Thanks again, > > -Carl > > -- > carl.d.worth at intel.com > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch > > -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110112/cf4c0d73/attachment.html>
Re: About the json output and the number of results shown.
I've had other problems attempting to use the JSON interface recently. For starters, if I'm simply trying to retrieve a single message, the interface is rather awkard. I seem to need to do something like: my $json = `notmuch show --format=json id:$message_id`; my $parsed_json = decode_json($json); my $message = $parsed_json->[0][0][0]; And, when I'm doing my search earlier to even find those message ids, I need to do a check to `notmuch count` first to see if I'll even get any results, because the 0 result case is not valid JSON. Of course, any feedback, like "you're doing it wrong" would be helpful. My script is available at: http://git.pioto.org/gitweb?p=pioto-scripts.git;a=blob;f=mail/notmuch-poll.pl;hb=master -- Mike Kelly ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [ANN] notmuch-deliver
Out of curiosity, has anyone considered using inotify to monitor maildirs for new mail to hand to notmuch? For systems supporting inotify (or equivalents), this would have the advantage of being compatible with any delivery mechanism, be it a mail server, procmail, or emacs fcc'ing a maildir. On Mon, Nov 8, 2010 at 12:50 PM, Carl Worth wrote: > On Wed, 26 May 2010 17:01:34 +0300, Ali Polatel wrote: > > notmuch-deliver is a maildir delivery tool for notmuch mail indexer. It > > reads from standard input, delivers the mail to the specified maildir > > and adds it to the notmuch database. This is meant as a convenient > > alternative to running notmuch new after mail delivery. > > Thanks for sharing this, Ali. > > What's the best way to advertise this to potential users? > > Should we include a separate utils directory in the notmuch repository > with auxiliary programs like this? > > Or should we implement this functionality within the notmuch binary > itself? > > I'm open to suggestions. > > If nothing else, the notmuchmail.org web page should grow a section to > point to auxiliary programs like this that users might find helpful. > > Thanks again, > > -Carl > > -- > carl.d.wo...@intel.com > > ___ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch > > ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
About the json output and the number of results shown.
Hi, The notmuch command line tool has an option that seems very interesting to me: --output=json In several languages, and especially in python, json is as easy to parse as: >>> res = json.load(stream) If your stream contains valid json, you then get all your data in res and you can immediately use it. With notmuch, some commands can bring a lot of results, and can take some time to return. That is why when I began to write a curse interface to notmuch, I added a mechanism to spawn these commands in background and gather the results asynchronously. Sadly, this makes me unable to use the built-in python json parser: As long as the output has not finished, the data on the stream is not valid json since it lacks at least the closing bracket '}'. As a consequence, I find easier not to use json and parse the data as it arrives. So I am wondering: what is the point of having a tool that is able to output json and ending in not using it? Is there a solution to make the json output more useable? One solution I've been thinking about would be to add an option: the range of results to show (something like --range=25:50). Is it doable easily? I mean: if results are not guaranteed to be in a given order, that would obviously be an issue. Same if finding the results 25:50 is exactly as long as finding the results 1:50. Otherwise, if it is doable, I guess this mail is a feature request. In any case, do you have any proposal for making sense of this json output without modifications in the notmuch CLI? Cheers, Christophe-Marie Duquesne ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Have to configure and build inside the source directory.
On Tue, 11 Jan 2011, Thomas Schwinge wrote:
> From: Thomas Schwinge
>
> Signed-off-by: Thomas Schwinge
>
> ---
> configure | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/configure b/configure
> index c58dd0f..b5e446c 100755
> --- a/configure
> +++ b/configure
> @@ -188,6 +188,17 @@ developers. Then, please email those details to the
> Notmuch list
> (notmuch@notmuchmail.org) so that we can hopefully make future
> versions of notmuch easier for you to use.
>
> +EOF
> +
> +if ! { : < configure; } 2> /dev/null; then
I think that "if ! test -f configure; then" be more readable.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Tag changes not persisted in message view
On Sun, 09 Jan 2011, Günter Ladwig wrote: > Hi, > > I installed notmuch yesterday and imported an account with about 9000 > mails. The import worked fine and the Emacs client shows all messages. > > However, I ran into an problem with changing tags in the message view: I > noticed that mails were not marked as read (i.e., their unread tag was > not removed) after reading them in the message view. After some > experimentation I can say that adding or removing tags in the message > view does not work at all (neither manually nor implicitly through > reading or archiving). While the UI is updated (i.e., the tags shown in > the headers), the changes are not persisted. Neither the search results > view nor the command line client show the changes made in the message > view. After reopening a message, the tags will again appear as before. Hi, It seems like the tags are not updated in the database, but only in the UI where the update is done independently of database. Do you see some error messages in the minibuffer when you change the tags? For example: A Xapian exception occurred opening database: Unable to get write lock on : already locked > Changing tags from the search results view or the command line works > fine, even though it is slow (I think this is caused by that Xapian bug > I saw some references to). Adding and removing tags in the message view > is however instantaneous (although ineffective), which seems to indicate > that Xapian was not called (or incorrectly). You can check which commands are invoked from emacs UI by having this script --8<---cut here---start->8--- #!/bin/sh echo "$@" >> /tmp/notmuch-ui.log notmuch "$@" --8<---cut here---end--->8--- and running emacs like emacs --eval '(setq notmuch-command "/path/to/the/script")' The commands invoked by the UI can be found in /tmp/notmuch-ui.log. Check whether the tagging commands work if you run them manually. > I'm using the latest version from the git repository (although I tried > 0.5 as well, without any difference). I'm on Mac OS with Cocoa Emacs > 23.2.1 (tried the console version as well). I also tried a pristine > Emacs configuration to remove interference with other Emacs packages, > but no such luck. Here's output from configure: > > Checking for Xapian development files... Yes (1.0.15). This seems to be quite old version of Xapian. I'm not aware of any API incompatibilities in the versions, but you may try a newer version (1.2.x). -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
