[PATCH] emacs: Accommodate message-mode updates.

2010-11-19 Thread Aneesh Kumar K. V
On Fri, 19 Nov 2010 16:06:40 +, David Edmondson  wrote:
> On Fri, 19 Nov 2010 21:31:36 +0530, "Aneesh Kumar K. V"  linux.vnet.ibm.com> wrote:
> > On Tue, 16 Nov 2010 17:51:38 +, David Edmondson  wrote:
> > > Message mode uses a different name for composition buffers in newer
> > > versions of emacs. Allow for this when causing the composition window
> > > to overlay the viewing window.
> > > ---
> > > 
> > > I don't understand why Aneesh chose to use `add-hook' and `purecopy'.
> > 
> > So what when i have unset mail added via .emacs even the older version
> > will work. making sure if the name change again i can fix it by a .emacs
> > update rather than notmuch code update.
> 
> What would you add to .emacs?
> 

In custom-set-variable i have the below

 '(same-window-buffer-names (quote ("*unsent mail*" "*shell*" "*mail*" 
"*inferior-lisp*" "*ielm*" "*scheme*")))
 '(same-window-regexps (quote ("\\*rsh-[^-]*\\*\\(\\|<[0-9]*>\\)" 
"\\*telnet-.*\\*\\(\\|<[0-9]+>\\)" "^\\*rlogin-.*\\*\\(\\|<[0-9]+>\\)" 
"\\*info\\*\\(\\|<[0-9]+>\\)" "\\*gud-.*\\*\\(\\|<[0-9]+>\\)" 
"\\`\\*Customiz.*\\*\\'" "\\*unsent mail .*")))


-aneesh


[PATCH] emacs: Accommodate message-mode updates.

2010-11-19 Thread Aneesh Kumar K. V
On Tue, 16 Nov 2010 17:51:38 +, David Edmondson  wrote:
> Message mode uses a different name for composition buffers in newer
> versions of emacs. Allow for this when causing the composition window
> to overlay the viewing window.
> ---
> 
> I don't understand why Aneesh chose to use `add-hook' and `purecopy'.

So what when i have unset mail added via .emacs even the older version
will work. making sure if the name change again i can fix it by a .emacs
update rather than notmuch code update.



> 
>  emacs/notmuch-mua.el |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index dc7b386..70c8dff 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -88,7 +88,7 @@ list."
>  (let
>   ;; Overlay the composition window on that being used to read
>   ;; the original message.
> - ((same-window-regexps '("\\*mail .*")))
> + ((same-window-regexps '("\\*mail .*" "\\*unsent mail .*")))
>(notmuch-mua-mail (mail-header 'to headers)
>   (mail-header 'subject headers)
>   (message-headers-to-generate headers t '(to subject


-aneesh


Re: [PATCH] emacs: Accommodate message-mode updates.

2010-11-19 Thread Aneesh Kumar K. V
On Tue, 16 Nov 2010 17:51:38 +, David Edmondson d...@dme.org wrote:
 Message mode uses a different name for composition buffers in newer
 versions of emacs. Allow for this when causing the composition window
 to overlay the viewing window.
 ---
 
 I don't understand why Aneesh chose to use `add-hook' and `purecopy'.

