[PATCH] emacs: Accommodate message-mode updates.
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.
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
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.
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
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
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
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
[notmuch] semi-usable notmuch-gtk client
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
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
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
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.
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
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
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
