Change duplicate priority?

Dear All, My work email comes through an Outlook server, which scans some attachments. The process seems to be to first post an email with an "Advanced Threat Protection" message and a link to a preview of the attachment. Then, after the scan is complete, to delete that message and post a second m

[PATCH v3 2/2] lib: Use email address instead of empty real name.

the search results instead. Signed-off-by: Jesse Rosenthal --- lib/thread.cc | 3 ++- test/T205-author-naming.sh | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/thread.cc b/lib/thread.cc index 8922403..79c3e9b 100644 --- a/lib/thread.cc +++ b/lib/thread.cc

[PATCH v3 1/2] test: Add known-broken test for empty author name

eem to fit well in any of our existing tests. Signed-off-by: Jesse Rosenthal --- test/T205-author-naming.sh | 13 + 1 file changed, 13 insertions(+) create mode 100755 test/T205-author-naming.sh diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh new file mode 10075

[PATCH v3 0/2] Use email address instead of empty real name.

-email-jrosenthal at jhu.edu Jesse Rosenthal (2): test: Add known-broken test for empty author name lib: Use email address instead of empty real name. lib/thread.cc | 3 ++- test/T205-author-naming.sh | 12 2 files changed, 14 insertions(+), 1 deletion(-) create mode

[PATCH v3 2/2] lib: Use email address instead of empty real name.

the search results instead. Signed-off-by: Jesse Rosenthal --- lib/thread.cc | 3 ++- test/T205-author-naming.sh | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/thread.cc b/lib/thread.cc index 8922403..79c3e9b 100644 --- a/lib/thread.cc +++ b/lib/thread.cc

[PATCH v3 0/2] Use email address instead of empty real name.

-email-jrosent...@jhu.edu Jesse Rosenthal (2): test: Add known-broken test for empty author name lib: Use email address instead of empty real name. lib/thread.cc | 3 ++- test/T205-author-naming.sh | 12 2 files changed, 14 insertions(+), 1 deletion(-) create mode

[PATCH v3 1/2] test: Add known-broken test for empty author name

eem to fit well in any of our existing tests. Signed-off-by: Jesse Rosenthal --- test/T205-author-naming.sh | 13 + 1 file changed, 13 insertions(+) create mode 100755 test/T205-author-naming.sh diff --git a/test/T205-author-naming.sh b/test/T205-author-naming.sh new file mode 10075

[PATCH v2 2/2] test: Add test for correct naming of author.

This is a new test file, since handling of unusual email addresses doesn't seem to fit well in any of our existing tests. Signed-off-by: Jesse Rosenthal --- test/T205-author-naming.sh | 12 1 file changed, 12 insertions(+) create mode 100755 test/T205-author-naming.sh diff

[PATCH v2 1/2] lib: Use email address instead of empty real name.

