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

[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

o 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 100755 ind

[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 1/2] test: Add known-broken test for empty author name

seem to fit well in any of our existing tests. Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu --- 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

[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 2/2] lib: Use email address instead of empty real name.

will be used in the search results instead. Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu --- 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

[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 --git

[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 1/2] lib: Use email address instead of empty real name.

will be used in the search results instead. Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu --- 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

[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 jrosent...@jhu.edu --- test/T205-author-naming.sh | 12 1 file changed, 12 insertions(+) create mode 100755 test/T205-author

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

will be used in the search results instead. Signed-off-by: Jesse Rosenthal jrosent...@jhu.edu --- 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

[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] 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

[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

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 j...@nikula.org 2

[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 wk...@tremily.us 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. Dict comprehensions

[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

[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(+)

[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

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

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 thread-naming

[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

[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

[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

[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.

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

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

Thanks for taking a look. Tomi Ollila tomi.oll...@iki.fi 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.

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 markwalters1...@gmail.com writes: I approve of the change in the

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

Hi, Thanks for taking a look at this. Mark Walters markwalters1...@gmail.com 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

[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

[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(+)

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

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 thread-naming test: Test

[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

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

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

Hi David, David Edmondson d...@dme.org 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

[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 jrosent...@jhu.edu

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"

Re: notmuch-lib questions and observations

Tomi Valkeinen tomi.valkei...@iki.fi 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

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

Re: Getting the right root mail of the thread

Jani Nikula j...@nikula.org 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

[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

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

On Wed, 27 Jun 2012, David Bremner da...@tethera.net 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

[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

[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

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

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

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

[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

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

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

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

On Sun, 26 Feb 2012 16:59:53 -0500, Tom Prince tom.pri...@ualberta.net 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

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

On Wed, 29 Feb 2012 10:36:57 -0500, Austin Clements amdra...@mit.edu 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

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 >

Re: nomuch_addresses.py

On Tue, 21 Feb 2012 14:53:06 +0100, Daniel Schoepe dan...@schoepe.org 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

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:12:36 -0500, Philippe LeCavalier supp...@plecavalier.com 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

Re: nomuch_addresses.py

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

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

Re: newbie questions

On Mon, 06 Feb 2012 08:51:15 +0200, Tomi Ollila tomi.oll...@iki.fi wrote: On Fri, 3 Feb 2012 12:59:34 +0100, Tamas Papp tkp...@gmail.com 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

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

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

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

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

Hi Xavier, On Fri, 20 Jan 2012 23:43:01 +0100, Xavier Maillard xav...@maillard.im 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

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. >

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

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: Updated remote script

Hi Tomi, On Thu, 19 Jan 2012 19:50:38 +0200, Tomi Ollila tomi.oll...@iki.fi 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

[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

Re: [PATCH] Perform mail polling asynchronously

On Tue, 03 Jan 2012 16:02:43 +, David Edmondson d...@dme.org wrote: On Mon, 5 Sep 2011 07:14:36 +0300, Antono Vasiljev s...@antono.info 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

[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 > ---

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 jrosent...@jhu.edu wrote: Pushed. Thanks, Jesse On Wed, 21 Dec 2011 13:49:17 +, David Edmondson d...@dme.org wrote

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

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

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 advantages o

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 would be

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: output file argument to notmuch dump.

On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca 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

Re: tag sharing

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

Re: tag sharing

On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal jrosent...@jhu.edu 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

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

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 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

Re: tag sharing

On Thu, 06 Oct 2011 09:56:43 -0300, David Bremner da...@tethera.net 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

Re: tag sharing

On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner da...@tethera.net 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

Re: tag sharing

On Thu, 06 Oct 2011 17:23:21 -0300, David Bremner da...@tethera.net 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

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

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

On Wed, 08 Jun 2011 10:46:57 -0700, Jameson Graef Rollins jroll...@finestructure.net 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

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

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins wrote: > I've been thinking about this more and it really seems we need a way to > just share tags. What if we had a way to export all the tags for a set > of messages as a notmuch dump file, that could just be piped into > notmuch to

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

On Mon, 06 Jun 2011 09:28:13 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: I've been thinking about this more and it really seems we need a way to just share tags. What if we had a way to export all the tags for a set of messages as a notmuch dump file, that could just be

Header and other questions

Hi, On Mon, 16 May 2011 17:15:17 +0200, Daniel Schoepe wrote: > I think this is only a subset of the requested functionality, since one > can only tag consecutive threads at once. It seems like for non-consecutive messages to be tagged, there'd have to be some sort of mutt-style

Header and other questions

On Sun, 15 May 2011 23:56:11 +0200, Xavier Maillard wrote: > On Sat, 14 May 2011 22:23:16 -0700, mueen at nawaz.org wrote: > > > 3. Can I mark a bunch of messages for tagging in the Emacs interface? I > > know I can tag all messages in a query, but sometimes I'd just like to > > select a few

Re: Header and other questions

On Sun, 15 May 2011 23:56:11 +0200, Xavier Maillard xav...@maillard.im wrote: On Sat, 14 May 2011 22:23:16 -0700, mu...@nawaz.org wrote: 3. Can I mark a bunch of messages for tagging in the Emacs interface? I know I can tag all messages in a query, but sometimes I'd just like to select a

  1   2   3   >