So what when i have unset mail added via .emacs even the older version
will work. making sure if the name change again i can fix it by a .emacs
update rather than notmuch code update.



 
  emacs/notmuch-mua.el |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
 index dc7b386..70c8dff 100644
 --- a/emacs/notmuch-mua.el
 +++ b/emacs/notmuch-mua.el
 @@ -88,7 +88,7 @@ list.
  (let
   ;; Overlay the composition window on that being used to read
   ;; the original message.
 - ((same-window-regexps '(\\*mail .*)))
 + ((same-window-regexps '(\\*mail .* \\*unsent mail .*)))
(notmuch-mua-mail (mail-header 'to headers)
   (mail-header 'subject headers)
   (message-headers-to-generate headers t '(to subject


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


Re: [PATCH] emacs: Accommodate message-mode updates.

2010-11-19 Thread Aneesh Kumar K. V
On Fri, 19 Nov 2010 16:06:40 +, David Edmondson d...@dme.org wrote:
 On Fri, 19 Nov 2010 21:31:36 +0530, Aneesh Kumar K. V 
 aneesh.ku...@linux.vnet.ibm.com wrote:
  On Tue, 16 Nov 2010 17:51:38 +, David Edmondson d...@dme.org wrote:
   Message mode uses a different name for composition buffers in newer
   versions of emacs. Allow for this when causing the composition window
   to overlay the viewing window.
   ---
   
   I don't understand why Aneesh chose to use `add-hook' and `purecopy'.
  
  So what when i have unset mail added via .emacs even the older version
  will work. making sure if the name change again i can fix it by a .emacs
  update rather than notmuch code update.
 
 What would you add to .emacs?
 

In custom-set-variable i have the below

 '(same-window-buffer-names (quote (*unsent mail* *shell* *mail* 
*inferior-lisp* *ielm* *scheme*)))
 '(same-window-regexps (quote (\\*rsh-[^-]*\\*\\(\\|[0-9]*\\) 
\\*telnet-.*\\*\\(\\|[0-9]+\\) ^\\*rlogin-.*\\*\\(\\|[0-9]+\\) 
\\*info\\*\\(\\|[0-9]+\\) \\*gud-.*\\*\\(\\|[0-9]+\\) 
\\`\\*Customiz.*\\*\\' \\*unsent mail .*)))


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


[PATCH 3/3] notmuch: Add support for listing the parent message

2010-11-04 Thread Aneesh Kumar K. V
On Thu, 04 Nov 2010 09:28:40 +, David Edmondson  wrote:
> On Wed, 27 Oct 2010 22:56:57 +0530, "Aneesh Kumar K.V"  linux.vnet.ibm.com> wrote:
> > From: Aneesh Kumar K.V 
> > 
> > When you have long thread, it would be nice to be able to
> > show the message to which the current message is a reply
> 
> The patch fires up a new search, destroying my context. Shouldn't the
> parent message be visible in the current thread and, if so, perhaps just
> searching in the current buffer for it (and jumping back there) be
> possible? (Maybe even with a key to pop back to the child easily.)
> 

It should actually stack up. That is, it fires up a new search but then a
'q' should bring back the old context. One of the thing i really
wanted to keep was the ability to go back to the old context with a key
binding which in this case is achieved by 'q'

-aneesh


Re: [PATCH 3/3] notmuch: Add support for listing the parent message

2010-11-04 Thread Aneesh Kumar K. V
On Thu, 04 Nov 2010 09:28:40 +, David Edmondson d...@dme.org wrote:
 On Wed, 27 Oct 2010 22:56:57 +0530, Aneesh Kumar K.V 
 aneesh.ku...@linux.vnet.ibm.com wrote:
  From: Aneesh Kumar K.V aneesh.ku...@gmail.com
  
  When you have long thread, it would be nice to be able to
  show the message to which the current message is a reply
 
 The patch fires up a new search, destroying my context. Shouldn't the
 parent message be visible in the current thread and, if so, perhaps just
 searching in the current buffer for it (and jumping back there) be
 possible? (Maybe even with a key to pop back to the child easily.)
 

It should actually stack up. That is, it fires up a new search but then a
'q' should bring back the old context. One of the thing i really
wanted to keep was the ability to go back to the old context with a key
binding which in this case is achieved by 'q'

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


Wrapping up the 0.3 release

2010-04-26 Thread Aneesh Kumar K. V
On Sat, 24 Apr 2010 08:37:11 -0700, Carl Worth  wrote:
> I pushed hard to get most everything we wanted for 0.3 done yesterday,
> (which was one week since 0.2). I think we're still within the tolerance
> of my published "about a week" schedule, but I would like to wrap things
> up soon.
> 
> Here are the features that I still have left in my queue at this point:
> 
>   * improve from-header guessing
> 
> Dirk is looking into fixing a segfault found by the test suite here
> 
>   * Fcc, Maildir, and Emacs message-mode -- a bit of code
> 
> This is next on my list to apply. Thanks for the extra testing!
> 
> There are a few other features that people had proposed but that didn't
> pass review yet. If people follow-up with those quickly, they can still
> go in. Otherwise, there's another new merge window coming up soon!
> 
> Meanwhile, I'm aware of two regressions I'd like to see fixed before
> 0.3:
> 
>   * Reply is now splitting the window
> 
> We're copying the original message into the new reply buffer, so
> what's the advantage of splitting here?

This actually have a disadvantage that after sending the mail i have to
explicitly kill the buffer


> 
>   * Composing a new message with 'm' brings up headers in a scrambled
> order.
> 
> A minor point, but it would be nice to fix this.
> 
> Finally, any of the tweaks I suggested to notmuch-hello mode would be
> quite welcome. I might take a whack at some of these.
> 
> Then, there's the task of writing up NEWS. Dirk started helping with
> that, which I appreciate. If anyone else wants to write up descriptions
> of their favorite features that have been merged, that would be great.

Another issue i found was


* A thread with only one message doesn't show the message body by
  default. I need to use 'h' key binding to show the message
  body. Multiple message thread seems to work fine.


-aneesh


[notmuch] JSON based emacs UI

2010-03-29 Thread Aneesh Kumar K. V
On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson  wrote:
> On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo  yahoo.com.br> wrote:
> > David Edmondson  wrote:
> > > 'RET' anywhere in the message is supposed to toggle visibility of the
> > > message. That was not working perfectly - a little forced redisplay
> > > helped (just pushed).
> > > 
> > > Toggling the visibility of headers is done with 'h'. There's currently
> > > no way to do that by pressing 'RET' somewhere. (You can also toggle the
> > > body with 'b'.)
> > 
> > I fear this is not correct. I cloned notmuch from Carl's git repository,
> > and whenever I press 'RET' while the point is over the subject line, the
> > result is the same as pressing 'h': the subject information gets toggled.
> 
> Is this considered a feature that blocks people from switching to the
> JSON based UI?
> 

For me it is not an issue and i already switched to jason based ui. The
diff-mode for inline patch itself is a big motivation for me to switch.

-aneesh


Re: [notmuch] JSON based emacs UI

2010-03-29 Thread Aneesh Kumar K. V
On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson d...@dme.org wrote:
 On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo fcarr...@yahoo.com.br 
 wrote:
  David Edmondson d...@dme.org wrote:
   'RET' anywhere in the message is supposed to toggle visibility of the
   message. That was not working perfectly - a little forced redisplay
   helped (just pushed).
   
   Toggling the visibility of headers is done with 'h'. There's currently
   no way to do that by pressing 'RET' somewhere. (You can also toggle the
   body with 'b'.)
  
  I fear this is not correct. I cloned notmuch from Carl's git repository,
  and whenever I press 'RET' while the point is over the subject line, the
  result is the same as pressing 'h': the subject information gets toggled.
 
 Is this considered a feature that blocks people from switching to the
 JSON based UI?
 

For me it is not an issue and i already switched to jason based ui. The
diff-mode for inline patch itself is a big motivation for me to switch.

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


[notmuch] JSON based emacs UI

2010-03-26 Thread Aneesh Kumar K. V
On Mon, 22 Mar 2010 14:47:39 +, David Edmondson  wrote:

I found another issue. In the notmuch-show-mode "RET" key on from and
subject doesn't seem to work.

For ex: for the last message "RET" key on from doesn't fold the message.
For all the message "RET" key on subject doesn't show the message
header(from cc and to list)

-aneesh


[notmuch] JSON based emacs UI

2010-03-26 Thread Aneesh Kumar K. V
On Thu, 25 Mar 2010 09:14:09 +, David Edmondson  wrote:
> On Thu, 25 Mar 2010 10:11:38 +0530, "Aneesh Kumar K. V"  linux.vnet.ibm.com> wrote:
> > Is there a way to get the inline patches shown similar to
> > diff-mode not just the attached patches ?
> 
> A new hook function for text/plain parts called
> `notmuch-wash-inline-patch' is added that attempts to do this by
> converting the inline patch into a fake attachment.
> 
> It guesses whether a buffer includes a patch and also the extent of that
> patch, so it's a bit risky and hence not enabled by default. It is only
> lightly tested. You can try it out by setting:
> 
>(setq notmuch-show-insert-text/plain-hook
>  '(notmuch-wash-wrap-long-lines
>notmuch-wash-tidy-citations
>notmuch-wash-compress-blanks
>notmuch-wash-inline-patch
>notmuch-wash-markup-citations))
> 
> The order is important!
> 

That worked. Thanks. BTW is there a way to get '=' to reload the thread
details. Something similar to notmuch-search-refresh-view. for the show
window. That would make sure i can get the tag updated tag details by
using = key. right now it is difficult to find out whether i "unread"
tag is removed from a message or not. The best fix would be to show the
updated tag dynamically 

-aneesh


Re: [notmuch] JSON based emacs UI

2010-03-26 Thread Aneesh Kumar K. V
On Mon, 22 Mar 2010 14:47:39 +, David Edmondson d...@dme.org wrote:

I found another issue. In the notmuch-show-mode RET key on from and
subject doesn't seem to work.

For ex: for the last message RET key on from doesn't fold the message.
For all the message RET key on subject doesn't show the message
header(from cc and to list)

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


[notmuch] JSON based emacs UI

2010-03-25 Thread Aneesh Kumar K. V
On Wed, 24 Mar 2010 07:32:41 +, David Edmondson  wrote:
> On Mon, 22 Mar 2010 14:47:39 +, David Edmondson  wrote:
> > I've pushed the first stage of a JSON based emacs UI to the repository
> > at http://github.com/dme/notmuch (it's in the "master" branch).
> > 
> > This is intended to be functionally equivalent to the current UI, though
> > HTML display is not present (see below).
> > 
> > This is lightly tested, but if anyone else wants to give it a try I
> > would be interested in feedback. There were a couple of places in the
> > current code where I wasn't completely sure of the intention, so I may
> > have inadvertently diverged (notmuch-show-rewind is a good example).
> > 
> > For HTML display and other improved MIME support my intention is to
> > enhance notmuch to allow single parts to be output (something like:
> > "notmuch show --part=2 id:k74hf87df.fsf at fish.org") and use that from the
> > UI code. No idea when I'll get to it, though.
> 
> "notmuch part --part=2 id:k74hf87df.fsf at fish.org" support is pushed now
> and notmuch-show.el updated to use it.
> 
> An attempt is made to inline all parts, including guessing the type of
> application/octet-stream parts using mailcap (so a file called
> "foo.patch" sent as type application/octet-stream will be displayed
> using diff-mode formatting).
> 

Is there a way to get the inline patches shown similar to
diff-mode not just the attached patches ?

-aneesh


Re: [notmuch] JSON based emacs UI

2010-03-25 Thread Aneesh Kumar K. V
On Thu, 25 Mar 2010 09:14:09 +, David Edmondson d...@dme.org wrote:
 On Thu, 25 Mar 2010 10:11:38 +0530, Aneesh Kumar K. V 
 aneesh.ku...@linux.vnet.ibm.com wrote:
  Is there a way to get the inline patches shown similar to
  diff-mode not just the attached patches ?
 
 A new hook function for text/plain parts called
 `notmuch-wash-inline-patch' is added that attempts to do this by
 converting the inline patch into a fake attachment.
 
 It guesses whether a buffer includes a patch and also the extent of that
 patch, so it's a bit risky and hence not enabled by default. It is only
 lightly tested. You can try it out by setting:
 
(setq notmuch-show-insert-text/plain-hook
  '(notmuch-wash-wrap-long-lines
notmuch-wash-tidy-citations
notmuch-wash-compress-blanks
notmuch-wash-inline-patch
notmuch-wash-markup-citations))
 
 The order is important!
 

That worked. Thanks. BTW is there a way to get '=' to reload the thread
details. Something similar to notmuch-search-refresh-view. for the show
window. That would make sure i can get the tag updated tag details by
using = key. right now it is difficult to find out whether i unread
tag is removed from a message or not. The best fix would be to show the
updated tag dynamically 

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


Re: [notmuch] JSON based emacs UI

2010-03-24 Thread Aneesh Kumar K. V
On Wed, 24 Mar 2010 07:32:41 +, David Edmondson d...@dme.org wrote:
 On Mon, 22 Mar 2010 14:47:39 +, David Edmondson d...@dme.org wrote:
  I've pushed the first stage of a JSON based emacs UI to the repository
  at http://github.com/dme/notmuch (it's in the master branch).
  
  This is intended to be functionally equivalent to the current UI, though
  HTML display is not present (see below).
  
  This is lightly tested, but if anyone else wants to give it a try I
  would be interested in feedback. There were a couple of places in the
  current code where I wasn't completely sure of the intention, so I may
  have inadvertently diverged (notmuch-show-rewind is a good example).
  
  For HTML display and other improved MIME support my intention is to
  enhance notmuch to allow single parts to be output (something like:
  notmuch show --part=2 id:k74hf87df@fish.org) and use that from the
  UI code. No idea when I'll get to it, though.
 
 notmuch part --part=2 id:k74hf87df@fish.org support is pushed now
 and notmuch-show.el updated to use it.
 
 An attempt is made to inline all parts, including guessing the type of
 application/octet-stream parts using mailcap (so a file called
 foo.patch sent as type application/octet-stream will be displayed
 using diff-mode formatting).
 

Is there a way to get the inline patches shown similar to
diff-mode not just the attached patches ?

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


[notmuch] Notmuch performance (literally, in my case)

2010-03-16 Thread Aneesh Kumar K. V
On Tue, 16 Mar 2010 08:37:54 -0700 (PDT), Ben Gamari  wrote:
> On Tue, 16 Mar 2010 11:08:47 +, Olly Betts  wrote:
> > For the issue of a background task interfering with interactive use, the 
> > feel
> > arguably matters more than the throughput.
> > 
> > I'll probably put that patch in 1.0.19, and look at moving all the 
> > fdatasync()
> > calls together.  This is http://trac.xapian.org/ticket/426 BTW.
> > 
> > The kernel should be able to handle this workload better though, so I would
> > say it was worthwhile to bring up on LKML if you have the energy.  It 
> > certainly
> > isn't just you, as apt-xapian-index seems to trigger it for some Ubuntu 
> > users,
> > and madduck mentioned it on #notmuch a week or so ago.
> 
> Alright. This issue has been bothering me for a very long time and it's 
> frankly
> pretty pathetic how badly the kernel falls apart under this sort of workload.
> I just wrote up a message (4b9fa440.12135e0a.7fc8.e745 at mx.google.com), 
> so
> we'll see what happens. In the past kernel developers have been very eager to
> write this issue off as not reproducible enough (perhaps wisely), so if anyone
> has anything to say, please contribute it to the thread.
> 

Ext3 fsync related issue is a know problem due to the way journalling is
handled in ext3. The solution for that would be data=writeback ( with
its loss of data integrity ) or not yet upstreamed data=guarded. Another
option would be to try ext4 which should not be impacted that badly by
the data=ordered journalled mode

-aneesh


Re: [notmuch] Notmuch performance (literally, in my case)

2010-03-16 Thread Aneesh Kumar K. V
On Tue, 16 Mar 2010 08:37:54 -0700 (PDT), Ben Gamari bgamari.f...@gmail.com 
wrote:
 On Tue, 16 Mar 2010 11:08:47 +, Olly Betts o...@survex.com wrote:
  For the issue of a background task interfering with interactive use, the 
  feel
  arguably matters more than the throughput.
  
  I'll probably put that patch in 1.0.19, and look at moving all the 
  fdatasync()
  calls together.  This is http://trac.xapian.org/ticket/426 BTW.
  
  The kernel should be able to handle this workload better though, so I would
  say it was worthwhile to bring up on LKML if you have the energy.  It 
  certainly
  isn't just you, as apt-xapian-index seems to trigger it for some Ubuntu 
  users,
  and madduck mentioned it on #notmuch a week or so ago.
 
 Alright. This issue has been bothering me for a very long time and it's 
 frankly
 pretty pathetic how badly the kernel falls apart under this sort of workload.
 I just wrote up a message (4b9fa440.12135e0a.7fc8.e...@mx.google.com), so
 we'll see what happens. In the past kernel developers have been very eager to
 write this issue off as not reproducible enough (perhaps wisely), so if anyone
 has anything to say, please contribute it to the thread.
 

Ext3 fsync related issue is a know problem due to the way journalling is
handled in ext3. The solution for that would be data=writeback ( with
its loss of data integrity ) or not yet upstreamed data=guarded. Another
option would be to try ext4 which should not be impacted that badly by
the data=ordered journalled mode

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


[notmuch] [PATCH -V3] notmuch.el: Support for customizing search result display

2010-02-11 Thread Aneesh Kumar K. V
On Thu, 11 Feb 2010 22:11:46 +0530, "Aneesh Kumar K.V"  wrote:
> From: Aneesh Kumar K.V 
> 
> This patch helps in customizing search result display
> similar to mutt's index_format. The customization is done
> by defining an alist as below
> 
> (setq notmuch-search-result-format '(("date" . "%s ")
>("authors" . "%-40s ")
>("subject" . "%s ")
>("tags" . "(%s)")))
> 
> The supported keywords are date, count, authors, subject and tags.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  notmuch.el |   56 +++-
>  1 files changed, 39 insertions(+), 17 deletions(-)
> 
> diff --git a/notmuch.el b/notmuch.el
> index 040997e..a4a89ac 100644
> --- a/notmuch.el
> +++ b/notmuch.el
> @@ -141,6 +141,19 @@ remaining lines into a button.")
>  (defvar notmuch-show-body-read-visible nil)
>  (defvar notmuch-show-citations-visible nil)
>  (defvar notmuch-show-signatures-visible nil)
> +(defcustom notmuch-search-result-format
> +  '(("date" . "%s")
> +("count" . "%-7s")
> +("authors" . "%-40s")
> +("subject" . "%s")
> +("tags" . "%s"))

I missed a '(' around tags. So the last line should be

("tags" . "(%s)"))

-aneesh


[notmuch] [PATCH] notmuch.el: colorize lines in notmuch-search based on thread tags.

2010-02-07 Thread Aneesh Kumar K. V
On Thu, 04 Feb 2010 07:07:26 -0500, Jameson Rollins  wrote:
> Arbitrary font faces can be specified for given thread tags.  By
> default, no coloring is applied.  To specify coloring, place something
> like this in your .emacs:
> 
> (setq notmuch-search-line-faces '(("delete" . '(:foreground "red"))
>   ("unread" . '(:foreground "green"
> 
> Order matters: line faces listed first will take precedence (in the
> example above, a thread tagged both "delete" and "unread" will be
> colored red, since the "delete" face is listed before the "unread").


Doesn't 92c4dcc641e9dfb5f65026ebae5cedc8eb1d9e21 help you achive
something similar ?

-aneesh


[notmuch] [PATCH -v2] notmuch.el: Support for customizing search result display

2009-12-11 Thread Aneesh Kumar K. V
On Wed,  2 Dec 2009 18:19:38 +0530, "Aneesh Kumar K.V"  wrote:
> From: Aneesh Kumar K.V 
> 
> This patch helps in customizing search result display
> similar to mutt's index_format. The customization is done
> by defining an alist as below
> 
> (setq notmuch-search-result-format '(("date" . "%s ")
>("authors" . "%-40s ")
>("subject" . "%s ")
>("tags" . "(%s)")))
> 
> The supported keywords are date, count, authors, subject and tags.
> 

Any update on this patch . I would like to get this merged as well

-aneesh


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

2009-12-11 Thread Aneesh Kumar K. V
On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth  wrote:
> On Thu,  3 Dec 2009 14:16:44 +0530, "Aneesh Kumar K.V"  linux.vnet.ibm.com> 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?

I sent an updated patch which did the above with less code duplication. Any
chance of getting this merged ?

-aneesh


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

2009-12-10 Thread Aneesh Kumar K. V
On Fri, 04 Dec 2009 11:07:54 -0800, Carl Worth cwo...@cworth.org wrote:
 On Thu,  3 Dec 2009 14:16:44 +0530, Aneesh Kumar K.V 
 aneesh.ku...@linux.vnet.ibm.com wrote:
  From: Aneesh Kumar K.V aneesh.ku...@gmail.com
  
  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?

I sent an updated patch which did the above with less code duplication. Any
chance of getting this merged ?

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


Re: [notmuch] [PATCH -v2] notmuch.el: Support for customizing search result display

2009-12-10 Thread Aneesh Kumar K. V
On Wed,  2 Dec 2009 18:19:38 +0530, Aneesh Kumar K.V 
aneesh.ku...@linux.vnet.ibm.com wrote:
 From: Aneesh Kumar K.V aneesh.ku...@gmail.com
 
 This patch helps in customizing search result display
 similar to mutt's index_format. The customization is done
 by defining an alist as below
 
 (setq notmuch-search-result-format '((date . %s )
(authors . %-40s )
(subject . %s )
(tags . (%s
 
 The supported keywords are date, count, authors, subject and tags.
 

Any update on this patch . I would like to get this merged as well

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


[notmuch] semi-usable notmuch-gtk client

2009-12-07 Thread Aneesh Kumar K. V
On Fri, 27 Nov 2009 19:58:38 +0200, Baruch Even  wrote:
> Hi,
> 
> I added a quick hack to show a message thread in notmuch-gtk and this 
> makes it semi-usable. I don't actually parse the reply of notmuch-show 
> but it's already passably usable to read mail.
> 

While discussing notmuch with some of the gnome developers they pointed
me to http://live.gnome.org/Anjal/ . The interface is suited to the way
notmuch displays threads. So i guess it would really cool if we can get
anjal to use nomuch as one of the backend.

That should also make sure you get a working mailclient in gtk with
minimal changes

-aneesh


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

2009-12-04 Thread 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] Recent (and forthcoming) improvements to the emacs interface

2009-12-04 Thread 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


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

2009-12-04 Thread Aneesh Kumar K. V
On Thu, 03 Dec 2009 14:15:07 -0800, Carl Worth cwo...@cworth.org 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/mailman/listinfo/notmuch


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

2009-11-30 Thread Aneesh Kumar K. V
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.
> 
> Signed-off-by: Kan-Ru Chen 
> ---
>  notmuch.el |   20 
>  1 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/notmuch.el b/notmuch.el
> index 65473ba..730538c 100644
> --- a/notmuch.el
> +++ b/notmuch.el
> @@ -714,9 +714,8 @@ which this thread was originally shown."
>(let ((beg (point-marker))
>  (btn nil))
>  (end-of-line)
> -; Inverse video for subject
> -(overlay-put (make-overlay beg (point)) 'face '(:inverse-video t))
> -(setq btn (make-button beg (point) :type 
> 'notmuch-button-body-toggle-type))
> +(setq btn (make-button beg (point) :type 'notmuch-button-body-toggle-type
> +   'face 'notmuch-show-message-summary-face))
>  (forward-line 1)
>  (end-of-line)
>  (let ((beg-hidden (point-marker)))
> @@ -739,7 +738,8 @@ which this thread was originally shown."
>(forward-line)
>(make-button (line-beginning-position) (line-end-position)
>  'invisibility-spec (cons invis-spec t)
> -:type 'notmuch-button-headers-toggle-type))
> +:type 'notmuch-button-headers-toggle-type
> +'face 'notmuch-show-message-headers-face))
>  (goto-char end)
>  (insert "\n")
>   (set-marker beg nil)
> @@ -959,6 +959,18 @@ thread from that buffer can be show when done with this 
> one)."
>"Notmuch search mode face used to highligh tags."
>:group 'notmuch)
> 
> +(defface notmuch-show-message-summary-face
> +  '((default
> +(:bold t :inverse-video t)))
> +  "Notmuch show mode face used to highlight summary line."
> +  :group 'notmuch)
> +
> +(defface notmuch-show-message-headers-face
> +  '((default
> + (:bold t)))
> +  "Notmuch show mode face used to highlight header lines."
> +  :group 'notmuch)
> +
>  (defvar notmuch-tag-face-alist nil
>"List containing the tag list that need to be highlighed")
> 

The subject line is already have a font face value attached.
message-header-name to show the name of the header and
message-header-subject to show the subject details.

-aneesh  


[notmuch] OpenPGP support

2009-11-26 Thread Aneesh Kumar K. V
On Thu, 26 Nov 2009 01:01:32 -0500, Jameson Graef Rollins  wrote:
> On Mon, Nov 23, 2009 at 08:00:09AM -0500, Jameson Graef Rollins wrote:
> > Hi, folks.  I know it's a hairy problem, but has anyone started
> > looking into OpenPGP support for notmuch?
> 
> Hey, folks.  I wanted to try to follow up on this question.
> 
> I would really like to start using notmuch with emacs beyond just
> testing, but I really need to be able to handle/read/send mail with
> PGP/MIME encoded attachments.  Do folks have any suggestions on how to
> handle this?  Is there a separate emacs mode that people use for
> signing/verifying/{de,en}crypting mail buffers, or is this something
> that is going to have to be integrated into the notmuch mode?  I guess
> the notmuch-show mode at least will need to do some verifying and
> decrypting.
> 
> I've noticed that some people on this list sign their mails.  Are
> those of you that do using notmuch?  If so, I would love to learn how
> you handle it.  Thanks so much for the info.
> 

message-mode can sign the message using C-c RET C-s
which is mml-secure-message-sign


-aneesh
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: 



[notmuch] [PATCH -v4] notmuch.el: Add face support to search and show mode

2009-11-25 Thread Aneesh Kumar K. V
On Tue, 24 Nov 2009 21:24:07 -0800, Alexander Botero-Lowry  wrote:
> On Wed, 25 Nov 2009 10:28:00 +0530, "Aneesh Kumar K.V"  linux.vnet.ibm.com> wrote:
> > This add two faces, notmuch-show-subject-face and
> > notmuch-tag-face. The first face is used to show the subject
> > line in the notmuch-show-mode and the second one to show tags
> > in the notmuch-search-mode.
> > 
> First, I definetly think fontification is the way to go instead of
> the adhoc/crappy way that cworth and I have been doing this in the
> past.
> 
> [snip]
> 
> > +(defvar notmuch-show-font-lock-keywords
> > +  (list ;; header in font-lock-type-face
> > +   (list "\\(Subject:.*$\\)"
> > +'(1  'notmuch-show-subject-face)))
> > +  "Additonal expression to hightlight in notmuch-show-mode")
> > +
> So what happens if I have Subject:  in my message?

It will highlight them too. I initially tried to highlight it only
in the header fields. But then my elisp is not good to find out
how to do it for the full message. That is we need to search the
header area of each message and highlight specific fields. And all
the message fall in the same buffer. 


> We already ran
> into a problem where a patch sent the list that included notmuch control
> character caused it to go into an infinite loop, I'd prefer our
> fontification code be a bit more resilient. At the very least this
> should use the font-lock syntax tables stuff to only do header
> fontification when inside the header block. This would probably require
> that fontification occur before the message is post-processed by 
> notmuch-show to remove the section markers etc.

Highlighting specific part of the email should not get any trouble
like infinite loop. Unless somebody figure out how to make elisp 
highlight specific area, it would be nice to have the patch applied.
I really found it to help me when reading mails.


> 
> Also +1 for more subduded colors than red. :) Possibly consider copying
> the message-mode colors, so that there is a bit of consistency between
> sending and viewing mail? Might even be able to steal the message-mode
> faces by importing their symbols.
> 

I use yellow with black background. It is difficult to find a color that
everybody likes. Infact once of the reason the patch was not applied
till now was yellow may the subject line not readable. So i went for
read which kind of looked fine with white background.



> [snip]
> 
> >  (defun notmuch-search-mode ()
> >"Major mode for searching mail with notmuch.
> > @@ -865,7 +888,18 @@ global search.
> >(setq truncate-lines t)
> >(setq major-mode 'notmuch-search-mode
> > mode-name "notmuch-search")
> > -  (setq buffer-read-only t))
> > +  (setq buffer-read-only t)
> > +  (if (not notmuch-tag-face-alist)
> > +  (add-to-list 'notmuch-search-font-lock-keywords (list
> > +   "\\(([^)]*)$\\)" '(1  'notmuch-tag-face)))
> This way of detecting the tags seems ok, but I think it would be nicer
> if it could be done even more deterministically. :) One idea that be
> neat is to have a --format=sexp for notmuch search, which exports sexps
> (probably alists, but could be some other format) for the search results
> that can just be eval'd and processed in a cleaner way (and would also
> make for nicer APIs in emacs for querying notmuch itself). Actually I
> really like the idea of a sexp output mode for show too, instead of the
> markers *plots*
> 
> > +(progn
> > +  (setq notmuch-search-tags (mapcar 'car notmuch-tag-face-alist))
> > +  (loop for notmuch-search-tag  in notmuch-search-tags
> > +do (add-to-list 'notmuch-search-font-lock-keywords (list
> > +   (concat "\\(" notmuch-search-tag "\\)")
> > +   `(1  ,(cdr (assoc notmuch-search-tag 
> > notmuch-tag-face-alist
> > +  (set (make-local-variable 'font-lock-defaults)
> > + '(notmuch-search-font-lock-keywords t)))
> >  
> I don't really see the point of fontifying all tags the same way if no
> tag-faces have been set, especially if none of the rest of the search
> results are fontified.

This was done as per Carl's request. The idea was to make tags stand out
from rest of the subject. 

-aneesh