[notmuch] [PATCH 2/2] notmuch-show: add optional argument for query context instead of using global binding notmuch-search-query-string

[da...@tethera.net]

From: David Bremner 

Also modify the one call to notmuch-show in notmuch.el.  This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
---
 notmuch.el |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 5925907..f7048d5 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -949,15 +949,17 @@ All currently available key bindings:
  (lambda()
(hl-line-mode 1) ))

-(defun notmuch-show (thread-id &optional parent-buffer)
+(defun notmuch-show (thread-id &optional parent-buffer query-context)
   "Run \"notmuch show\" with the given thread ID and display results.

 The optional PARENT-BUFFER is the notmuch-search buffer from
 which this notmuch-show command was executed, (so that the next
-thread from that buffer can be show when done with this one)."
+thread from that buffer can be show when done with this one).
+
+The optional QUERY-CONTEXT is a notmuch search term. Only messages from the 
thread 
+matching this search term are shown if non-nil. "
   (interactive "sNotmuch show: ")
-  (let ((query notmuch-search-query-string)
-   (buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
+  (let ((buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
 (switch-to-buffer buffer)
 (notmuch-show-mode)
 (set (make-local-variable 'notmuch-show-parent-buffer) parent-buffer)
@@ -969,7 +971,9 @@ thread from that buffer can be show when done with this 
one)."
   (erase-buffer)
   (goto-char (point-min))
   (save-excursion
-   (call-process notmuch-command nil t nil "show" "--entire-thread" 
thread-id "and (" query ")")
+   (let* ((basic-args (list notmuch-command nil t nil "show" 
"--entire-thread" thread-id))
+   (args (if query-context (append basic-args (list "and (" 
query-context ")")) basic-args)))
+ (apply 'call-process args))
(notmuch-show-markup-messages)
)
   (run-hooks 'notmuch-show-hook)
@@ -1146,7 +1150,7 @@ Complete list of currently available key bindings:
   (interactive)
   (let ((thread-id (notmuch-search-find-thread-id)))
 (if (> (length thread-id) 0)
-   (notmuch-show thread-id (current-buffer))
+   (notmuch-show thread-id (current-buffer) notmuch-search-query-string)
   (error "End of search results"

 (defun notmuch-search-reply-to-thread ()
-- 
1.6.5.3

[notmuch] [PATCH 1/2] notmuch-search-process-filter: add text properties for authors and subject to each line

[da...@tethera.net]

From: David Bremner 

Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id.  These functions are just a wrapper
around get-text-property, but in principle that could change.
---
 notmuch.el |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index c504f46..5925907 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1133,6 +1133,14 @@ Complete list of currently available key bindings:
   "Return the thread for the current thread"
   (get-text-property (point) 'notmuch-search-thread-id))

+(defun notmuch-search-find-authors ()
+  "Return the authors for the current thread"
+  (get-text-property (point) 'notmuch-search-authors))
+
+(defun notmuch-search-find-subject ()
+  "Return the subject for the current thread"
+  (get-text-property (point) 'notmuch-search-subject))
+
 (defun notmuch-search-show-thread ()
   "Display the currently selected thread."
   (interactive)
@@ -1257,7 +1265,9 @@ This function advances the next thread when finished."
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
-   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id))
+   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
+   (put-text-property beg (point-marker) 
'notmuch-search-authors authors)
+   (put-text-property beg (point-marker) 
'notmuch-search-subject subject))
  (set 'line (match-end 0)))
  (set 'more nil))
   (delete-process proc
-- 
1.6.5.3

[notmuch] Patches in support of linking from org-mode

[da...@tethera.net]

These two patches are pretty much independent. The first is needed by my 
work in progress patch for org-mode to provide links into notmuch 
(http://pivot.cs.unb.ca/git/?p=org-mode.git;a=shortlog;h=refs/heads/notmuch-link).

The second changes the interface of git-show to take the query-string
recently added explicitly as a parameter. This is more an aesthetic
thing, but it means that I don't have to call notmuch-show like
(let notmuch-query-search-string thread-id
 (notmuch-show thread-id))

Hope you like em. I also hope this whole git-send-email thing works out.

David

[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Jed Brown]

On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth  wrote:

> But surely there's a way to implement this with dramatically less code
> duplication?

It should just be very short after this series

  id:1259450376-24523-1-git-send-email-jed at 59A2.org

I think --format= should not be used for this, formatting is orthogonal
to selecting recipients.

Speaking of code duplication, perhaps it is worth abstracting options
parsing (or using an existing library).

Jed

[notmuch] Notmuch's search view sucks

[Baruch Even]

Karl Wiberg wrote:
> On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth  wrote:
>> And a step beyond that would support different languages for
>> different emails, but that sounds like something "hard" to identify.
> 
> But probably not as hard as identifying spam. It could probably be
> done with a simple Bayesian filter counting word frequencies---but
> it'd be much better if somebody else had already solved the problem,
> since this smells suspiciously like something that ought to be a
> separate project and put in a library ... does anyone know if such a
> project already exists? I know Google can do it ...
> 
> It'd be very cool to have notmuch automatically tag messages according
> to what language they're in.

What we should have is an interface to run an external program to 
classify a message when it's newly introduced and another that runs when 
tags are changed so that machine learning can be made to work when the 
user changes tags.

Baruch

[notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:16:20PM -0800, Carl Worth wrote:
> On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins  finestructure.net> wrote:
> > -   install contrib/notmuch-completion.bash \
> > +   install -m0644 contrib/notmuch-completion.bash \
> > $(DESTDIR)$(bash_completion_dir)/notmuch
> 
> Thanks. I pushed this.
> 
> I didn't push the parent commit in the thread, (regarding zlib), since as
> mentioned in another reply this is actually a bug in the GMime
> pkg-config file.

Great.  That's fine with me (assuming that GMime actually gets fixed
upstream).

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/2ee667b4/attachment.pgp>

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:12:47PM -0800, Carl Worth wrote:
> Handling --prefix will be a nice addition to our configure script. So,
> thanks!

Yeah, it's definitely needed for the Debian packaging as well.

> Your commit message has that flag word of "also" in it, and as it turns
> out, the removal of Makefile.config from the repository has actually
> happened already. But that was easy enough to fix.

I was thinking that the removal of the Makefile.config from the repo
went together with the new auto-generation of that file from configure
script.  Do you think they still should have been separate patches?

> > +# option parsing
> > +for option; do
> > +if [ "${option%=*}" = '--prefix' ] ; then
> > +   PREFIX="${option#*=}"
> > +fi
> > +done
> 
> I've gone ahead and committed that now. Then I noticed that we should
> really use ${option%%=*} to support the case of an option value
> containing an '=' character. So I fixed that.

Ah, good catch.  Sorry about that.  

> Our configuration system certainly isn't as full-featured yet as a
> standard autoconf-based configure script, but I'm quite happy with how
> clean it is for both users and developers.

Autoconf terrifies me, so I agree I'm quite happy with the simple
configure script we have right now.  If it gets the job done without
having to deal with autoconf then that's great in my book.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/3bd13606/attachment.pgp>

[notmuch] [PATCH 2/2] notmuch-show: add optional argument for query context instead of using global binding notmuch-search-query-string

[david]

From: David Bremner 

Also modify the one call to notmuch-show in notmuch.el.  This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
---
 notmuch.el |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index 5925907..f7048d5 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -949,15 +949,17 @@ All currently available key bindings:
  (lambda()
(hl-line-mode 1) ))
 
-(defun notmuch-show (thread-id &optional parent-buffer)
+(defun notmuch-show (thread-id &optional parent-buffer query-context)
   "Run \"notmuch show\" with the given thread ID and display results.
 
 The optional PARENT-BUFFER is the notmuch-search buffer from
 which this notmuch-show command was executed, (so that the next
-thread from that buffer can be show when done with this one)."
+thread from that buffer can be show when done with this one).
+
+The optional QUERY-CONTEXT is a notmuch search term. Only messages from the 
thread 
+matching this search term are shown if non-nil. "
   (interactive "sNotmuch show: ")
-  (let ((query notmuch-search-query-string)
-   (buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
+  (let ((buffer (get-buffer-create (concat "*notmuch-show-" thread-id "*"
 (switch-to-buffer buffer)
 (notmuch-show-mode)
 (set (make-local-variable 'notmuch-show-parent-buffer) parent-buffer)
@@ -969,7 +971,9 @@ thread from that buffer can be show when done with this 
one)."
   (erase-buffer)
   (goto-char (point-min))
   (save-excursion
-   (call-process notmuch-command nil t nil "show" "--entire-thread" 
thread-id "and (" query ")")
+   (let* ((basic-args (list notmuch-command nil t nil "show" 
"--entire-thread" thread-id))
+   (args (if query-context (append basic-args (list "and (" 
query-context ")")) basic-args)))
+ (apply 'call-process args))
(notmuch-show-markup-messages)
)
   (run-hooks 'notmuch-show-hook)
@@ -1146,7 +1150,7 @@ Complete list of currently available key bindings:
   (interactive)
   (let ((thread-id (notmuch-search-find-thread-id)))
 (if (> (length thread-id) 0)
-   (notmuch-show thread-id (current-buffer))
+   (notmuch-show thread-id (current-buffer) notmuch-search-query-string)
   (error "End of search results"
 
 (defun notmuch-search-reply-to-thread ()
-- 
1.6.5.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 1/2] notmuch-search-process-filter: add text properties for authors and subject to each line

[david]

From: David Bremner 

Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id.  These functions are just a wrapper
around get-text-property, but in principle that could change.
---
 notmuch.el |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/notmuch.el b/notmuch.el
index c504f46..5925907 100644
--- a/notmuch.el
+++ b/notmuch.el
@@ -1133,6 +1133,14 @@ Complete list of currently available key bindings:
   "Return the thread for the current thread"
   (get-text-property (point) 'notmuch-search-thread-id))
 
+(defun notmuch-search-find-authors ()
+  "Return the authors for the current thread"
+  (get-text-property (point) 'notmuch-search-authors))
+
+(defun notmuch-search-find-subject ()
+  "Return the subject for the current thread"
+  (get-text-property (point) 'notmuch-search-subject))
+
 (defun notmuch-search-show-thread ()
   "Display the currently selected thread."
   (interactive)
@@ -1257,7 +1265,9 @@ This function advances the next thread when finished."
  (goto-char (point-max))
  (let ((beg (point-marker)))
(insert (format "%s %-7s %-40s %s (%s)\n" date count 
authors subject tags))
-   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id))
+   (put-text-property beg (point-marker) 
'notmuch-search-thread-id thread-id)
+   (put-text-property beg (point-marker) 
'notmuch-search-authors authors)
+   (put-text-property beg (point-marker) 
'notmuch-search-subject subject))
  (set 'line (match-end 0)))
  (set 'more nil))
   (delete-process proc
-- 
1.6.5.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Patches in support of linking from org-mode

[david]

These two patches are pretty much independent. The first is needed by my 
work in progress patch for org-mode to provide links into notmuch 
(http://pivot.cs.unb.ca/git/?p=org-mode.git;a=shortlog;h=refs/heads/notmuch-link).

The second changes the interface of git-show to take the query-string
recently added explicitly as a parameter. This is more an aesthetic
thing, but it means that I don't have to call notmuch-show like
(let notmuch-query-search-string thread-id
 (notmuch-show thread-id))

Hope you like em. I also hope this whole git-send-email thing works out.

David
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs UI customization

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 01:01:17PM -0500, Jameson Graef Rollins wrote:
> In general, I think it would be really good to put together some
> documentation about all the ways that users can customize the notmuch
> interface.  I would be willing to help with that as well.  It would
> also be nice to allow for customization about of things that are
> currently not that might be controversial.

So I was thinking about this a bit, and it occured to me that a great
thing to do would be to include with notmuch an example emacs
configuration file that includes examples of all (or many) of the ways
one could customize emacs for notmuch, maybe also including ways one
might want to customize the 'message' or 'MML' modes as well.  I, and
I'm sure others, would find it a very useful reference.  I'll start
putting something like this together and forward what I have to the
list.  If others are interested in doing the same, I would be thrilled
to compile what we come up with.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/1c135bf1/attachment.pgp>

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Fri, 4 Dec 2009 19:20:50 -0500, Jameson Graef Rollins 
 wrote:
> > Your commit message has that flag word of "also" in it, and as it turns
> > out, the removal of Makefile.config from the repository has actually
> > happened already. But that was easy enough to fix.
> 
> I was thinking that the removal of the Makefile.config from the repo
> went together with the new auto-generation of that file from configure
> script.  Do you think they still should have been separate patches?

No, it was fine. It's just funny to me how often that word "also" in a
commit message seems to end up being a predictor for things later, (like
this case where half of a patch is already implemented, or much worse,
how often a bisect lands on a commit that makes multiple changes).

So I was really just expressing amusement at seeing it again.

> > > +# option parsing
> > > +for option; do
> > > +if [ "${option%=*}" = '--prefix' ] ; then
> > > + PREFIX="${option#*=}"
> > > +fi
> > > +done
> > 
> > I've gone ahead and committed that now. Then I noticed that we should
> > really use ${option%%=*} to support the case of an option value
> > containing an '=' character. So I fixed that.
> 
> Ah, good catch.  Sorry about that.  

No worries. I was just impressed at the tiny amount of code needed for
the parsing here, so ended up looking closer to understand it.

> Autoconf terrifies me, so I agree I'm quite happy with the simple
> configure script we have right now.  If it gets the job done without
> having to deal with autoconf then that's great in my book.

Cool. At least not everyone thinks I'm crazy then. That's
encouraging. :-)

-Carl


pgplDoLzToHyz.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Fri, 4 Dec 2009 19:20:50 -0500, Jameson Graef Rollins  wrote:
> > Your commit message has that flag word of "also" in it, and as it turns
> > out, the removal of Makefile.config from the repository has actually
> > happened already. But that was easy enough to fix.
> 
> I was thinking that the removal of the Makefile.config from the repo
> went together with the new auto-generation of that file from configure
> script.  Do you think they still should have been separate patches?

No, it was fine. It's just funny to me how often that word "also" in a
commit message seems to end up being a predictor for things later, (like
this case where half of a patch is already implemented, or much worse,
how often a bisect lands on a commit that makes multiple changes).

So I was really just expressing amusement at seeing it again.

> > > +# option parsing
> > > +for option; do
> > > +if [ "${option%=*}" = '--prefix' ] ; then
> > > + PREFIX="${option#*=}"
> > > +fi
> > > +done
> > 
> > I've gone ahead and committed that now. Then I noticed that we should
> > really use ${option%%=*} to support the case of an option value
> > containing an '=' character. So I fixed that.
> 
> Ah, good catch.  Sorry about that.  

No worries. I was just impressed at the tiny amount of code needed for
the parsing here, so ended up looking closer to understand it.

> Autoconf terrifies me, so I agree I'm quite happy with the simple
> configure script we have right now.  If it gets the job done without
> having to deal with autoconf then that's great in my book.

Cool. At least not everyone thinks I'm crazy then. That's
encouraging. :-)

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/059a6064/attachment.pgp>

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 16:39:50 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

 CW> But when viewing an actual message, I'm still planning on having
 CW> notmuch just return an arbitrary filename from the list of
 CW> filenames associated with that message. Does anyone see any problem
 CW> with that? Can you think of a case where you'd really care about
 CW> seeing one or the other of a particular duplicated message?

There might be different Reply-To fields.

So I'd just return bigger dup, as it probably contains more information
:)

-- 
  http://fossarchy.blogspot.com/


pgpVhyQD5Jv8p.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman 
 wrote:
> Besides, in notmuch, what's the difference going to be?  It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?

There's one other point I should make here while talking about duplicate
messages, (as determined by identical Message ID).

Currently notmuch just indexes the first version of any given message it
sees, and simply ignores anything else it sees in the future.

We're planning to change it to at least save each of the filenames for
messages with multiple files. That way if some duplicates are deleted,
then notmuch will still be able to find one of the others.

Also, we could make notmuch index duplicate messages and add any
additional terms found to the document for the message. Currently, that
wouldn't make a big difference since notmuch is only indexing the body
and a few specific headers, (From, Subject, To, Cc, Bcc, Messsage-ID,
In-Reply-To, References).

So any differences there should be quite minor (a "[LIST]" prefix in
subject? an extra footer in the boday?), under the assumption that no
mail files will ever exist with the same message ID but disparate
content.

Now, we have a TODO item to allow for indexing additional headers,
(either by default or by user configuration). Once we start doing that,
it probably will make sense to at least index the duplicates.

But when viewing an actual message, I'm still planning on having notmuch
just return an arbitrary filename from the list of filenames associated
with that message. Does anyone see any problem with that? Can you think
of a case where you'd really care about seeing one or the other of
a particular duplicated message?

-Carl


pgpwMRp1Se2vY.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman  wrote:
> Besides, in notmuch, what's the difference going to be?  It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?

There's one other point I should make here while talking about duplicate
messages, (as determined by identical Message ID).

Currently notmuch just indexes the first version of any given message it
sees, and simply ignores anything else it sees in the future.

We're planning to change it to at least save each of the filenames for
messages with multiple files. That way if some duplicates are deleted,
then notmuch will still be able to find one of the others.

Also, we could make notmuch index duplicate messages and add any
additional terms found to the document for the message. Currently, that
wouldn't make a big difference since notmuch is only indexing the body
and a few specific headers, (From, Subject, To, Cc, Bcc, Messsage-ID,
In-Reply-To, References).

So any differences there should be quite minor (a "[LIST]" prefix in
subject? an extra footer in the boday?), under the assumption that no
mail files will ever exist with the same message ID but disparate
content.

Now, we have a TODO item to allow for indexing additional headers,
(either by default or by user configuration). Once we start doing that,
it probably will make sense to at least index the duplicates.

But when viewing an actual message, I'm still planning on having notmuch
just return an arbitrary filename from the list of filenames associated
with that message. Does anyone see any problem with that? Can you think
of a case where you'd really care about seeing one or the other of
a particular duplicated message?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/528b3fd3/attachment.pgp>

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman 
 wrote:
> Now, if you have an MTA that does duplicate suppression based on
> message-id, you probably won't see the copy of a message that went to
> the list if you're cc:'d on it because the direct copy (sans list-id
> header) is likely to arrive first.
> 
> I would argue that that's a feature not a bug---the sender, at least,
> hopes you will give it closer scrutiny because you were CC:'d.  They're
> trying to bring it to your attention.

Sure, giving it closer scrutiny is good. But if I expect a search like:

tag:lkml

to match all of my mail that came through the mailing list, but it
actually *misses* mail where the sender wanted me to give extra
scrutiny, then that's a big failure.

> Besides, in notmuch, what's the difference going to be?  It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?

The difference is whether the message is found in a search, (see above).

> (I'm waiting for Debian packages, lazy bastard that I am, so I'm
> guessing on that)

Yeah, I'll get to that (real soon now, I promise.)

> On the linux-kernel list, l-k often isn't in the to: field---or does
> notmuch also index the cc: as to:?  If it does, this could work; if
> not, FAIL.

Yes. In notmuch, all recipient fields, (even Bcc: if a mail happens to
hit your mail store with that intact), all get indexed to a single "to"
prefix. My rationale is that when reading a message it's often very
useful to see whether I was addresses specifically or just CC'ed. But
when _searching_ for a message, it's too fragile to have to guess
whether the recipient was on the To: or CC: header (and too painful to
always type (to:m...@example.com or cc:m...@example.com).

-Carl


pgphwLErbTMiN.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 4 Dec 2009 14:09:46 -0500, Michael Alan Dorman  wrote:
> Now, if you have an MTA that does duplicate suppression based on
> message-id, you probably won't see the copy of a message that went to
> the list if you're cc:'d on it because the direct copy (sans list-id
> header) is likely to arrive first.
> 
> I would argue that that's a feature not a bug---the sender, at least,
> hopes you will give it closer scrutiny because you were CC:'d.  They're
> trying to bring it to your attention.

Sure, giving it closer scrutiny is good. But if I expect a search like:

tag:lkml

to match all of my mail that came through the mailing list, but it
actually *misses* mail where the sender wanted me to give extra
scrutiny, then that's a big failure.

> Besides, in notmuch, what's the difference going to be?  It'll still be
> threaded the same, etc., but you'd be able to tell that this one came
> to you rather than through the list, no?

The difference is whether the message is found in a search, (see above).

> (I'm waiting for Debian packages, lazy bastard that I am, so I'm
> guessing on that)

Yeah, I'll get to that (real soon now, I promise.)

> On the linux-kernel list, l-k often isn't in the to: field---or does
> notmuch also index the cc: as to:?  If it does, this could work; if
> not, FAIL.

Yes. In notmuch, all recipient fields, (even Bcc: if a mail happens to
hit your mail store with that intact), all get indexed to a single "to"
prefix. My rationale is that when reading a message it's often very
useful to see whether I was addresses specifically or just CC'ed. But
when _searching_ for a message, it's too fragile to have to guess
whether the recipient was on the To: or CC: header (and too painful to
always type (to:me at example.com or cc:me at example.com).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/a2f9ca6d/attachment-0001.pgp>

Re: [notmuch] [PATCH] Fix typos in documentation strings

[Carl Worth]

On Tue, 01 Dec 2009 08:45:17 -0200, Fernando Carrijo  
wrote:
> One more party, one more joiner, one more patch!  :)

Welcome to the party, Fernando!

> -  "Forward a the current message."
> +  "Forward the current message."
..
> -  "Preficate testing whether current message is unread."
> +  "Predicate testing whether current message is unread."

Clearly I need to stay on top of my notmuch patch-queue better. Then I
could have just applied this patch instead of finding and fixing those
typos separately.

I'll look forward to further patches from you! (And don't worry, I'm
sure I'll keep misspelling things often...)

-Carl


pgprcdxMuTYlH.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Fix typos in documentation strings

[Carl Worth]

On Tue, 01 Dec 2009 08:45:17 -0200, Fernando Carrijo  
wrote:
> One more party, one more joiner, one more patch!  :)

Welcome to the party, Fernando!

> -  "Forward a the current message."
> +  "Forward the current message."
..
> -  "Preficate testing whether current message is unread."
> +  "Predicate testing whether current message is unread."

Clearly I need to stay on top of my notmuch patch-queue better. Then I
could have just applied this patch instead of finding and fixing those
typos separately.

I'll look forward to further patches from you! (And don't worry, I'm
sure I'll keep misspelling things often...)

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/838784f5/attachment.pgp>

Re: [notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:16:20PM -0800, Carl Worth wrote:
> On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins 
>  wrote:
> > -   install contrib/notmuch-completion.bash \
> > +   install -m0644 contrib/notmuch-completion.bash \
> > $(DESTDIR)$(bash_completion_dir)/notmuch
> 
> Thanks. I pushed this.
> 
> I didn't push the parent commit in the thread, (regarding zlib), since as
> mentioned in another reply this is actually a bug in the GMime
> pkg-config file.

Great.  That's fine with me (assuming that GMime actually gets fixed
upstream).

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 04:12:47PM -0800, Carl Worth wrote:
> Handling --prefix will be a nice addition to our configure script. So,
> thanks!

Yeah, it's definitely needed for the Debian packaging as well.

> Your commit message has that flag word of "also" in it, and as it turns
> out, the removal of Makefile.config from the repository has actually
> happened already. But that was easy enough to fix.

I was thinking that the removal of the Makefile.config from the repo
went together with the new auto-generation of that file from configure
script.  Do you think they still should have been separate patches?

> > +# option parsing
> > +for option; do
> > +if [ "${option%=*}" = '--prefix' ] ; then
> > +   PREFIX="${option#*=}"
> > +fi
> > +done
> 
> I've gone ahead and committed that now. Then I noticed that we should
> really use ${option%%=*} to support the case of an option value
> containing an '=' character. So I fixed that.

Ah, good catch.  Sorry about that.  

> Our configuration system certainly isn't as full-featured yet as a
> standard autoconf-based configure script, but I'm quite happy with how
> clean it is for both users and developers.

Autoconf terrifies me, so I agree I'm quite happy with the simple
configure script we have right now.  If it gets the job done without
having to deal with autoconf then that's great in my book.

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Emacs: Problem viewing a thread after reading it once interface

[Bart Trojanowski]

* Carl Worth  [091204 13:55]:
> So maybe we need "notmuch show" to accept a second query string
> to do something like:
> 
>   notmuch show tag:foo --matching tag:inbox
> 
> which will display all threads with messages matching "tag:foo" but then
> mark only the messages matching "tag:inbox" with the "match:1" marker
> for the UI to use.

Right.  That would make sense.
thread ID, like say:

> What do you think, Bart? Did you run into a similar issue with the vim
> interface?

While I have not noticed before, yes... it's there.

-Bart



-- 
WebSig: http://www.jukie.net/~bart/sig/

Re: [notmuch] [PATCH] notmuch.el: Add face support to message summary and subject lines.

[Carl Worth]

On Mon, 30 Nov 2009 22:50:39 +0800, Kan-Ru Chen  wrote:
> Remove the underline of both message summary and subject lines.
> Message summary still defaults to reverse-video, use customize to
> change it to whatever you like.

Thanks for submitting this patch. I recently fixed the ugly underlining
a separate way. Let me know if you think the current code needs any
further improvement in this area.

-Carl


pgpqSzfSMkUuo.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] notmuch.el: Add face support to message summary and subject lines.

[Carl Worth]

On Mon, 30 Nov 2009 22:50:39 +0800, Kan-Ru Chen  wrote:
> Remove the underline of both message summary and subject lines.
> Message summary still defaults to reverse-video, use customize to
> change it to whatever you like.

Thanks for submitting this patch. I recently fixed the ugly underlining
a separate way. Let me know if you think the current code needs any
further improvement in this area.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/17f907a8/attachment.pgp>

Re: [notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Carl Worth]

On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins 
 wrote:
> - install contrib/notmuch-completion.bash \
> + install -m0644 contrib/notmuch-completion.bash \
>   $(DESTDIR)$(bash_completion_dir)/notmuch

Thanks. I pushed this.

I didn't push the parent commit in the thread, (regarding zlib), since as
mentioned in another reply this is actually a bug in the GMime
pkg-config file.

-Carl


pgpZuFWxHwUsm.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 3/3] fix Makefile.local to install bash completion definitions as not executable

[Carl Worth]

On Sat, 28 Nov 2009 18:57:37 -0500, Jameson Graef Rollins  wrote:
> - install contrib/notmuch-completion.bash \
> + install -m0644 contrib/notmuch-completion.bash \
>   $(DESTDIR)$(bash_completion_dir)/notmuch

Thanks. I pushed this.

I didn't push the parent commit in the thread, (regarding zlib), since as
mentioned in another reply this is actually a bug in the GMime
pkg-config file.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/78c6/attachment.pgp>

Re: [notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Sat, 28 Nov 2009 18:57:35 -0500, Jameson Graef Rollins 
 wrote:
> This also removes the Makefile.config from the repository, since it
> shouldn't be kept in the repository and should be created by the
> configure script.

Hi Jamie,

Handling --prefix will be a nice addition to our configure script. So,
thanks!

Your commit message has that flag word of "also" in it, and as it turns
out, the removal of Makefile.config from the repository has actually
happened already. But that was easy enough to fix.

> +# option parsing
> +for option; do
> +if [ "${option%=*}" = '--prefix' ] ; then
> + PREFIX="${option#*=}"
> +fi
> +done

I've gone ahead and committed that now. Then I noticed that we should
really use ${option%%=*} to support the case of an option value
containing an '=' character. So I fixed that.

Then, since I was in the area, I added support to configure for
capturing CFLAGS from the environment, I fixed this (and also "make
CFLAGS=") to also influence C++ compilation (still can be separately
overridden with CXXFLAGS), and I fixed our quiet-compilation mode to
actually print the (user-specified) CFLAGS.

Finally, I documented things by adding a "configure --help" to document
CC, CFLAGS, and --prefix; and by making "make" tell the user about
"./configure" and "./configure --help" when make runs configure
implicitly.

Our configuration system certainly isn't as full-featured yet as a
standard autoconf-based configure script, but I'm quite happy with how
clean it is for both users and developers.

-Carl


pgp653MkE239C.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 1/3] fix configure script to handle --prefix= and properly create Makefile.config

[Carl Worth]

On Sat, 28 Nov 2009 18:57:35 -0500, Jameson Graef Rollins  wrote:
> This also removes the Makefile.config from the repository, since it
> shouldn't be kept in the repository and should be created by the
> configure script.

Hi Jamie,

Handling --prefix will be a nice addition to our configure script. So,
thanks!

Your commit message has that flag word of "also" in it, and as it turns
out, the removal of Makefile.config from the repository has actually
happened already. But that was easy enough to fix.

> +# option parsing
> +for option; do
> +if [ "${option%=*}" = '--prefix' ] ; then
> + PREFIX="${option#*=}"
> +fi
> +done

I've gone ahead and committed that now. Then I noticed that we should
really use ${option%%=*} to support the case of an option value
containing an '=' character. So I fixed that.

Then, since I was in the area, I added support to configure for
capturing CFLAGS from the environment, I fixed this (and also "make
CFLAGS=") to also influence C++ compilation (still can be separately
overridden with CXXFLAGS), and I fixed our quiet-compilation mode to
actually print the (user-specified) CFLAGS.

Finally, I documented things by adding a "configure --help" to document
CC, CFLAGS, and --prefix; and by making "make" tell the user about
"./configure" and "./configure --help" when make runs configure
implicitly.

Our configuration system certainly isn't as full-featured yet as a
standard autoconf-based configure script, but I'm quite happy with how
clean it is for both users and developers.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/64b55f91/attachment.pgp>

Re: [notmuch] emacs UI customization

[Jameson Graef Rollins]

On Fri, Dec 04, 2009 at 01:01:17PM -0500, Jameson Graef Rollins wrote:
> In general, I think it would be really good to put together some
> documentation about all the ways that users can customize the notmuch
> interface.  I would be willing to help with that as well.  It would
> also be nice to allow for customization about of things that are
> currently not that might be controversial.

So I was thinking about this a bit, and it occured to me that a great
thing to do would be to include with notmuch an example emacs
configuration file that includes examples of all (or many) of the ways
one could customize emacs for notmuch, maybe also including ways one
might want to customize the 'message' or 'MML' modes as well.  I, and
I'm sure others, would find it a very useful reference.  I'll start
putting something like this together and forward what I have to the
list.  If others are interested in doing the same, I would be thrilled
to compile what we come up with.

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

On Sat, 05 Dec 2009 00:55:20 +0600
Mikhail Gusarov  wrote:

> 
> Twas brillig at 13:52:20 04.12.2009 UTC-05 when
> mdorman at ironicdesign.com did gyre and gimble:
> 
>  MAD> Err, this makes no sense.  How can Mailman have any knowledge
>  MAD> of, and therefore "do anything" to any message that came by way
>  MAD> of a CC?
> 
> for each subscriber:
>   if subscriber.email in message.cc:
>  continue
>   ...
>   # delivery

I stand corrected---it seems like a gigantic misfeature to me, so
much so that I checked and apparently that is exactly how Mailman
works in its default configuration.

My apologies for suggesting you didn't know what you were talking
about.  I made the mistake of assuming sane software.

Mike.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/37421252/attachment-0001.pgp>

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
> I just pushed out a nice set of changes to the emacs interface. Here's a
> quick summary of what you can expect to get when you next update:
> 
>   * Much nicer looking presentation, (no more ugly reverse-video or
> underlines on the message summary line).
> 
>   * More reliable message-visibility buttons, (using RET in the first
> column of a message-summary line now works).
> 
>   * Space bar fixed to advance to next open message, (it was originally
> written this way, but has been broken since we changed from global
> to local toggling of hidden message parts).
> 
>   * Showing a thread where the search matches only a subset of the
> thread now opens only the matched messages (in addition to unread
> messages).
> 
> This last feature is the big one---the rest all just happened to come
> along at the same time. One thing that I often do is read some giant
> thread and then tag a single message deep in that thread for dealing
> with later. And previously, doing a search for that tag would bring back
> the entire thread. Now, it opens only the message I'm actually looking
> for. So this is a very welcome change
> 
> And thanks to Bart Trojanowski for the groundwork for this change. I
> think the vim interface has had this feature for a while, (or would have
> if I had pushed all of Bart's changes earlier).
> 
> Meanwhile, Keith and Eric gave me some helpful feedback about the
> notmuch user-interface over lunch today, and in particular about the
> handling of the "unread" tag. Here are some of the things discussed,
> along with some things I'd like to change in response.
> 
> I'm open to suggestions on all of these, and most importantly, wanted to
> let people know about some upcoming user-interface changes before they
> were in place and potentially surprising.
> 
>   * The magic space bar is too magic. Threads are separate conversations
> so one key for paging through the current conversation shouldn't
> also switch to the next conversation, (particularly when the
> complementary key DEL doesn't reverse this behavior of SPACE).
> 
> Recommendation: Make SPACE only page the current message. Recommend
> that user use 'a' to advance to next thread, (or 'x' to exit back to
> search results).
> 
>   * The unread tag is not handled transparently enough. Both Keith and
> Eric complained of frequently being presented with messages as
> "unread" that they had read before. (And I don't want to ever have
> to manually think about whether to remove a thread as "unread".)
> 
> Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
> 'x' mark remove the "unread" tag from all messages in the current
> thread (as well as the "inbox" tag as currently). Also make 'n' and
> 'p' remove the "unread tag as well.
> 
> Followup: This frees up 'N' and 'P', so I'd like to use the for
> "next message" and "previous message" and make 'n' and 'p' do "next
> open message" and "previous open message".
> 
>   * Opening up unread messages in notmuch-show mode is not
> helpful. Keith reads a lot of high-volume mailing lists by reading
> the subject lines in search mode and then doing "* -inbox". He likes
> that notmuch remembers that these messages are still unread, but if
> he later searches for a single message that happens to be in a giant
> thread of unread messages, then he wants to see just than one
> message, not all of them.
> 
> Recommendation: Make notmuch-show-mode open *only* messages that
> match the search---not unread messages as well. At this point the
> unread tag becomes just a hint to the user and won't be explicitly
> handled differently by the interface, (other than that various
> commands will remove the unread tag if present). The unread tag is
> still useful for when searching for something like "I know I read
> this message recently".
> 
> Followup: I wonder if I would miss one feature here. If I'm
> interrupted after reading part of a giant thread, currently I can
> quite and when I come back notmuch will remember right where I was
> while reading. One way to get this behavior back would be to make
> SPACE remove the inbox tag from each message its scrolled off. I'll
> have to think about that.
> 
>   * The current 'a' key in search-mode is unreliable. It seemed like a
> good idea to make 'a' only archive messages that match the search,
> but it's a flawed idea. Imagine the following scenario: Eric is
> reading his inbox and sees some threads related to a boring
> topic. He filters down to these with "f tag:boring". He's satisfied
> with the search results, and hits 'a' on each thread and even sees
> the "inbox" tag disappear from the presentation. But then when he
> returns to his inbox search and refreshes, the boring threads
> re-appear and have the 

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

> But the above sounds like the List-Id header is unreliable enough to
> be useless.

In my current .sieve setup, I have 93 entries for mailing lists.  87
of them use list-id[1].  3 use list-post.  1 uses 'mailing-list', but
looking at it, could be switched to list-id.  2 use x-mailing-list
(blasted vger.kernel.org).

None of my email gets misfiled, so it seems pretty darn reliable to
me. :)

Now, if you have an MTA that does duplicate suppression based on
message-id, you probably won't see the copy of a message that went to
the list if you're cc:'d on it because the direct copy (sans list-id
header) is likely to arrive first.

I would argue that that's a feature not a bug---the sender, at least,
hopes you will give it closer scrutiny because you were CC:'d.  They're
trying to bring it to your attention.

Besides, in notmuch, what's the difference going to be?  It'll still be
threaded the same, etc., but you'd be able to tell that this one came
to you rather than through the list, no?

(I'm waiting for Debian packages, lazy bastard that I am, so I'm
guessing on that)

> Any reason not to just use something like
> to:notmuch at notmuchmail to match messages sent to a list like this one?

On the linux-kernel list, l-k often isn't in the to: field---or does
notmuch also index the cc: as to:?  If it does, this could work; if
not, FAIL.

Mike.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/8770d8fc/attachment.pgp>

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:

.

> 
>   * The magic space bar is too magic. Threads are separate conversations
> so one key for paging through the current conversation shouldn't
> also switch to the next conversation, (particularly when the
> complementary key DEL doesn't reverse this behavior of SPACE).

agreed

> 
> Recommendation: Make SPACE only page the current message. Recommend
> that user use 'a' to advance to next thread, (or 'x' to exit back to
> search results).

Later you mention 'N' and 'n' to do the same task. Or are you suggesting
that 'a' would move to the next task after marking the current task read ?

> 
>   * The unread tag is not handled transparently enough. Both Keith and
> Eric complained of frequently being presented with messages as
> "unread" that they had read before. (And I don't want to ever have
> to manually think about whether to remove a thread as "unread".)
> 
> Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
> 'x' mark remove the "unread" tag from all messages in the current
> thread (as well as the "inbox" tag as currently). Also make 'n' and
> 'p' remove the "unread tag as well.


ok that explains. But with Xapian ticket 250 we would definitely want
some keybinding that move to the next mail without updating tags.


> 
> Followup: This frees up 'N' and 'P', so I'd like to use the for
> "next message" and "previous message" and make 'n' and 'p' do "next
> open message" and "previous open message".
> 
>   * Opening up unread messages in notmuch-show mode is not
> helpful. Keith reads a lot of high-volume mailing lists by reading
> the subject lines in search mode and then doing "* -inbox". He likes
> that notmuch remembers that these messages are still unread, but if
> he later searches for a single message that happens to be in a giant
> thread of unread messages, then he wants to see just than one
> message, not all of them.
> 
> Recommendation: Make notmuch-show-mode open *only* messages that
> match the search---not unread messages as well. At this point the
> unread tag becomes just a hint to the user and won't be explicitly
> handled differently by the interface, (other than that various
> commands will remove the unread tag if present). The unread tag is
> still useful for when searching for something like "I know I read
> this message recently".
> 
> Followup: I wonder if I would miss one feature here. If I'm
> interrupted after reading part of a giant thread, currently I can
> quite and when I come back notmuch will remember right where I was
> while reading. One way to get this behavior back would be to make
> SPACE remove the inbox tag from each message its scrolled off. I'll
> have to think about that.
> 
>   * The current 'a' key in search-mode is unreliable. It seemed like a
> good idea to make 'a' only archive messages that match the search,
> but it's a flawed idea. Imagine the following scenario: Eric is
> reading his inbox and sees some threads related to a boring
> topic. He filters down to these with "f tag:boring". He's satisfied
> with the search results, and hits 'a' on each thread and even sees
> the "inbox" tag disappear from the presentation. But then when he
> returns to his inbox search and refreshes, the boring threads
> re-appear and have the inbox tag again. Ugh. The presentation is
> inconsistent and things just feel unreliable and broken.
> 
> And a related issue:
> 
>   * The '*' key in search-mode doesn't provide any feedback that it has
> actually done anything, (none of the added/removed tags are changed
> in the presentation). And hitting '=' isn't necessarily ideal since
> it can make things irretrievably disappear, ('a' is different since
> it allows the user to confirm that things are good before making
> results disappear with '='). [*]
> 
> Recommendation: Revert 'a' to act on all messages in a thread---not
> only those that match the search results. Then change '*' to work by
> walking the list and explicitly calling the same action as 'a' on
> each line. This will provide the desired feedback and should be
> plenty fast.

With xapian ticket 250 doing a tag update per thread is going to be
really slow right ?


> 
> Note: There are still use cases where the user might want to modify
> the tags only on messages matching the search, (think, "remove from
> inbox all messages from:someone"). So I'm aware that there's still a
> hole in functionality here, but I really want to fix the current
> inconsistency in the presentation. And I'm open to further
> suggestions here.
> 
> Let me know if any of the above seems crazy,
> 

-aneesh

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

On Sat, 05 Dec 2009 00:07:36 +0600
Mikhail Gusarov  wrote:

> The only problem with Cc is that Mailman suppresses duplicate
> messages and hence there is no List-Id: on message.

Err, this makes no sense.  How can Mailman have any knowledge of, and
therefore "do anything" to any message that came by way of a CC?

Now, your mail transfer agent might do duplicate suppression, and if
the direct email reaches you before the one that went through the
mailing list, you won't have a copy that includes the list-id header,
but that's an issue on your end, not with the mailing list software.

Mike.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/1a80237f/attachment.pgp>

Re: [notmuch] Emacs: Problem viewing a thread after reading it once interface

[Bart Trojanowski]

* Carl Worth  [091204 13:55]:
> So maybe we need "notmuch show" to accept a second query string
> to do something like:
> 
>   notmuch show tag:foo --matching tag:inbox
> 
> which will display all threads with messages matching "tag:foo" but then
> mark only the messages matching "tag:inbox" with the "match:1" marker
> for the UI to use.

Right.  That would make sense.
thread ID, like say:

> What do you think, Bart? Did you run into a similar issue with the vim
> interface?

While I have not noticed before, yes... it's there.

-Bart



-- 
WebSig: http://www.jukie.net/~bart/sig/
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] emacs UI customization

[Jameson Graef Rollins]

Hey, Carl et. al.  The recent improvements to the notmuch emacs mode
look great.  I have a couple of suggestions/questions about the UI
that I wanted to put to the group.

Here are some things that I would really like to see:

* in thread view, show read messages as initially collapsed

* show more header info (To:, Date: (with time), etc), or add ability
  to control which headers are displayed

* add blank line between header and body

* customize coloring of fields (in headers, or collapsed
  quotes/signatures/etc)

* customize key bindings

Is it currently possible to easily customize these things (ie. without
modifying the notmuch.el)?  If so, that would be great and I would
love to learn how (my current elisp and emacs customization skills are
pretty weak).  If not, I would like to strongly petition for either
changing these things, or making it possible for users to customize
them themselves.

In general, I think it would be really good to put together some
documentation about all the ways that users can customize the notmuch
interface.  I would be willing to help with that as well.  It would
also be nice to allow for customization about of things that are
currently not that might be controversial.

Thanks so much for the help.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/34d88203/attachment.pgp>

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

On Sat, 05 Dec 2009 00:55:20 +0600
Mikhail Gusarov  wrote:

> 
> Twas brillig at 13:52:20 04.12.2009 UTC-05 when
> mdor...@ironicdesign.com did gyre and gimble:
> 
>  MAD> Err, this makes no sense.  How can Mailman have any knowledge
>  MAD> of, and therefore "do anything" to any message that came by way
>  MAD> of a CC?
> 
> for each subscriber:
>   if subscriber.email in message.cc:
>  continue
>   ...
>   # delivery

I stand corrected---it seems like a gigantic misfeature to me, so
much so that I checked and apparently that is exactly how Mailman
works in its default configuration.

My apologies for suggesting you didn't know what you were talking
about.  I made the mistake of assuming sane software.

Mike.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Jed Brown]

On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth  wrote:

> But surely there's a way to implement this with dramatically less code
> duplication?

It should just be very short after this series

  id:1259450376-24523-1-git-send-email-...@59a2.org

I think --format= should not be used for this, formatting is orthogonal
to selecting recipients.

Speaking of code duplication, perhaps it is worth abstracting options
parsing (or using an existing library).

Jed
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 2/2] * free the response data from 'prompt'

[Carl Worth]

On Wed,  2 Dec 2009 09:11:25 +0200, "Dirk-Jan C. Binnema"  
wrote:
> Free the results of the prompt; this patch does the minimal job for that.
> It may be nice to refactor the function a bit. 
> 
> Signed-off-by: Dirk-Jan C. Binnema 

Hi there,

I pushed the first leak fix from this series, but the below is doing a
little more work than necessary.

The getline function is happy to accept a malloc'ed pointer and return
it again if it's large enough, (or otherwise realloc it and return the
result).

So we don't need to free response between each call to prompt, but just
after the last one.

-Carl


pgptKYgSPXMNE.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 2/2] * free the response data from 'prompt'

[Carl Worth]

On Wed,  2 Dec 2009 09:11:25 +0200, "Dirk-Jan C. Binnema"  wrote:
> Free the results of the prompt; this patch does the minimal job for that.
> It may be nice to refactor the function a bit. 
> 
> Signed-off-by: Dirk-Jan C. Binnema 

Hi there,

I pushed the first leak fix from this series, but the below is doing a
little more work than necessary.

The getline function is happy to accept a malloc'ed pointer and return
it again if it's large enough, (or otherwise realloc it and return the
result).

So we don't need to free response between each call to prompt, but just
after the last one.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/c03b8bc3/attachment.pgp>

[notmuch] Trouble with notmuch-show

[Alexander Botero-Lowry]

On Fri, 04 Dec 2009 11:06:15 -0800, Carl Worth  wrote:
> On Thu, 03 Dec 2009 23:08:31 +0100, Jed Brown  wrote:
> > I know html support is still poor, but the following seems worse than
> > not showing anything.  When I visit this message, I get prompted to save
> > the MIME part and the following is displayed (including all the hidden
> > stuff).  Original message is attached.
> 
> I ran into this recently as well.
> 
> When the HTML formatting works, it's quite impressive. But when it
> decides it needs to save some attachment, then notmuch gets tripped up
> and ends up displaying a very raw message.
> 
Yes. I've notied this but only with spam. I've been not bothered to look
into it because of that, but it's starting to break my spacebar flow, so
I'll try and figure out what's going on.

alex

Re: [notmuch] Trouble with notmuch-show

[Alexander Botero-Lowry]

On Fri, 04 Dec 2009 11:06:15 -0800, Carl Worth  wrote:
> On Thu, 03 Dec 2009 23:08:31 +0100, Jed Brown  wrote:
> > I know html support is still poor, but the following seems worse than
> > not showing anything.  When I visit this message, I get prompted to save
> > the MIME part and the following is displayed (including all the hidden
> > stuff).  Original message is attached.
> 
> I ran into this recently as well.
> 
> When the HTML formatting works, it's quite impressive. But when it
> decides it needs to save some attachment, then notmuch gets tripped up
> and ends up displaying a very raw message.
> 
Yes. I've notied this but only with spam. I've been not bothered to look
into it because of that, but it's starting to break my spacebar flow, so
I'll try and figure out what's going on.

alex
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Make search filters handle disjunctive queries.

[Carl Worth]

On Wed,  2 Dec 2009 12:00:35 +0100, Jed Brown  wrote:
> notmuch-search-filter now accepts an arbitrary query and will group if
> necessary so that we get
> 
>   tag:inbox AND (gravy OR biscuits)
> 
> instead of the former
> 
>   tag:inbox AND gravy OR biscuits

Perfect. A nice clean patch for just the one feature. Thanks!

I've pushed this now.

-Carl


pgpptmtW52QwL.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH] Make search filters handle disjunctive queries.

[Carl Worth]

On Wed,  2 Dec 2009 12:00:35 +0100, Jed Brown  wrote:
> notmuch-search-filter now accepts an arbitrary query and will group if
> necessary so that we get
> 
>   tag:inbox AND (gravy OR biscuits)
> 
> instead of the former
> 
>   tag:inbox AND gravy OR biscuits

Perfect. A nice clean patch for just the one feature. Thanks!

I've pushed this now.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/f57e000d/attachment.pgp>

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

> But the above sounds like the List-Id header is unreliable enough to
> be useless.

In my current .sieve setup, I have 93 entries for mailing lists.  87
of them use list-id[1].  3 use list-post.  1 uses 'mailing-list', but
looking at it, could be switched to list-id.  2 use x-mailing-list
(blasted vger.kernel.org).

None of my email gets misfiled, so it seems pretty darn reliable to
me. :)

Now, if you have an MTA that does duplicate suppression based on
message-id, you probably won't see the copy of a message that went to
the list if you're cc:'d on it because the direct copy (sans list-id
header) is likely to arrive first.

I would argue that that's a feature not a bug---the sender, at least,
hopes you will give it closer scrutiny because you were CC:'d.  They're
trying to bring it to your attention.

Besides, in notmuch, what's the difference going to be?  It'll still be
threaded the same, etc., but you'd be able to tell that this one came
to you rather than through the list, no?

(I'm waiting for Debian packages, lazy bastard that I am, so I'm
guessing on that)

> Any reason not to just use something like
> to:notm...@notmuchmail to match messages sent to a list like this one?

On the linux-kernel list, l-k often isn't in the to: field---or does
notmuch also index the cc: as to:?  If it does, this could work; if
not, FAIL.

Mike.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Carl Worth]

On Thu,  3 Dec 2009 14:16:44 +0530, "Aneesh Kumar K.V" 
 wrote:
> From: Aneesh Kumar K.V 
> 
> This patch add --format=sender-only option.

I like the idea here, (and agree that an 'R' keybinding would be great).

But surely there's a way to implement this with dramatically less code
duplication?

-Carl


pgpTfOPIsYeky.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 1/2] notmuch-reply: Add support for replying only to sender

[Carl Worth]

On Thu,  3 Dec 2009 14:16:44 +0530, "Aneesh Kumar K.V"  wrote:
> From: Aneesh Kumar K.V 
> 
> This patch add --format=sender-only option.

I like the idea here, (and agree that an 'R' keybinding would be great).

But surely there's a way to implement this with dramatically less code
duplication?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/309042f4/attachment.pgp>

Re: [notmuch] Trouble with notmuch-show

[Carl Worth]

On Thu, 03 Dec 2009 23:08:31 +0100, Jed Brown  wrote:
> I know html support is still poor, but the following seems worse than
> not showing anything.  When I visit this message, I get prompted to save
> the MIME part and the following is displayed (including all the hidden
> stuff).  Original message is attached.

I ran into this recently as well.

When the HTML formatting works, it's quite impressive. But when it
decides it needs to save some attachment, then notmuch gets tripped up
and ends up displaying a very raw message.

Improvements would be most welcome, from anyone, of course.

-Carl


pgpOXw7OA9X80.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Trouble with notmuch-show

[Carl Worth]

On Thu, 03 Dec 2009 23:08:31 +0100, Jed Brown  wrote:
> I know html support is still poor, but the following seems worse than
> not showing anything.  When I visit this message, I get prompted to save
> the MIME part and the following is displayed (including all the hidden
> stuff).  Original message is attached.

I ran into this recently as well.

When the HTML formatting works, it's quite impressive. But when it
decides it needs to save some attachment, then notmuch gets tripped up
and ends up displaying a very raw message.

Improvements would be most welcome, from anyone, of course.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/1554234d/attachment.pgp>

[notmuch] Emacs: Problem viewing a thread after reading it once interface

[Carl Worth]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
>   * Showing a thread where the search matches only a subset of the
> thread now opens only the matched messages (in addition to unread
> messages).
> 
> This last feature is the big one---the rest all just happened to come
> along at the same time. One thing that I often do is read some giant
> thread and then tag a single message deep in that thread for dealing
> with later. And previously, doing a search for that tag would bring back
> the entire thread. Now, it opens only the message I'm actually looking
> for. So this is a very welcome change

Unfortunately, this change also introduces a major bug.

After I do a search such as tag:inbox and then view a resulting thread,
(and read it and archive it), then my search results still show that
thread result until I manually update the search view.

But, if I actually try to view that thread again from the search view,
it doesn't work. It previously worked since it would call "notmuch show"
with a query string of "thread:foo" but now calls it with "thread:foo
and tag:inbox" which now matches no messages.

The additional search term wasn't intended to change the returned
messages, (since we're passing the --entire-thread option to see all the
messages in the thread). It was only intended to restrict which messages
get the "match:1" marker added to them.

So maybe we need "notmuch show" to accept a second query string
to do something like:

notmuch show tag:foo --matching tag:inbox

which will display all threads with messages matching "tag:foo" but then
mark only the messages matching "tag:inbox" with the "match:1" marker
for the UI to use.

What do you think, Bart? Did you run into a similar issue with the vim
interface?

-Carl


pgp8w36ktLXBQ.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Emacs: Problem viewing a thread after reading it once interface

[Carl Worth]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
>   * Showing a thread where the search matches only a subset of the
> thread now opens only the matched messages (in addition to unread
> messages).
> 
> This last feature is the big one---the rest all just happened to come
> along at the same time. One thing that I often do is read some giant
> thread and then tag a single message deep in that thread for dealing
> with later. And previously, doing a search for that tag would bring back
> the entire thread. Now, it opens only the message I'm actually looking
> for. So this is a very welcome change

Unfortunately, this change also introduces a major bug.

After I do a search such as tag:inbox and then view a resulting thread,
(and read it and archive it), then my search results still show that
thread result until I manually update the search view.

But, if I actually try to view that thread again from the search view,
it doesn't work. It previously worked since it would call "notmuch show"
with a query string of "thread:foo" but now calls it with "thread:foo
and tag:inbox" which now matches no messages.

The additional search term wasn't intended to change the returned
messages, (since we're passing the --entire-thread option to see all the
messages in the thread). It was only intended to restrict which messages
get the "match:1" marker added to them.

So maybe we need "notmuch show" to accept a second query string
to do something like:

notmuch show tag:foo --matching tag:inbox

which will display all threads with messages matching "tag:foo" but then
mark only the messages matching "tag:inbox" with the "match:1" marker
for the UI to use.

What do you think, Bart? Did you run into a similar issue with the vim
interface?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/e0e57e1f/attachment.pgp>

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 13:52:20 04.12.2009 UTC-05 when mdor...@ironicdesign.com did 
gyre and gimble:

 MAD> Err, this makes no sense.  How can Mailman have any knowledge of,
 MAD> and therefore "do anything" to any message that came by way of a
 MAD> CC?

for each subscriber:
  if subscriber.email in message.cc:
 continue
  ...
  # delivery

 MAD> Now, your mail transfer agent might do duplicate suppression

No, it does not.

-- 
  http://fossarchy.blogspot.com/


pgpZEvfLz2HuF.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Michael Alan Dorman]

On Sat, 05 Dec 2009 00:07:36 +0600
Mikhail Gusarov  wrote:

> The only problem with Cc is that Mailman suppresses duplicate
> messages and hence there is no List-Id: on message.

Err, this makes no sense.  How can Mailman have any knowledge of, and
therefore "do anything" to any message that came by way of a CC?

Now, your mail transfer agent might do duplicate suppression, and if
the direct email reaches you before the one that went through the
mailing list, you won't have a copy that includes the list-id header,
but that's an issue on your end, not with the mailing list software.

Mike.


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 10:35:27 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

 >> The only problem with Cc is that Mailman suppresses duplicate
 >> messages and hence there is no List-Id: on message.

 CW> But the above sounds like the List-Id header is unreliable enough
 CW> to be useless.  Any reason not to just use something like
 CW> to:notm...@notmuchmail to match messages sent to a list like this
 CW> one?

Automated processing. I'd go crazy to put all mailing lists' addresses
to .procmailrc instead of simple sorter in sed. But it seems it's the
only reliable way.

 CW> I think mailman defaults to not allowing messages with the
 CW> mailing-list address implicit (such as in a Bcc) so it seems like
 CW> matching the list recipient will be more reliable than hoping the
 CW> List-Id is always there.

Yep. Unfortunately.

-- 
  http://fossarchy.blogspot.com/


pgpJIxAtRvcFv.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Notmuch's search view sucks

[Olly Betts]

Karl Wiberg writes:
> On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth wrote:
> > And a step beyond that would support different languages for
> > different emails, but that sounds like something "hard" to identify.
> 
> But probably not as hard as identifying spam. It could probably be
> done with a simple Bayesian filter counting word frequencies---but
> it'd be much better if somebody else had already solved the problem,
> since this smells suspiciously like something that ought to be a
> separate project and put in a library ... does anyone know if such a
> project already exists?

There's TextCat:

http://www.let.rug.nl/vannoord/TextCat/

It looks at n-gram frequencies, and can guess pretty reliably from
even a fairly small amount of text.

TextCat is in Perl.  I don't know if there's a C or C++ implementation
but it isn't a huge piece of code - finding a good technique was the
clever part of it.

Cheers,
Olly

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Sat, 05 Dec 2009 00:07:36 +0600, Mikhail Gusarov  
wrote:
> The only problem with Cc is that Mailman suppresses duplicate messages and 
> hence
> there is no List-Id: on message.

Hey, well notmuch doesn't even index the List-Id: header anyway. [*] ;-)

But the above sounds like the List-Id header is unreliable enough to be
useless. Any reason not to just use something like
to:notm...@notmuchmail to match messages sent to a list like this one?

I think mailman defaults to not allowing messages with the mailing-list
address implicit (such as in a Bcc) so it seems like matching the list
recipient will be more reliable than hoping the List-Id is always there.

-Carl

[*] Our TODO list does talk about supporting a configuration parameter
for indexing additional headers of interest.


pgpV8gX9vqhp9.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Sat, 05 Dec 2009 00:07:36 +0600, Mikhail Gusarov  wrote:
> The only problem with Cc is that Mailman suppresses duplicate messages and 
> hence
> there is no List-Id: on message.

Hey, well notmuch doesn't even index the List-Id: header anyway. [*] ;-)

But the above sounds like the List-Id header is unreliable enough to be
useless. Any reason not to just use something like
to:notmuch at notmuchmail to match messages sent to a list like this one?

I think mailman defaults to not allowing messages with the mailing-list
address implicit (such as in a Bcc) so it seems like matching the list
recipient will be more reliable than hoping the List-Id is always there.

-Carl

[*] Our TODO list does talk about supporting a configuration parameter
for indexing additional headers of interest.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/d72d0cf7/attachment.pgp>

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Mikhail Gusarov]

Twas brillig at 10:05:05 04.12.2009 UTC-08 when cwo...@cworth.org did gyre and 
gimble:

 CW> Plus, notmuch already handles duplicate mail just fine, (in that the
 CW> user only sees one copy at least). And I tag my mail differently when
 CW> one of my addresses appears on the CC list, so I definitely prefer that
 CW> people CC me when they want to call my specific attention to a message.

The only problem with Cc is that Mailman suppresses duplicate messages and hence
there is no List-Id: on message.

-- 
  http://fossarchy.blogspot.com/


pgp0ErfTPiPG0.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 04 Dec 2009 09:55:45 -0400, da...@tethera.net wrote:
> P.S. do people want to be CC'd on this list, or not?

We don't require subscription to the list, so I recommend CC, yes.

Plus, notmuch already handles duplicate mail just fine, (in that the
user only sees one copy at least). And I tag my mail differently when
one of my addresses appears on the CC list, so I definitely prefer that
people CC me when they want to call my specific attention to a message.

-Carl



pgpLVTXleZV0b.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[Carl Worth]

On Fri, 04 Dec 2009 09:55:45 -0400, david at tethera.net wrote:
> P.S. do people want to be CC'd on this list, or not?

We don't require subscription to the list, so I recommend CC, yes.

Plus, notmuch already handles duplicate mail just fine, (in that the
user only sees one copy at least). And I tag my mail differently when
one of my addresses appears on the CC list, so I definitely prefer that
people CC me when they want to call my specific attention to a message.

-Carl

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/c590d01f/attachment.pgp>

Re: [notmuch] Notmuch's search view sucks

[Carl Worth]

On Fri, 04 Dec 2009 06:52:38 -0500, Aaron Ecay  wrote:
> The same algorithm is implemented in C here:
> http://www.mnogosearch.org/guesser/
> 
> Licensed under the GPL and includes presets for ~50 languages.

That indeed does look very interesting, (at least what I can get from
google's cache of the website, as the server seems to be down just
now). Oh, but I can just "apt-get source mnogosearch" and find
src/mguesser.c and src/guesser.c at least.

> A potential drawback is that it doesn't handle raw HTML very well,
> according to the documentation.

Shouldn't really be an issue. Notmuch will already want to de-tagify
HTML before indexing anyway.

-Carl


pgpzAEjnY2iSv.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Notmuch's search view sucks

[Carl Worth]

On Fri, 04 Dec 2009 06:52:38 -0500, Aaron Ecay  wrote:
> The same algorithm is implemented in C here:
> http://www.mnogosearch.org/guesser/
> 
> Licensed under the GPL and includes presets for ~50 languages.

That indeed does look very interesting, (at least what I can get from
google's cache of the website, as the server seems to be down just
now). Oh, but I can just "apt-get source mnogosearch" and find
src/mguesser.c and src/guesser.c at least.

> A potential drawback is that it doesn't handle raw HTML very well,
> according to the documentation.

Shouldn't really be an issue. Notmuch will already want to de-tagify
HTML before indexing anyway.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/d0377ad3/attachment.pgp>

[notmuch] emacs UI customization

[Jameson Graef Rollins]

Hey, Carl et. al.  The recent improvements to the notmuch emacs mode
look great.  I have a couple of suggestions/questions about the UI
that I wanted to put to the group.

Here are some things that I would really like to see:

* in thread view, show read messages as initially collapsed

* show more header info (To:, Date: (with time), etc), or add ability
  to control which headers are displayed

* add blank line between header and body

* customize coloring of fields (in headers, or collapsed
  quotes/signatures/etc)

* customize key bindings

Is it currently possible to easily customize these things (ie. without
modifying the notmuch.el)?  If so, that would be great and I would
love to learn how (my current elisp and emacs customization skills are
pretty weak).  If not, I would like to strongly petition for either
changing these things, or making it possible for users to customize
them themselves.

In general, I think it would be really good to put together some
documentation about all the ways that users can customize the notmuch
interface.  I would be willing to help with that as well.  It would
also be nice to allow for customization about of things that are
currently not that might be controversial.

Thanks so much for the help.

jamie.


signature.asc
Description: Digital signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch's search view sucks

[Baruch Even]

Karl Wiberg wrote:

On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth  wrote:

And a step beyond that would support different languages for
different emails, but that sounds like something "hard" to identify.


But probably not as hard as identifying spam. It could probably be
done with a simple Bayesian filter counting word frequencies---but
it'd be much better if somebody else had already solved the problem,
since this smells suspiciously like something that ought to be a
separate project and put in a library ... does anyone know if such a
project already exists? I know Google can do it ...

It'd be very cool to have notmuch automatically tag messages according
to what language they're in.


What we should have is an interface to run an external program to 
classify a message when it's newly introduced and another that runs when 
tags are changed so that machine learning can be made to work when the 
user changes tags.


Baruch

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH (rebased)] Handle message renames in mail spool

[da...@tethera.net]

At Thu, 03 Dec 2009 16:45:22 -0800,

> Anyway, I think we'll see code for that soon, so I'm not planning to
> commit the offered patch. But people really needing renames might want
> to use it for now, (and live with any performance implications it
> causes).

I could live with the performance issues, but it seems that it re-tags
every "Processed" file (renamed or not) as inbox.  This brings about
20k messages back into my inbox, which is a bit unusable.  The problem
seems to be that notmuch_database_add_message returns
NOTMUCH_STATUS_SUCCESS whether or not a new message was really added.
I don't know if there is an easy fix for this, or if it is worth
pursuing, given that the patch won't be committed.

d

P.S. do people want to be CC'd on this list, or not?

Re: [notmuch] [PATCH 2/9] Adjust autoload comments

[Carl Worth]

On Thu, 3 Dec 2009 20:24:59 -0500, Jameson Graef Rollins 
 wrote:
> I actually really like having notmuch open right into my "inbox".

Well, at least that option won't ever go away. :-)

> I thought part of the point of notmuch was to get rid of the whole dump
> idea of folders!

There's certainly lots of brain-damage in "folder-based" email
programs. And obviously, we don't want to encourage that. I think one of
the biggest things that notmuch provides to avoid the brain damage is
global search.

So what I'm imagining for the default notmuch view is something like
this:

Welcome to notmuch.

Notmuch search: _

Saved searches:

55,342  All messages
22  Inbox

Recent searches:

 1  from:"someone special" and tag:unread
34  tag:notmuch and tag:todo

Click (or press Enter) on any search to see the results.
Right-click (or press Space) on any recent search to save it.

So the "saved searches" portion of the view is basically just what
notmuch-folder displays now. Above that there's an obvious place to
start a new search, (in a slightly more "web-browser-like" way than the
typical mini-buffer approach).

All recent searches appear in the list at the bottom automatically, and
there's the documented mechanism for saving a search, (giving it a name
and having it appear above).

I think the above should do a good job of emphasizing what notmuch is,
and how a search-based email program is fundamentally different than a
folder-based approach.

Feedback?

-Carl


pgpJr29QsZZMw.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 2/9] Adjust autoload comments

[Carl Worth]

On Thu, 3 Dec 2009 20:24:59 -0500, Jameson Graef Rollins  wrote:
> I actually really like having notmuch open right into my "inbox".

Well, at least that option won't ever go away. :-)

> I thought part of the point of notmuch was to get rid of the whole dump
> idea of folders!

There's certainly lots of brain-damage in "folder-based" email
programs. And obviously, we don't want to encourage that. I think one of
the biggest things that notmuch provides to avoid the brain damage is
global search.

So what I'm imagining for the default notmuch view is something like
this:

Welcome to notmuch.

Notmuch search: _

Saved searches:

55,342  All messages
22  Inbox

Recent searches:

 1  from:"someone special" and tag:unread
34  tag:notmuch and tag:todo

Click (or press Enter) on any search to see the results.
Right-click (or press Space) on any recent search to save it.

So the "saved searches" portion of the view is basically just what
notmuch-folder displays now. Above that there's an obvious place to
start a new search, (in a slightly more "web-browser-like" way than the
typical mini-buffer approach).

All recent searches appear in the list at the bottom automatically, and
there's the documented mechanism for saving a search, (giving it a name
and having it appear above).

I think the above should do a good job of emphasizing what notmuch is,
and how a search-based email program is fundamentally different than a
folder-based approach.

Feedback?

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/3c2fde32/attachment-0001.pgp>

Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 03:06:32 +0100, Marten Veldthuis  
wrote:
> Not sure what happened, but:
> 
> Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
> notmuch-show-view-all-mime-parts
> From: cama...@picnicpark.org
...
> now collapses into:
> 
> Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
> notmuch-show-view-all-mime-parts
> From: Keith Amidon 
> 
> on my system (notice the From: header).

I think that's actual text in the message, (not a header). Does that
look to you like what's happening?

And any ideas for making this kind of thing more clear? On my system,
the "From:" line that is in the message at least isn't colorized like
the actual headers are.

-Carl


pgpRXliZDUQfV.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 03:06:32 +0100, Marten Veldthuis  
wrote:
> Not sure what happened, but:
> 
> Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
> notmuch-show-view-all-mime-parts
> From: camalot at picnicpark.org
...
> now collapses into:
> 
> Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
> notmuch-show-view-all-mime-parts
> From: Keith Amidon 
> 
> on my system (notice the From: header).

I think that's actual text in the message, (not a header). Does that
look to you like what's happening?

And any ideas for making this kind of thing more clear? On my system,
the "From:" line that is in the message at least isn't colorized like
the actual headers are.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/0766d940/attachment.pgp>

Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 14:28:22 +0530, "Aneesh Kumar K. V" 
 wrote:
> Can we also get a facility to temporarily mark a message and apply tags
> on all marked message. In mutt terminology it is called 'tag'.

Would be nice, yes. Another thing we probably want is a way to modify
the tags on all threads within the current emacs region.

-Carl


pgpCLQkf2kb8N.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

On Fri, 04 Dec 2009 14:28:22 +0530, "Aneesh Kumar K. V"  wrote:
> Can we also get a facility to temporarily mark a message and apply tags
> on all marked message. In mutt terminology it is called 'tag'.

Would be nice, yes. Another thing we probably want is a way to modify
the tags on all threads within the current emacs region.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/2a986042/attachment.pgp>

Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

Hi Aneesh,

Thanks for the followup.

On Fri, 04 Dec 2009 14:08:52 +0530, "Aneesh Kumar K. V" 
 wrote:
> > Recommendation: Make SPACE only page the current message. Recommend
> > that user use 'a' to advance to next thread, (or 'x' to exit back to
> > search results).
> 
> Later you mention 'N' and 'n' to do the same task. Or are you suggesting
> that 'a' would move to the next task after marking the current task
> read ?

Sorry, I meant for 'N' and 'P' to move between messages in a thread.

But it would make sense to also have commands to navigate to the next
and previous threads. So many actions and so few keys... :-}

> ok that explains. But with Xapian ticket 250 we would definitely want
> some keybinding that move to the next mail without updating tags.

I don't want to let a current bug shape the interface we want. But, yes,
that's a current reality.

> > Recommendation: Revert 'a' to act on all messages in a thread---not
> > only those that match the search results. Then change '*' to work by
> > walking the list and explicitly calling the same action as 'a' on
> > each line. This will provide the desired feedback and should be
> > plenty fast.
> 
> With xapian ticket 250 doing a tag update per thread is going to be
> really slow right ?

Yes, but that's already the case with '*'. The Xapian work involved
should be the same whether calling "notmuch tag" once with the whole
search string, or several times, (once for each thread).

-Carl


pgp1pwyaWRkCI.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Carl Worth]

Hi Aneesh,

Thanks for the followup.

On Fri, 04 Dec 2009 14:08:52 +0530, "Aneesh Kumar K. V"  wrote:
> > Recommendation: Make SPACE only page the current message. Recommend
> > that user use 'a' to advance to next thread, (or 'x' to exit back to
> > search results).
> 
> Later you mention 'N' and 'n' to do the same task. Or are you suggesting
> that 'a' would move to the next task after marking the current task
> read ?

Sorry, I meant for 'N' and 'P' to move between messages in a thread.

But it would make sense to also have commands to navigate to the next
and previous threads. So many actions and so few keys... :-}

> ok that explains. But with Xapian ticket 250 we would definitely want
> some keybinding that move to the next mail without updating tags.

I don't want to let a current bug shape the interface we want. But, yes,
that's a current reality.

> > Recommendation: Revert 'a' to act on all messages in a thread---not
> > only those that match the search results. Then change '*' to work by
> > walking the list and explicitly calling the same action as 'a' on
> > each line. This will provide the desired feedback and should be
> > plenty fast.
> 
> With xapian ticket 250 doing a tag update per thread is going to be
> really slow right ?

Yes, but that's already the case with '*'. The Xapian work involved
should be the same whether calling "notmuch tag" once with the whole
search string, or several times, (once for each thread).

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20091204/2e514347/attachment.pgp>

[notmuch] Notmuch's search view sucks

[Karl Wiberg]

On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth  wrote:
> And a step beyond that would support different languages for
> different emails, but that sounds like something "hard" to identify.

But probably not as hard as identifying spam. It could probably be
done with a simple Bayesian filter counting word frequencies---but
it'd be much better if somebody else had already solved the problem,
since this smells suspiciously like something that ought to be a
separate project and put in a library ... does anyone know if such a
project already exists? I know Google can do it ...

It'd be very cool to have notmuch automatically tag messages according
to what language they're in.

-- 
Karl Wiberg, kha at treskal.com
   subrabbit.wordpress.com
   www.treskal.com/kalle

[notmuch] Notmuch's search view sucks

[Aaron Ecay]

--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen:

[...]

> TextCat is in Perl.  I don't know if there's a C or C++ implementation but
> it isn't a huge piece of code - finding a good technique was the clever part
> of it.

The same algorithm is implemented in C here:
http://www.mnogosearch.org/guesser/

Licensed under the GPL and includes presets for ~50 languages.  A potential
drawback is that it doesn't handle raw HTML very well, according to the
documentation.

Aaron

Re: [notmuch] [PATCH (rebased)] Handle message renames in mail spool

[david]

At Thu, 03 Dec 2009 16:45:22 -0800,

> Anyway, I think we'll see code for that soon, so I'm not planning to
> commit the offered patch. But people really needing renames might want
> to use it for now, (and live with any performance implications it
> causes).

I could live with the performance issues, but it seems that it re-tags
every "Processed" file (renamed or not) as inbox.  This brings about
20k messages back into my inbox, which is a bit unusable.  The problem
seems to be that notmuch_database_add_message returns
NOTMUCH_STATUS_SUCCESS whether or not a new message was really added.
I don't know if there is an easy fix for this, or if it is worth
pursuing, given that the patch won't be committed.

d

P.S. do people want to be CC'd on this list, or not?


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] [PATCH 2/9] Adjust autoload comments

[James Rowe]

  Firstly, thanks for the full explanations!

On Thu, 03 Dec 2009 17:04:52 -0800, Carl Worth  wrote:
> The notmuch-folder command is definitely a nice primary interface to
> notmuch for some people. I'm seriously considering making it the view
> that one gets with "M-x notmuch" (after the notmuch-folder view gets a
> little sprucing up).

  Coming from sup and being a gmail user "emacs -f notmuch" seems like
the natural mail interface to me. Still, even if the default view
changes I can switch to just opening a tag:inbox search.

  I've left the elisp-make-autoload-file change in our builds, which
means all the ";;;###autoload" enveloped functions are available. Nobody
seems to be upset by the change.

> As for notmuch-search, I find it very convenient to have the ability to
> do a "M-x notmuch-search" (or perhaps even a simpler keybinding for it)
> From any random emacs buffer. If you don't live inside emacs, and just
> have a single emacs frame open for notmuch sake, maybe that's not as
> interesting.

  Carl, you've got me pegged.  I use the /other/ editor, I only
installed emacs for notmuch.

  For me, I've already managed to train myself to just fire up notmuch
and hit 's' when searching. The extra search buffer that method creates
makes no difference to my personal usage patterns.

-- 
Thanks,

James

Re: [notmuch] Notmuch's search view sucks

[Aaron Ecay]

--- 2009ko Abenudak 4an, Olly Betts-ek idatzi zuen:

[...]

> TextCat is in Perl.  I don't know if there's a C or C++ implementation but
> it isn't a huge piece of code - finding a good technique was the clever part
> of it.

The same algorithm is implemented in C here:
http://www.mnogosearch.org/guesser/

Licensed under the GPL and includes presets for ~50 languages.  A potential
drawback is that it doesn't handle raw HTML very well, according to the
documentation.

Aaron
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Recent (and forthcoming) improvements to the emacs interface

[Marten Veldthuis]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
>   * Much nicer looking presentation, (no more ugly reverse-video or
> underlines on the message summary line).
> 
>   * More reliable message-visibility buttons, (using RET in the first
> column of a message-summary line now works).

Not sure what happened, but:

Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
notmuch-show-view-all-mime-parts
From: camalot at picnicpark.org
To: notmuch at notmuchmail.org
Cc: Keith Amidon 
Bcc: 
Date: Fri, 27 Nov 2009 05:30:10 -0800

now collapses into:


Subject: [notmuch] [PATCH 4/9] Factor out message buffer mgmt from 
notmuch-show-view-all-mime-parts
From: Keith Amidon 

on my system (notice the From: header).

-- 
- Marten

Re: [notmuch] Notmuch's search view sucks

[Olly Betts]

Karl Wiberg writes:
> On Fri, Dec 4, 2009 at 1:29 AM, Carl Worth wrote:
> > And a step beyond that would support different languages for
> > different emails, but that sounds like something "hard" to identify.
> 
> But probably not as hard as identifying spam. It could probably be
> done with a simple Bayesian filter counting word frequencies---but
> it'd be much better if somebody else had already solved the problem,
> since this smells suspiciously like something that ought to be a
> separate project and put in a library ... does anyone know if such a
> project already exists?

There's TextCat:

http://www.let.rug.nl/vannoord/TextCat/

It looks at n-gram frequencies, and can guess pretty reliably from
even a fairly small amount of text.

TextCat is in Perl.  I don't know if there's a C or C++ implementation
but it isn't a huge piece of code - finding a good technique was the
clever part of it.

Cheers,
Olly

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:
> I just pushed out a nice set of changes to the emacs interface. Here's a
> quick summary of what you can expect to get when you next update:
> 
>   * Much nicer looking presentation, (no more ugly reverse-video or
> underlines on the message summary line).
> 
>   * More reliable message-visibility buttons, (using RET in the first
> column of a message-summary line now works).
> 
>   * Space bar fixed to advance to next open message, (it was originally
> written this way, but has been broken since we changed from global
> to local toggling of hidden message parts).
> 
>   * Showing a thread where the search matches only a subset of the
> thread now opens only the matched messages (in addition to unread
> messages).
> 
> This last feature is the big one---the rest all just happened to come
> along at the same time. One thing that I often do is read some giant
> thread and then tag a single message deep in that thread for dealing
> with later. And previously, doing a search for that tag would bring back
> the entire thread. Now, it opens only the message I'm actually looking
> for. So this is a very welcome change
> 
> And thanks to Bart Trojanowski for the groundwork for this change. I
> think the vim interface has had this feature for a while, (or would have
> if I had pushed all of Bart's changes earlier).
> 
> Meanwhile, Keith and Eric gave me some helpful feedback about the
> notmuch user-interface over lunch today, and in particular about the
> handling of the "unread" tag. Here are some of the things discussed,
> along with some things I'd like to change in response.
> 
> I'm open to suggestions on all of these, and most importantly, wanted to
> let people know about some upcoming user-interface changes before they
> were in place and potentially surprising.
> 
>   * The magic space bar is too magic. Threads are separate conversations
> so one key for paging through the current conversation shouldn't
> also switch to the next conversation, (particularly when the
> complementary key DEL doesn't reverse this behavior of SPACE).
> 
> Recommendation: Make SPACE only page the current message. Recommend
> that user use 'a' to advance to next thread, (or 'x' to exit back to
> search results).
> 
>   * The unread tag is not handled transparently enough. Both Keith and
> Eric complained of frequently being presented with messages as
> "unread" that they had read before. (And I don't want to ever have
> to manually think about whether to remove a thread as "unread".)
> 
> Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
> 'x' mark remove the "unread" tag from all messages in the current
> thread (as well as the "inbox" tag as currently). Also make 'n' and
> 'p' remove the "unread tag as well.
> 
> Followup: This frees up 'N' and 'P', so I'd like to use the for
> "next message" and "previous message" and make 'n' and 'p' do "next
> open message" and "previous open message".
> 
>   * Opening up unread messages in notmuch-show mode is not
> helpful. Keith reads a lot of high-volume mailing lists by reading
> the subject lines in search mode and then doing "* -inbox". He likes
> that notmuch remembers that these messages are still unread, but if
> he later searches for a single message that happens to be in a giant
> thread of unread messages, then he wants to see just than one
> message, not all of them.
> 
> Recommendation: Make notmuch-show-mode open *only* messages that
> match the search---not unread messages as well. At this point the
> unread tag becomes just a hint to the user and won't be explicitly
> handled differently by the interface, (other than that various
> commands will remove the unread tag if present). The unread tag is
> still useful for when searching for something like "I know I read
> this message recently".
> 
> Followup: I wonder if I would miss one feature here. If I'm
> interrupted after reading part of a giant thread, currently I can
> quite and when I come back notmuch will remember right where I was
> while reading. One way to get this behavior back would be to make
> SPACE remove the inbox tag from each message its scrolled off. I'll
> have to think about that.
> 
>   * The current 'a' key in search-mode is unreliable. It seemed like a
> good idea to make 'a' only archive messages that match the search,
> but it's a flawed idea. Imagine the following scenario: Eric is
> reading his inbox and sees some threads related to a boring
> topic. He filters down to these with "f tag:boring". He's satisfied
> with the search results, and hits 'a' on each thread and even sees
> the "inbox" tag disappear from the presentation. But then when he
> returns to his inbox search and refreshes, the boring threads
> re-appear and have the 

Re: [notmuch] Recent (and forthcoming) improvements to the emacs interface

[Aneesh Kumar K. V]

On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth  wrote:

.

> 
>   * The magic space bar is too magic. Threads are separate conversations
> so one key for paging through the current conversation shouldn't
> also switch to the next conversation, (particularly when the
> complementary key DEL doesn't reverse this behavior of SPACE).

agreed

> 
> Recommendation: Make SPACE only page the current message. Recommend
> that user use 'a' to advance to next thread, (or 'x' to exit back to
> search results).

Later you mention 'N' and 'n' to do the same task. Or are you suggesting
that 'a' would move to the next task after marking the current task read ?

> 
>   * The unread tag is not handled transparently enough. Both Keith and
> Eric complained of frequently being presented with messages as
> "unread" that they had read before. (And I don't want to ever have
> to manually think about whether to remove a thread as "unread".)
> 
> Recommendation: Drop the 'A' and 'X' keybindings and make 'a' and
> 'x' mark remove the "unread" tag from all messages in the current
> thread (as well as the "inbox" tag as currently). Also make 'n' and
> 'p' remove the "unread tag as well.


ok that explains. But with Xapian ticket 250 we would definitely want
some keybinding that move to the next mail without updating tags.


> 
> Followup: This frees up 'N' and 'P', so I'd like to use the for
> "next message" and "previous message" and make 'n' and 'p' do "next
> open message" and "previous open message".
> 
>   * Opening up unread messages in notmuch-show mode is not
> helpful. Keith reads a lot of high-volume mailing lists by reading
> the subject lines in search mode and then doing "* -inbox". He likes
> that notmuch remembers that these messages are still unread, but if
> he later searches for a single message that happens to be in a giant
> thread of unread messages, then he wants to see just than one
> message, not all of them.
> 
> Recommendation: Make notmuch-show-mode open *only* messages that
> match the search---not unread messages as well. At this point the
> unread tag becomes just a hint to the user and won't be explicitly
> handled differently by the interface, (other than that various
> commands will remove the unread tag if present). The unread tag is
> still useful for when searching for something like "I know I read
> this message recently".
> 
> Followup: I wonder if I would miss one feature here. If I'm
> interrupted after reading part of a giant thread, currently I can
> quite and when I come back notmuch will remember right where I was
> while reading. One way to get this behavior back would be to make
> SPACE remove the inbox tag from each message its scrolled off. I'll
> have to think about that.
> 
>   * The current 'a' key in search-mode is unreliable. It seemed like a
> good idea to make 'a' only archive messages that match the search,
> but it's a flawed idea. Imagine the following scenario: Eric is
> reading his inbox and sees some threads related to a boring
> topic. He filters down to these with "f tag:boring". He's satisfied
> with the search results, and hits 'a' on each thread and even sees
> the "inbox" tag disappear from the presentation. But then when he
> returns to his inbox search and refreshes, the boring threads
> re-appear and have the inbox tag again. Ugh. The presentation is
> inconsistent and things just feel unreliable and broken.
> 
> And a related issue:
> 
>   * The '*' key in search-mode doesn't provide any feedback that it has
> actually done anything, (none of the added/removed tags are changed
> in the presentation). And hitting '=' isn't necessarily ideal since
> it can make things irretrievably disappear, ('a' is different since
> it allows the user to confirm that things are good before making
> results disappear with '='). [*]
> 
> Recommendation: Revert 'a' to act on all messages in a thread---not
> only those that match the search results. Then change '*' to work by
> walking the list and explicitly calling the same action as 'a' on
> each line. This will provide the desired feedback and should be
> plenty fast.

With xapian ticket 250 doing a tag update per thread is going to be
really slow right ?


> 
> Note: There are still use cases where the user might want to modify
> the tags only on messages matching the search, (think, "remove from
> inbox all messages from:someone"). So I'm aware that there's still a
> hole in functionality here, but I really want to fix the current
> inconsistency in the presentation. And I'm open to further
> suggestions here.
> 
> Let me know if any of the above seems crazy,
> 

-aneesh
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/