the search results instead. Signed-off-by: Jesse Rosenthal --- lib/thread.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/thread.cc b/lib/thread.cc index 8922403..68b2b94 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -277,7 +277,8 @@ _thread_add_message (notmuc

[PATCH v2 0/2] Use email address instead of empty real name.

Apologies. A git (-user) malfunction in v1 accidentally sent the whole mbox as one patch. These are the correct patches. Jesse Rosenthal (2): lib: Use email address instead of empty real name. test: Add test for correct naming of author. lib/thread.cc | 3 ++- test/T205-author

[PATCH 1/2] lib: Use email address instead of empty real name.

the search results instead. Signed-off-by: Jesse Rosenthal --- lib/thread.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/thread.cc b/lib/thread.cc index 8922403..68b2b94 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -277,7 +277,8 @@ _thread_add_message (notmuc

[PATCH v2 0/2] Use email address instead of empty real name.

Apologies. A git (-user) malfunction in v1 accidentally sent the whole mbox as one patch. These are the correct patches. Jesse Rosenthal (2): lib: Use email address instead of empty real name. test: Add test for correct naming of author. lib/thread.cc | 3 ++- test/T205-author

[PATCH v2 2/2] test: Add test for correct naming of author.

This is a new test file, since handling of unusual email addresses doesn't seem to fit well in any of our existing tests. Signed-off-by: Jesse Rosenthal --- test/T205-author-naming.sh | 12 1 file changed, 12 insertions(+) create mode 100755 test/T205-author-naming.sh diff

[PATCH v2 1/2] lib: Use email address instead of empty real name.

the search results instead. Signed-off-by: Jesse Rosenthal --- lib/thread.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/thread.cc b/lib/thread.cc index 8922403..68b2b94 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -277,7 +277,8 @@ _thread_add_message (notmuc

[PATCH 1/2] lib: Use email address instead of empty real name.

the search results instead. Signed-off-by: Jesse Rosenthal --- lib/thread.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/thread.cc b/lib/thread.cc index 8922403..68b2b94 100644 --- a/lib/thread.cc +++ b/lib/thread.cc @@ -277,7 +277,8 @@ _thread_add_message (notmuc

[PATCH] test: Make gen-threads work with python3

"W. Trevor King" writes: > On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote: >> We instead initalize the dictionary using the dict comprehension and >> then update it with the values from the tree. This will work with >> both python2 and python3. >

[PATCH] test: Make gen-threads work with python3

python3 doesn't allow dictionaries to be initialized with non-string keywords. This presents problems on systems in which "python" means "python3". We instead initalize the dictionary using the dict comprehension and then update it with the values from the tree. This will work with both python2 and

Re: [PATCH] test: Make gen-threads work with python3

"W. Trevor King" writes: > On Fri, Oct 31, 2014 at 01:33:25PM -0400, Jesse Rosenthal wrote: >> We instead initalize the dictionary using the dict comprehension and >> then update it with the values from the tree. This will work with >> both python2 and python3. >

[PATCH v5 0/7] notmuch search --output=sender/recipients

Dear Michal, Thanks for all this. The feature looks great! One issue: I'm getting corrupt output when using `--output=count` with "fold" filters: ~~~ jkr at ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count "tag:notmuch and date:today.." 2 Jani Nikula 2 Michal

[PATCH] test: Make gen-threads work with python3

python3 doesn't allow dictionaries to be initialized with non-string keywords. This presents problems on systems in which "python" means "python3". We instead initalize the dictionary using the dict comprehension and then update it with the values from the tree. This will work with both python2 and

Re: [PATCH v5 0/7] notmuch search --output=sender/recipients

Dear Michal, Thanks for all this. The feature looks great! One issue: I'm getting corrupt output when using `--output=count` with "fold" filters: ~~~ jkr@ladybug [11:01AM] ~ $ notmuch search --output=recipients --output=count "tag:notmuch and date:today.." 2 Jani Nikula 2 Michal So

[v2 3/3] thread-naming test: Test empty subject names.

We test all empty subjects, and then empty subjects followed by non-empty subjects (searching both oldest- and newest-first). --- test/T200-thread-naming.sh | 32 1 file changed, 32 insertions(+) diff --git a/test/T200-thread-naming.sh b/test/T200-thread-naming.sh

[v2 2/3] test-lib: Add dummy subject to force empty subject

At the moment, the test-lib fills in any missing headers. This makes it impossible to test our handling of empty subjects. This will allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force the subject to remain empty. --- test/test-lib.sh | 2 ++ 1 file changed, 2 insertions(+) diff

[v2 1/3] thread.cc: Avoid empty thread names if possible.

Currently the thread is named based on either the oldest or newest matching message (depending on the search order). If this message has an empty subject, though, the thread will show up with an empty subject in the search results. (See the thread starting with `id:1412371140-21051-1-git-send-email

[v2 0/3] Avoid empty thread names if possible

uite to accept a non-empty header. I called the dummy subject `@FORCE_EMPTY` to differentiate from a normal string, but not invoke any special shell-ness. Jesse Rosenthal (3): thread.cc: Avoid empty thread names if possible. test-lib: Add dummy subject to force empty subject thre

[v2 0/3] Avoid empty thread names if possible

uite to accept a non-empty header. I called the dummy subject `@FORCE_EMPTY` to differentiate from a normal string, but not invoke any special shell-ness. Jesse Rosenthal (3): thread.cc: Avoid empty thread names if possible. test-lib: Add dummy subject to force empty subject thre

[v2 2/3] test-lib: Add dummy subject to force empty subject

At the moment, the test-lib fills in any missing headers. This makes it impossible to test our handling of empty subjects. This will allow us to use a special dummy subject -- `@FORCE_EMPTY` -- to force the subject to remain empty. --- test/test-lib.sh | 2 ++ 1 file changed, 2 insertions(+) diff

[v2 1/3] thread.cc: Avoid empty thread names if possible.

Currently the thread is named based on either the oldest or newest matching message (depending on the search order). If this message has an empty subject, though, the thread will show up with an empty subject in the search results. (See the thread starting with `id:1412371140-21051-1-git-send-email

[v2 3/3] thread-naming test: Test empty subject names.

We test all empty subjects, and then empty subjects followed by non-empty subjects (searching both oldest- and newest-first). --- test/T200-thread-naming.sh | 32 1 file changed, 32 insertions(+) diff --git a/test/T200-thread-naming.sh b/test/T200-thread-naming.sh

[PATCH] Avoid empty thread names if possible.

[I'm not sure why the below reply did not go to the list. Later replies did, so I assume there must have been so problem in the sending. Mark, apologies if you get this twice.] Hi, Thanks for taking a look at this. Mark Walters writes: > I approve of the change in the output but I am unsure abo

[PATCH] Avoid empty thread names if possible.

Hmm, that's strange -- my inital detailed response to Mark's message didn't go through to the list. I wonder if it's being filtered or something.

[PATCH] Avoid empty thread names if possible.

Thanks for taking a look. Tomi Ollila writes: > IMO it is a bit silly to scan through the whole string and use the return > value of 0 (vs != 0) to have effect. we should probably have something like > #define EMPTY_STRING(s) ((s)[0] == '\0') > and use that instead. Good point. Will put in the

[PATCH] Avoid empty thread names if possible.

By the way, this discussion brings up another problem. I wasn't able to write a test for this (to address the below concerns) because the test suite for thread-naming supplies some sort of auto-generated subject for threads with empty subjects. So we can't test behavior for dealing with empty subje

[PATCH] Avoid empty thread names if possible.

Hi, Thanks for taking a look at this. Mark Walters writes: > I approve of the change in the output but I am unsure about the > implementation. It would be nice to have a clear rule about which > subject is taken. Eg: > > if sort is oldest first then it is the subject of the oldest >

Re: [PATCH] Avoid empty thread names if possible.

Hi, Thanks for taking a look at this. Mark Walters writes: > I approve of the change in the output but I am unsure about the > implementation. It would be nice to have a clear rule about which > subject is taken. Eg: > > if sort is oldest first then it is the subject of the oldest >

Re: [PATCH] Avoid empty thread names if possible.

[I'm not sure why the below reply did not go to the list. Later replies did, so I assume there must have been so problem in the sending. Mark, apologies if you get this twice.] Hi, Thanks for taking a look at this. Mark Walters writes: > I approve of the change in the output but I am unsure abo

Re: [PATCH] Avoid empty thread names if possible.

Hmm, that's strange -- my inital detailed response to Mark's message didn't go through to the list. I wonder if it's being filtered or something. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Avoid empty thread names if possible.

Thanks for taking a look. Tomi Ollila writes: > IMO it is a bit silly to scan through the whole string and use the return > value of 0 (vs != 0) to have effect. we should probably have something like > #define EMPTY_STRING(s) ((s)[0] == '\0') > and use that instead. Good point. Will put in the

Re: [PATCH] Avoid empty thread names if possible.

By the way, this discussion brings up another problem. I wasn't able to write a test for this (to address the below concerns) because the test suite for thread-naming supplies some sort of auto-generated subject for threads with empty subjects. So we can't test behavior for dealing with empty subje

[PATCH] Avoid empty thread names if possible.

-email-david at tethera.net` for an example.) This patch changes the behavior to name based on the oldest/newest matching non-empty subject. This is particularly helpful for patchsets. If the only subjects are empty, the thread subject will still be empty. Signed-off-by: Jesse Rosenthal --- lib

[PATCH] Avoid empty thread names if possible.

-email-da...@tethera.net` for an example.) This patch changes the behavior to name based on the oldest/newest matching non-empty subject. This is particularly helpful for patchsets. If the only subjects are empty, the thread subject will still be empty. Signed-off-by: Jesse Rosenthal --- lib

RFC: notmuch-cache.el: simple caching of MIME parts

Hi David, David Edmondson writes: > ...here is a very simple filesystem based cache of MIME parts for > notmuch. It's integrated using defadvice for now, but a cleaner > approach is obviously possible. Just to say that this is great, and very much appreciated. There are some threads I avoided o

Re: RFC: notmuch-cache.el: simple caching of MIME parts

Hi David, David Edmondson writes: > ...here is a very simple filesystem based cache of MIME parts for > notmuch. It's integrated using defadvice for now, but a cleaner > approach is obviously possible. Just to say that this is great, and very much appreciated. There are some threads I avoided o

notmuch-lib questions and observations

Tomi Valkeinen writes: > I think I wasn't very clear on what I meant. I was thinking about the > behavior that graphical mail clients have: they periodically refresh the > emails, showing new ones if there are any, and they'll show some icon or > such which tells the user this email is "new" (whi

Re: notmuch-lib questions and observations

Tomi Valkeinen writes: > I think I wasn't very clear on what I meant. I was thinking about the > behavior that graphical mail clients have: they periodically refresh the > emails, showing new ones if there are any, and they'll show some icon or > such which tells the user this email is "new" (whi

Getting the right root mail of the thread

Jani Nikula writes: > I think it's actually worse than what your example demonstrates. It's > the subject of the newest/oldest *matching* message that gets used. In > your example, the first/last messages in the thread apparently match > your query. The behavior is there because subjects frequent

Re: Getting the right root mail of the thread

Jani Nikula writes: > I think it's actually worse than what your example demonstrates. It's > the subject of the newest/oldest *matching* message that gets used. In > your example, the first/last messages in the thread apparently match > your query. The behavior is there because subjects frequent

[PATCH] Restore original keybinding ('r' = reply-to-all)

On Wed, 27 Jun 2012, David Bremner wrote: > My bias is probably apparent in that I pushed the original patch... And mine in that the first thing I did in my .emacs, back in 2009 or so, was write a reply-to-sender function, and reverse the behavior. In fact, I just got around to using the built-in

Re: [PATCH] Restore original keybinding ('r' = reply-to-all)

On Wed, 27 Jun 2012, David Bremner wrote: > My bias is probably apparent in that I pushed the original patch... And mine in that the first thing I did in my .emacs, back in 2009 or so, was write a reply-to-sender function, and reverse the behavior. In fact, I just got around to using the built-in

[PATCHv2] emacs: derive correct timestamp in FCC unique name

e original intention here as well, we might as well. Signed-off-by: Jesse Rosenthal --- emacs/notmuch-maildir-fcc.el |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index dcfbc4b..07eedba 100644 --- a/emacs/notmu

[PATCH] emacs: derive correct timestamp in FCC unique name

Hi, thanks for thinking this through. On Thu, 14 Jun 2012, Tomi Ollila wrote: > Alternatives: > > 1) Use current patch, filenames will have extra '-' in 2038 on 32-bit > systems. Well, that assumes there is still the same arithmetic operations -- the calendar issue will probably push them to e

[PATCHv2] emacs: derive correct timestamp in FCC unique name

e original intention here as well, we might as well. Signed-off-by: Jesse Rosenthal --- emacs/notmuch-maildir-fcc.el |7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index dcfbc4b..07eedba 100644 --- a/emacs/notmu

Re: [PATCH] emacs: derive correct timestamp in FCC unique name

Hi, thanks for thinking this through. On Thu, 14 Jun 2012, Tomi Ollila wrote: > Alternatives: > > 1) Use current patch, filenames will have extra '-' in 2038 on 32-bit > systems. Well, that assumes there is still the same arithmetic operations -- the calendar issue will probably push them to e

[PATCH] emacs: derive correct timestamp in FCC unique name

an integer.) This change is mostly a question of consistency, since the unique name is arbitrary anyway. But since most people use timestamps, and that was the original intention here as well, we might as well. Signed-off-by: Jesse Rosenthal --- emacs/notmuch-maildir-fcc.el |2 +- 1 file

[PATCH] emacs: derive correct timestamp in FCC unique name

an integer.) This change is mostly a question of consistency, since the unique name is arbitrary anyway. But since most people use timestamps, and that was the original intention here as well, we might as well. Signed-off-by: Jesse Rosenthal --- emacs/notmuch-maildir-fcc.el |2 +- 1 file

[RFC] Smart replying

Dear All, I know that folks recently got done haggling over reply bindings, but there's something I've been using for a little while, and I was curious about whether it's something people would be interested in. Forgive me if this functionality was already discussed and I missed it. The problem i

[RFC] Smart replying

Dear All, I know that folks recently got done haggling over reply bindings, but there's something I've been using for a little while, and I was curious about whether it's something people would be interested in. Forgive me if this functionality was already discussed and I missed it. The problem i

Replacing my name/email with "me" (or similar) in author lists

On Wed, 29 Feb 2012 17:47:46 -0500, Austin Clements wrote: > > On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements > > wrote: > > > What if the output of search (say, specifically the JSON format) > > > included information on each message in the thread such as the > > > 'message' production fro

Re: Replacing my name/email with "me" (or similar) in author lists

On Wed, 29 Feb 2012 17:47:46 -0500, Austin Clements wrote: > > On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements > > wrote: > > > What if the output of search (say, specifically the JSON format) > > > included information on each message in the thread such as the > > > 'message' production fro

Replacing my name/email with "me" (or similar) in author lists

On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements wrote: > What if the output of search (say, specifically the JSON format) > included information on each message in the thread such as the > 'message' production from devel/schemata minus the body field? Then > the frontend would have loads of i

Replacing my name/email with "me" (or similar) in author lists

On Sun, 26 Feb 2012 16:59:53 -0500, Tom Prince wrote: > It is probably overkill for any one feature, but it does seem like > something useful to have. So maybe it would be worthwhile to create > for this one feature, even it it is overkill. I can think of other features where some layer like thi

Re: Replacing my name/email with "me" (or similar) in author lists

On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements wrote: > What if the output of search (say, specifically the JSON format) > included information on each message in the thread such as the > 'message' production from devel/schemata minus the body field? Then > the frontend would have loads of i

Re: Replacing my name/email with "me" (or similar) in author lists

On Sun, 26 Feb 2012 16:59:53 -0500, Tom Prince wrote: > It is probably overkill for any one feature, but it does seem like > something useful to have. So maybe it would be worthwhile to create > for this one feature, even it it is overkill. I can think of other features where some layer like this

nomuch_addresses.py

On Tue, 21 Feb 2012 14:53:06 +0100, Daniel Schoepe wrote: > On Tue, 21 Feb 2012 09:15:09 -, Justus Winter <4winter at > informatik.uni-hamburg.de> wrote: > The reason I mentioned nottoomuch-addresses at all, is that completion > itself is _a lot_ faster (at least for me), compared to > addrl

Re: nomuch_addresses.py

On Tue, 21 Feb 2012 14:53:06 +0100, Daniel Schoepe wrote: > On Tue, 21 Feb 2012 09:15:09 -, Justus Winter > <4win...@informatik.uni-hamburg.de> wrote: > The reason I mentioned nottoomuch-addresses at all, is that completion > itself is _a lot_ faster (at least for me), compared to > addrlooku

nomuch_addresses.py

On Thu, 16 Feb 2012 14:51:59 -0500, Philippe LeCavalier wrote: > $ ~/notmuch/notmuch_addresses/notmuch_addresses.py > Traceback (most recent call last): > File "/home/plecavalier/notmuch/notmuch_addresses/notmuch_addresses.py", > line 19, in > import notmuch > ImportError: No module named

nomuch_addresses.py

On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier wrote: > I'm trying to setup tab completion for addresses. I appeared to me that > the simplest solution was notmuch_addresses so I grabbed a copy from > git. When I hit tab I get this[1] Was I suppose to do something more? ... > ref. > [1] >

Re: nomuch_addresses.py

On Thu, 16 Feb 2012 14:51:59 -0500, Philippe LeCavalier wrote: > $ ~/notmuch/notmuch_addresses/notmuch_addresses.py > Traceback (most recent call last): > File "/home/plecavalier/notmuch/notmuch_addresses/notmuch_addresses.py", > line 19, in > import notmuch > ImportError: No module named

Re: nomuch_addresses.py

On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier wrote: > I'm trying to setup tab completion for addresses. I appeared to me that > the simplest solution was notmuch_addresses so I grabbed a copy from > git. When I hit tab I get this[1] Was I suppose to do something more? ... > ref. > [1]

newbie questions

On Mon, 06 Feb 2012 08:51:15 +0200, Tomi Ollila wrote: > On Fri, 3 Feb 2012 12:59:34 +0100, Tamas Papp wrote: > > > > 1. How can I restrict searches (eg of my inbox) to the last few > > messages (eg 50-100) or some date (eg last 2 weeks)? I am using the > > Emacs interface. > > Currently, if y

Re: newbie questions

On Mon, 06 Feb 2012 08:51:15 +0200, Tomi Ollila wrote: > On Fri, 3 Feb 2012 12:59:34 +0100, Tamas Papp wrote: > > > > 1. How can I restrict searches (eg of my inbox) to the last few > > messages (eg 50-100) or some date (eg last 2 weeks)? I am using the > > Emacs interface. > > Currently, if y

tach.el: an attachment interface for message mode.

Hi Xavier, On Fri, 20 Jan 2012 23:43:01 +0100, Xavier Maillard wrote: > I like it. Thanks for giving it a try. > Simple but at first it is not easy to understand what to do with that > window. Also, there is no way to toggle the window visibility. But for a > first shot, it is a good shot :D

Re: tach.el: an attachment interface for message mode.

Hi Xavier, On Fri, 20 Jan 2012 23:43:01 +0100, Xavier Maillard wrote: > I like it. Thanks for giving it a try. > Simple but at first it is not easy to understand what to do with that > window. Also, there is no way to toggle the window visibility. But for a > first shot, it is a good shot :D T

tach.el: an attachment interface for message mode.

Dear All, I sent this to the list a couple of years back, but now that things are moving again, and there are new eyes on the list, I thought I'd send it again. I believe I'm the only person to use this (and might well continue to be so) but I've been using it for a couple of years without any pro

tach.el: an attachment interface for message mode.

Dear All, I sent this to the list a couple of years back, but now that things are moving again, and there are new eyes on the list, I thought I'd send it again. I believe I'm the only person to use this (and might well continue to be so) but I've been using it for a couple of years without any pro

Updated remote script

Hi Tomi, On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila wrote: > Quick comments: "/tmp/notmuch_dtach.socket" is dangerous (and the _ssh). > > either > make directory /tmp/notmuch_`id -u` > and chmod it to 0700 > and make sure you own it and it has right permissions. > or

Re: Updated remote script

Hi Tomi, On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila wrote: > Quick comments: "/tmp/notmuch_dtach.socket" is dangerous (and the _ssh). > > either > make directory /tmp/notmuch_`id -u` > and chmod it to 0700 > and make sure you own it and it has right permissions. > or

Updated remote script

Dear all, Just wanted to note that I finally got around to updating the way-deprecated "remoteusage" wiki page[0], with a simplified script, that takes into account comments that some have made in the past. Caching for attachments is gone, since the complications of part handling vs. raw handling

Updated remote script

Dear all, Just wanted to note that I finally got around to updating the way-deprecated "remoteusage" wiki page[0], with a simplified script, that takes into account comments that some have made in the past. Caching for attachments is gone, since the complications of part handling vs. raw handling

Re: [PATCH] Perform mail polling asynchronously

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson wrote: > On Mon, 5 Sep 2011 07:14:36 +0300, Antono Vasiljev wrote: > > If the poll script runs asynchronously, won't the notmuch-search output > refresh and jump into my face when I'm busy doing something else? And, > if I'm not busy doing some

[PATCH] Perform mail polling asynchronously

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson wrote: > On Mon, 5 Sep 2011 07:14:36 +0300, Antono Vasiljev > wrote: > > If the poll script runs asynchronously, won't the notmuch-search output > refresh and jump into my face when I'm busy doing something else? And, > if I'm not busy doing s

[PATCH] notmuch-addresses: Match on the full name as well as components.

Oh, and I moved the code to http://commonmeasure.org/~jkr/notmuch_addresses.git Best, Jesse On Fri, 30 Dec 2011 14:04:43 -0500, Jesse Rosenthal wrote: > Pushed. > > Thanks, > Jesse > > On Wed, 21 Dec 2011 13:49:17 +, David Edmondson wrote: > > --- > >

[PATCH] notmuch-addresses: Match on the full name as well as components.

Pushed. Thanks, Jesse On Wed, 21 Dec 2011 13:49:17 +, David Edmondson wrote: > --- > notmuch_addresses.py |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/notmuch_addresses.py b/notmuch_addresses.py > index bf45151..74a743c 100755 > --- a/notmuch_addresse

Re: [PATCH] notmuch-addresses: Match on the full name as well as components.

Oh, and I moved the code to http://commonmeasure.org/~jkr/notmuch_addresses.git Best, Jesse On Fri, 30 Dec 2011 14:04:43 -0500, Jesse Rosenthal wrote: > Pushed. > > Thanks, > Jesse > > On Wed, 21 Dec 2011 13:49:17 +, David Edmondson wrote: > > --- > >

Re: [PATCH] notmuch-addresses: Match on the full name as well as components.

Pushed. Thanks, Jesse On Wed, 21 Dec 2011 13:49:17 +, David Edmondson wrote: > --- > notmuch_addresses.py |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/notmuch_addresses.py b/notmuch_addresses.py > index bf45151..74a743c 100755 > --- a/notmuch_addresse

Re: remote-notmuch.sh

Hi Tomi, > If this proves to be working better in other users use then I can > update the script on the remoteusage page also. I actually wrote the original script, and updated it as I changed it, without much sense for who, if anyone, was using it. Please feel free to update the version on the o

remote-notmuch.sh

Hi Tomi, > If this proves to be working better in other users use then I can > update the script on the remoteusage page also. I actually wrote the original script, and updated it as I changed it, without much sense for who, if anyone, was using it. Please feel free to update the version on the o

tag sharing

On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal wrote: > What's the value added over just keeping a (compressed?) collection of > diffs for each namespace? Okay -- please don't bother answering this part. It was early in the morning, and I forgot some of the obvious ad

tag sharing

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner wrote: Non-text part: multipart/signed > On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal > wrote: > > morning's project. In retrospect, I think the main issue was that I was > > trying to figure out how history woul

output file argument to notmuch dump.

On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > 1) just delete the output file option from notmuch-dump, and use shell >redirection. So far I don't see a non-contrived example when writing >an output file directly is useful, but maybe that is just a failure >of imagination.

Re: tag sharing

On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal wrote: > What's the value added over just keeping a (compressed?) collection of > diffs for each namespace? Okay -- please don't bother answering this part. It was early in the morning, and I forgot some of the obvious ad

Re: tag sharing

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner wrote: Non-text part: multipart/signed > On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal > wrote: > > morning's project. In retrospect, I think the main issue was that I was > > trying to figure out how history woul

Re: output file argument to notmuch dump.

On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > 1) just delete the output file option from notmuch-dump, and use shell >redirection. So far I don't see a non-contrived example when writing >an output file directly is useful, but maybe that is just a failure >of imagination.

tag sharing

On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner wrote: > What doesn't work is searches for the whole namespace "notmuch search > tag:bremner.*" will return nothing, even though "notmuch search > tag:bremner.to-fix" does. A simple shell way to do this would be notmuch search-tags | grep "^b

tag sharing

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner wrote: > something like that sounds plausible. Currently the query parser doesn't > handle searches like "tag:bremner/to-fix" very well, because it > helpfully splits at '/' (aiui; maybe somebody else can explain it > better). "notmuch search "tag

Re: tag sharing

On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner wrote: > What doesn't work is searches for the whole namespace "notmuch search > tag:bremner.*" will return nothing, even though "notmuch search > tag:bremner.to-fix" does. A simple shell way to do this would be notmuch search-tags | grep "^b

Re: tag sharing

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner wrote: > something like that sounds plausible. Currently the query parser doesn't > handle searches like "tag:bremner/to-fix" very well, because it > helpfully splits at '/' (aiui; maybe somebody else can explain it > better). "notmuch search "tag

tag sharing

On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner wrote: > Jesse, do you remember why you decided to roll your own? Only reason I can remember (a year and a half later) of is that it seemed like the basic illustration of concept would be a saturday morning's project. In retrospect, I think the ma

Re: tag sharing

On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner wrote: > Jesse, do you remember why you decided to roll your own? Only reason I can remember (a year and a half later) of is that it seemed like the basic illustration of concept would be a saturday morning's project. In retrospect, I think the ma

tag sharing [was: Re: release-candidate/0.6 redux]

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins wrote: > Did you guys try to address the issue of tag removal at all? I've been > trying to decide if this is something we need to worry about or not. > For instance, if cworth pushed a tag ".needs-review", you would probably > want to hav

  1   2   3   >