[PATCH] Shell programming: directories are ``executable'' (that is, searchable), too.
On Wed, 02 Feb 2011, Thomas Schwinge wrote:
> Signed-off-by: Thomas Schwinge
> ---
> test/test-lib.sh |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index f536172..3471ead 100755
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -815,13 +815,14 @@ EOF
> }
>
>
> +# Locate the directory containing the `notmuch' executable we are to use.
> find_notmuch_path ()
> {
> dir="$1"
>
> while [ -n "$dir" ]; do
> bin="$dir/notmuch"
> - if [ -x "$bin" ]; then
> + if [ -f "$bin" -a -x "$bin" ]; then
Looks good to me. Thanks.
-Michal
search conditions on siblings/parent/children in thread
On Mon, 31 Jan 2011, Gregor Kappler wrote: > I am using notmuch for my mail and also for mailing lists. For mailing > lists it would be much more convenient to have a saved search displaying > only replies to watched (say, tag:flagged) posts instead of the whole > list. Hi Gregor, AFAIK this is not possible. I customized notmuch-search-line-faces to highlight threads with flagged messages by different background color. In the search window I still see the whole list, but the interesting threads are highlighted so I can act on them differently. > I did not find any way in notmuch to specify conditions on > sibling/parent/children posts in a post's thread during search. > > Does anybody use those searches? > > Are there plans to include this feature? There were some discussions about these kinds of searches but no patches have been posted. > > Sure, this feature would be very welcomed by me! Is there demand of > other users? > > If this is currently not possible, I do not know whether it is feasable > with xapian: can xapian this kind of search and how it would perform. I think that this kind of queries could be directly performed by Xapian only if database schema is changed. However, we could probably implement them directly in notmuch at the place where the list of the threads is constructed. Custom query parser patches (sent recently by Austin Clements) could probably help in this regard. Cheers, Michal
new "crypto" branch providing full PGP/MIME support
On Fri, 04 Feb 2011 09:32:23 -0800, Jameson Rollins wrote: > Yeah, I've found some emails that are doing this as well. I'm looking > in to what we can do to mitigate the problem, which I think is > ultimately a problem in GMime. The json output should not be > breaking, though, so that I will definitely fix. I pulled your latest updates to the crypto branch (I can reply to encrypted mails without resorting to Gnus! W00t!) and have noticed that I'm not seeing the json eof anymore, but if I grab the keys for the various folks in this thread as a test (Micah seems to be signing with an expired key?) then emacs just hangs when trying to produce the notmuch-show buffer. I can actually see the notmuch show process pegging the cpu in top. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110205/3d2565ab/attachment.pgp>
Remote usage script updated
On Thu, 27 Jan 2011, Jesse Rosenthal wrote:
> Dear all,
>
> Just a note to say that I finally got around to updating the remote
> usage script on the wiki to what I'm using now. With "--format=raw" in,
> it's all pretty straightforward.
Hi Jesse,
thanks for this. I wanted to do this since the --format=raw was merged,
but didn't find the time for it. I have a few comments:
> The only things the script does now are:
>
> 1. Produces a slight pause in the "notmuch show" output to avoid that
>weird bug where emacs leaves off every tenth message or so.
I added a comment to the script to explain the sleep there. Otherwise,
people may delete the command because they think it is not needed.
> 2. Locally caches raw messages (i.e. when --format=raw) is called. This
>usually happens when getting attachments, so this is a nice way to
>avoid having to download large attachments repeatedly.
This is a good idea.
>Note this just caches based on msg-id (or a hash thereof, to avoid
>strange characters in file names). That means that if an attachment
>is deleted on the server, the cache will be out of date. An easy way
>to fix this would be to make the cache file name a concatenation of
>the msg-id hash (check that first) and the hash of the actual message
>(check that if the msg-id hash is there). I might put this in in the
>future, especially if anyone else is using the script.
>
> 3. Escapes dollar signs in the msg-id to make shell-quoting over ssh
>work.
I think that quoting with
printf -v args "%q " "$@"
instead of sed would work more reliably (see bash(1)).
> I've actually switched over to keeping my messages on my IMAP server and
> using this remote script on all of my computers. It avoids any need for
> syncing. It's been working very well for me so far.
>
> A future feature might be to integrate the ControlMaster feature of
> openssh into the script, instead of having to open a connection
> manually, but there are some complications there (dead sockets still
> around if you go offline, etc.).
In another project I worked around the dead sockets this way:
sshgw() {
local socket="$HOME/.ssh/cangw-connection"
if [[ ! -S $socket ]] || ! ssh -x -a -S $socket root at 192.168.2.3 true;
then
# Create master connection to speed up subsequent commands.
ssh -N -f -M -S $socket root at 192.168.2.3 >/dev/null 2>&1
fi
ssh -x -a -S $socket root at 192.168.2.3 "$@"
}
I guess this should work even for notmuch.
-Michal
Re: new crypto branch providing full PGP/MIME support
On Fri, 04 Feb 2011 09:32:23 -0800, Jameson Rollins jroll...@finestructure.net wrote: Yeah, I've found some emails that are doing this as well. I'm looking in to what we can do to mitigate the problem, which I think is ultimately a problem in GMime. The json output should not be breaking, though, so that I will definitely fix. I pulled your latest updates to the crypto branch (I can reply to encrypted mails without resorting to Gnus! W00t!) and have noticed that I'm not seeing the json eof anymore, but if I grab the keys for the various folks in this thread as a test (Micah seems to be signing with an expired key?) then emacs just hangs when trying to produce the notmuch-show buffer. I can actually see the notmuch show process pegging the cpu in top. pgp3ZjZRCg0WX.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: search conditions on siblings/parent/children in thread
On Mon, 31 Jan 2011, Gregor Kappler wrote: I am using notmuch for my mail and also for mailing lists. For mailing lists it would be much more convenient to have a saved search displaying only replies to watched (say, tag:flagged) posts instead of the whole list. Hi Gregor, AFAIK this is not possible. I customized notmuch-search-line-faces to highlight threads with flagged messages by different background color. In the search window I still see the whole list, but the interesting threads are highlighted so I can act on them differently. I did not find any way in notmuch to specify conditions on sibling/parent/children posts in a post's thread during search. Does anybody use those searches? Are there plans to include this feature? There were some discussions about these kinds of searches but no patches have been posted. Sure, this feature would be very welcomed by me! Is there demand of other users? If this is currently not possible, I do not know whether it is feasable with xapian: can xapian this kind of search and how it would perform. I think that this kind of queries could be directly performed by Xapian only if database schema is changed. However, we could probably implement them directly in notmuch at the place where the list of the threads is constructed. Custom query parser patches (sent recently by Austin Clements) could probably help in this regard. Cheers, Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Shell programming: directories are ``executable'' (that is, searchable), too.
On Wed, 02 Feb 2011, Thomas Schwinge wrote:
Signed-off-by: Thomas Schwinge tho...@schwinge.name
---
test/test-lib.sh |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index f536172..3471ead 100755
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -815,13 +815,14 @@ EOF
}
+# Locate the directory containing the `notmuch' executable we are to use.
find_notmuch_path ()
{
dir=$1
while [ -n $dir ]; do
bin=$dir/notmuch
- if [ -x $bin ]; then
+ if [ -f $bin -a -x $bin ]; then
Looks good to me. Thanks.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Have --format=mbox insert Status:
On Wed, 02 Feb 2011, Peter John Hartman wrote:
Hi folks,
This is not a complete patch, but should give you an idea. (It works well
enough for me, but I think it could do more).
diff --git a/notmuch-show.c b/notmuch-show.c
index ef421ec..dff66de 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -272,6 +272,12 @@ format_message_mbox (const void *ctx,
printf (From %s %s, from, date_asctime);
+if (strstr(_get_tags_as_string(ctx,message),unread) != NULL) {
+ printf (Status: O\n);
+} else {
+ printf (Status: RO\n);
+}
+
Hi Peter,
would this output be compatible with all mbox consumers or only with
those who expect the Status: line? If the latter, we would probably want
a command line option to enable this.
For instance, I combine notmuch with mutt as follows:
notmuch show --format=mbox $(notmuch search thread:xxx | cut -d' ' -f1)
tmp.mbox mutt -f tmp.mbox rm -f tmp.mbox
Interesting :)
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Remote usage script updated
On Sat, 05 Feb 2011, Michal Sojka wrote:
On Thu, 27 Jan 2011, Jesse Rosenthal wrote:
A future feature might be to integrate the ControlMaster feature of
openssh into the script, instead of having to open a connection
manually, but there are some complications there (dead sockets still
around if you go offline, etc.).
In another project I worked around the dead sockets this way:
sshgw() {
local socket=$HOME/.ssh/cangw-connection
if [[ ! -S $socket ]] || ! ssh -x -a -S $socket root@192.168.2.3 true;
then
# Create master connection to speed up subsequent commands.
ssh -N -f -M -S $socket root@192.168.2.3 /dev/null 21
fi
ssh -x -a -S $socket root@192.168.2.3 $@
}
Hmm, this code worked well with dropbear ssh server but it seems that
with openssh server the result is not that good. Namely, if the master
connection is dead, the command running true blocked for a long time. I
have always killed it before it timed out so I don't know whether it
blocks indefinitely or there is only long timeout.
I may look at this later, but I use notmuch remotely only from time to
time so this is not priority for me.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
