RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Jesse Rosenthal
On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal  
wrote:
> Tach is a minor mode that adds mutt-like attachment handling to
> message mode. It's not notmuch specific, but I wrote it to use with
> notmuch, and I thought it might be of use to some on the list.

I wanted to see if there would be any interest in adding this to notmuch
in 0.4 or after. It makes composing messages with attachments much more
pleasant that using raw mml-mode, and would likely be much more
accomodating to new users. With the new notmuch-mua hooks, it would be
easy to turn on and off as well. I've been using it for a number of
months, and have not had any problems with it.

One issue to note: if you start composing a message with tach-mode
enabled, and then disable it, the attachments you added with tach won't
get added properly (there will just be a plaintext list of them at the
the bottom of the message after a separator). In other words, tach
converts the attachment list on sending, just as message-mode adds
headers, removes "text follows this line", etc. This doesn't seem like
an issue to me (a message started by message-mode can't be sent by
another MUA either) but I did want to bring it to people's attention.

If there is interest, I would take the necessary steps to integrate it
and prepare a patch.

All best,
Jesse


Kudos! Also: +1 PGP!

2010-04-25 Thread Darren McGuicken
I just wanted to drop a quick mail to the list to give you all my huge
thanks for this already astonishingly useful tool!  

Like a few others, it seems, I arrived here after reading a
not-very-grumpy review in the Grumpy Editor series[1].
Everything-is-a-search combined with CLI access?!  Sold!

I've been slowly moving all my day-to-day mailing needs to notmuch over
the last month and the only thing I'm missing is native message
decryption and verification support - is this being actively worked on,
I haven't seen it mentioned in a while?  Or is it feasible to add this
as a target for an upcoming merge window?  How far away are we from
something workable - are we just(!) looking for someone to stitch the
code together or do we need to brainstorm a little more exactly what the
approach is likely to be?

In the meantime, I find myself using the snippet from Tassilo in:

id:87zl6cl595.fsf at thinkpad.tsdh.de

Which lets me jump to the selected encrypted message in Gnus and have it
in turn auto-decrypt the text.  Works well but does need a second mail
program ;-)


[1] http://lwn.net/Articles/380073/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100425/4d76546e/attachment.pgp>


RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Dirk Hohndel
On Sun, 25 Apr 2010 21:06:01 -0400, Jesse Rosenthal  
wrote:
> On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal  
> wrote:
> > Tach is a minor mode that adds mutt-like attachment handling to
> > message mode. It's not notmuch specific, but I wrote it to use with
> > notmuch, and I thought it might be of use to some on the list.
> 
> I wanted to see if there would be any interest in adding this to notmuch
> in 0.4 or after. It makes composing messages with attachments much more
> pleasant that using raw mml-mode, and would likely be much more
> accomodating to new users. With the new notmuch-mua hooks, it would be
> easy to turn on and off as well. I've been using it for a number of
> months, and have not had any problems with it.

I have not played with the version you posted earlier - sofar I use the
attachment functionality that Emacs offers by default and I agree that
this is lacking.
>From your description I can't quite tell if tach is overkill,
though. When I just attach a file I'd like to be able to do this just
using the minibuffer to pick a file - not having to open another buffer,
press +, find the file, etc...

> One issue to note: if you start composing a message with tach-mode
> enabled, and then disable it, the attachments you added with tach won't
> get added properly (there will just be a plaintext list of them at the
> the bottom of the message after a separator). In other words, tach
> converts the attachment list on sending, just as message-mode adds
> headers, removes "text follows this line", etc. This doesn't seem like
> an issue to me (a message started by message-mode can't be sent by
> another MUA either) but I did want to bring it to people's attention.

I think that's reasonable

> If there is interest, I would take the necessary steps to integrate it
> and prepare a patch.

I'd be interested to see a notmuch integration...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center


[PATCH] Makefile: specify libnotmuch.so location with -rpath

2010-04-25 Thread Adrien Bustany
On Sun, 25 Apr 2010 16:38:40 +0100, Chris Wilson
 wrote:
> In order to handle installation into user directories, it is convenient
> to encode the library location into the search path for the notmuch
> executable. This is achieved for the GNU linker with the -rpath
> argument.
> ---
>  Makefile.local |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Makefile.local b/Makefile.local
> index 5bb570b..77d2c45 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
>  # Smash together user's values with our extra values
>  FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS)
>  $(CONFIGURE_CFLAGS) $(extra_cflags)
>  FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS)
>  $(extra_cflags) $(extra_cxxflags)
> -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
> +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Wl,-rpath=$(prefix)/lib -Llib
> -lnotmuch
>  FINAL_NOTMUCH_LINKER = CC
>  ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
>  FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)

Hello Chris,

I know that many distros (among them Fedora, see
https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath )
discourage the use of rpath. Do you think it could be an option set at
configure time (set rpath or not) ?

Cheers

Adrien



[PATCH] Makefile: specify libnotmuch.so location with -rpath

2010-04-25 Thread Adrien Bustany
On Sun, 25 Apr 2010 16:38:40 +0100, Chris Wilson
 wrote:
> In order to handle installation into user directories, it is convenient
> to encode the library location into the search path for the notmuch
> executable. This is achieved for the GNU linker with the -rpath
> argument.
> ---
>  Makefile.local |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/Makefile.local b/Makefile.local
> index 5bb570b..77d2c45 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
>  # Smash together user's values with our extra values
>  FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS)
>  $(CONFIGURE_CFLAGS) $(extra_cflags)
>  FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS)
>  $(extra_cflags) $(extra_cxxflags)
> -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
> +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Wl,-rpath=$(prefix)/lib -Llib
> -lnotmuch
>  FINAL_NOTMUCH_LINKER = CC
>  ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
>  FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)

Hello Chris,

I know that many distros (among them Fedora, see
https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath )
discourage the use of rpath. Do you think it could be an option set at
configure time (set rpath or not) ?

Cheers

Adrien


[PATCH] Makefile: specify libnotmuch.so location with -rpath

2010-04-25 Thread Chris Wilson
In order to handle installation into user directories, it is convenient
to encode the library location into the search path for the notmuch
executable. This is achieved for the GNU linker with the -rpath
argument.
---
 Makefile.local |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile.local b/Makefile.local
index 5bb570b..77d2c45 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
 # Smash together user's values with our extra values
 FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) 
$(CONFIGURE_CFLAGS) $(extra_cflags)
 FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) 
$(extra_cflags) $(extra_cxxflags)
-FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
+FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Wl,-rpath=$(prefix)/lib -Llib -lnotmuch
 FINAL_NOTMUCH_LINKER = CC
 ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
 FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)
-- 
1.7.0.5



Some messages show only headers.

2010-04-25 Thread Abhishek Dasgupta

Hi all,

I've been using notmuch for some time, and I noticed that some mails
show only the header when pressing [return] on notmuch-show-all. If I
press [return] on the highlighted From: header then the entire message
displays.

Is this behaviour expected? The default behaviour in most other MUAs is
to show the message in full.

What is interesting is that this only works for some messages, not
all. In particular messages from debian-devel-announce, and my college
mailing lists do not show until I press enter on From:, but messages
sent directly to me usually show up.

Abhishek
--
Please cc me, I am not subscribed to this list.


Failing test cases

2010-04-25 Thread Jason White
I just tried to build the Debian package from the latest Git master branch,
but this could not be completed due to failures of test cases 067, 068 and
069.

Are others seeing this, or is it a peculiarity of my system (Debian Sid,
x86-64)?



[SCM] notmuch - thread-based email index, search and tagging. branch, master, updated. 0.2-180-gc87d17f

2010-04-25 Thread David Edmondson
On Sat, 24 Apr 2010 06:17:03 -0700 (PDT), notmuch-commits-sender at 
notmuchmail.org (Carl Worth) wrote:
> emacs: Make notmuch-hello jumpt to search bar by default.
> 
> This isn't ideal for me personally, since I usually want to inovke a
> saved search rather than entering a new search textually. But it's at
> least better than just putting point in the upper-left corner where it
> doesn't do anything.

Originally this was the behaviour (jump to the search box), but I found
that it really annoyed me. To use any of the keybindings it's necessary
to move the cursor out of the search entry area.

dme.
-- 
David Edmondson, http://dme.org


[PATCH] configure: add ignored options for compatibility.

2010-04-25 Thread C├ędric Cabessa
gentoo's ebuild script expects 2 more options for configure:
  --host (same format as --build)
  --datadir
---
 configure |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index ec8c3fd..c522ad8 100755
--- a/configure
+++ b/configure
@@ -77,7 +77,9 @@ Additional options are accepted for compatibility with other
 configure-script calling conventions, but don't do anything yet:

--build=-- Currently ignored
+   --host=--  Currently ignored
--infodir=DIR   Currently ignored
+   --datadir=DIR   Currently ignored
--localstatedir=DIR Currently ignored
--libexecdir=DIRCurrently ignored
--disable-maintainer-mode   Currently ignored
@@ -119,8 +121,26 @@ for option; do
build_option=${build_option#*-}
build_vendor=${build_option%%-*}
build_os=${build_option#*-}
+elif [ "${option%%=*}" = '--host' ] ; then
+   host_option="${option#*=}"
+   case ${host_option} in
+   *-*-*) ;;
+   *)
+   echo "Unrecognized value for --host option: ${host_option}"
+   echo "Should be: --"
+   echo "See:"
+   echo "  $0 --help"
+   echo ""
+   exit 1
+   esac
+   host_cpu=${host_option%%-*}
+   host_option=${host_option#*-}
+   host_vendor=${host_option%%-*}
+   host_os=${host_option#*-}
 elif [ "${option%%=*}" = '--infodir' ] ; then
true
+elif [ "${option%%=*}" = '--datadir' ] ; then
+   true
 elif [ "${option%%=*}" = '--localstatedir' ] ; then
true
 elif [ "${option%%=*}" = '--libexecdir' ] ; then
-- 
1.7.0.4



Re: [SCM] notmuch - thread-based email index, search and tagging. branch, master, updated. 0.2-180-gc87d17f

2010-04-25 Thread David Edmondson
On Sat, 24 Apr 2010 06:17:03 -0700 (PDT), 
notmuch-commits-sen...@notmuchmail.org (Carl Worth) wrote:
 emacs: Make notmuch-hello jumpt to search bar by default.
 
 This isn't ideal for me personally, since I usually want to inovke a
 saved search rather than entering a new search textually. But it's at
 least better than just putting point in the upper-left corner where it
 doesn't do anything.

Originally this was the behaviour (jump to the search box), but I found
that it really annoyed me. To use any of the keybindings it's necessary
to move the cursor out of the search entry area.

dme.
-- 
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] Makefile: specify libnotmuch.so location with -rpath

2010-04-25 Thread Chris Wilson
In order to handle installation into user directories, it is convenient
to encode the library location into the search path for the notmuch
executable. This is achieved for the GNU linker with the -rpath
argument.
---
 Makefile.local |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile.local b/Makefile.local
index 5bb570b..77d2c45 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
 # Smash together user's values with our extra values
 FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) 
$(CONFIGURE_CFLAGS) $(extra_cflags)
 FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) 
$(extra_cflags) $(extra_cxxflags)
-FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
+FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Wl,-rpath=$(prefix)/lib -Llib -lnotmuch
 FINAL_NOTMUCH_LINKER = CC
 ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
 FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)
-- 
1.7.0.5

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


Re: [PATCH] Makefile: specify libnotmuch.so location with -rpath

2010-04-25 Thread Adrien Bustany
On Sun, 25 Apr 2010 16:38:40 +0100, Chris Wilson
ch...@chris-wilson.co.uk wrote:
 In order to handle installation into user directories, it is convenient
 to encode the library location into the search path for the notmuch
 executable. This is achieved for the GNU linker with the -rpath
 argument.
 ---
  Makefile.local |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/Makefile.local b/Makefile.local
 index 5bb570b..77d2c45 100644
 --- a/Makefile.local
 +++ b/Makefile.local
 @@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
  # Smash together user's values with our extra values
  FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS)
  $(CONFIGURE_CFLAGS) $(extra_cflags)
  FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS)
  $(extra_cflags) $(extra_cxxflags)
 -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
 +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Wl,-rpath=$(prefix)/lib -Llib
 -lnotmuch
  FINAL_NOTMUCH_LINKER = CC
  ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
  FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)

Hello Chris,

I know that many distros (among them Fedora, see
https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath )
discourage the use of rpath. Do you think it could be an option set at
configure time (set rpath or not) ?

Cheers

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


Re: [PATCH] Makefile: specify libnotmuch.so location with -rpath

2010-04-25 Thread Adrien Bustany
On Sun, 25 Apr 2010 16:38:40 +0100, Chris Wilson
ch...@chris-wilson.co.uk wrote:
 In order to handle installation into user directories, it is convenient
 to encode the library location into the search path for the notmuch
 executable. This is achieved for the GNU linker with the -rpath
 argument.
 ---
  Makefile.local |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/Makefile.local b/Makefile.local
 index 5bb570b..77d2c45 100644
 --- a/Makefile.local
 +++ b/Makefile.local
 @@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
  # Smash together user's values with our extra values
  FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS)
  $(CONFIGURE_CFLAGS) $(extra_cflags)
  FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS)
  $(extra_cflags) $(extra_cxxflags)
 -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
 +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Wl,-rpath=$(prefix)/lib -Llib
 -lnotmuch
  FINAL_NOTMUCH_LINKER = CC
  ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
  FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)

Hello Chris,

I know that many distros (among them Fedora, see
https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath )
discourage the use of rpath. Do you think it could be an option set at
configure time (set rpath or not) ?

Cheers

Adrien

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


Kudos! Also: +1 PGP!

2010-04-25 Thread Darren McGuicken
I just wanted to drop a quick mail to the list to give you all my huge
thanks for this already astonishingly useful tool!  

Like a few others, it seems, I arrived here after reading a
not-very-grumpy review in the Grumpy Editor series[1].
Everything-is-a-search combined with CLI access?!  Sold!

I've been slowly moving all my day-to-day mailing needs to notmuch over
the last month and the only thing I'm missing is native message
decryption and verification support - is this being actively worked on,
I haven't seen it mentioned in a while?  Or is it feasible to add this
as a target for an upcoming merge window?  How far away are we from
something workable - are we just(!) looking for someone to stitch the
code together or do we need to brainstorm a little more exactly what the
approach is likely to be?

In the meantime, I find myself using the snippet from Tassilo in:

id:87zl6cl595@thinkpad.tsdh.de

Which lets me jump to the selected encrypted message in Gnus and have it
in turn auto-decrypt the text.  Works well but does need a second mail
program ;-)


[1] http://lwn.net/Articles/380073/


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


RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Jesse Rosenthal
On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote:
 Tach is a minor mode that adds mutt-like attachment handling to
 message mode. It's not notmuch specific, but I wrote it to use with
 notmuch, and I thought it might be of use to some on the list.

I wanted to see if there would be any interest in adding this to notmuch
in 0.4 or after. It makes composing messages with attachments much more
pleasant that using raw mml-mode, and would likely be much more
accomodating to new users. With the new notmuch-mua hooks, it would be
easy to turn on and off as well. I've been using it for a number of
months, and have not had any problems with it.

One issue to note: if you start composing a message with tach-mode
enabled, and then disable it, the attachments you added with tach won't
get added properly (there will just be a plaintext list of them at the
the bottom of the message after a separator). In other words, tach
converts the attachment list on sending, just as message-mode adds
headers, removes text follows this line, etc. This doesn't seem like
an issue to me (a message started by message-mode can't be sent by
another MUA either) but I did want to bring it to people's attention.

If there is interest, I would take the necessary steps to integrate it
and prepare a patch.

All best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Dirk Hohndel
On Sun, 25 Apr 2010 21:06:01 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 On Sat, 20 Feb 2010 22:12:21 -0500, Jesse Rosenthal jrosent...@jhu.edu 
 wrote:
  Tach is a minor mode that adds mutt-like attachment handling to
  message mode. It's not notmuch specific, but I wrote it to use with
  notmuch, and I thought it might be of use to some on the list.
 
 I wanted to see if there would be any interest in adding this to notmuch
 in 0.4 or after. It makes composing messages with attachments much more
 pleasant that using raw mml-mode, and would likely be much more
 accomodating to new users. With the new notmuch-mua hooks, it would be
 easy to turn on and off as well. I've been using it for a number of
 months, and have not had any problems with it.

I have not played with the version you posted earlier - sofar I use the
attachment functionality that Emacs offers by default and I agree that
this is lacking.
From your description I can't quite tell if tach is overkill,
though. When I just attach a file I'd like to be able to do this just
using the minibuffer to pick a file - not having to open another buffer,
press +, find the file, etc...
 
 One issue to note: if you start composing a message with tach-mode
 enabled, and then disable it, the attachments you added with tach won't
 get added properly (there will just be a plaintext list of them at the
 the bottom of the message after a separator). In other words, tach
 converts the attachment list on sending, just as message-mode adds
 headers, removes text follows this line, etc. This doesn't seem like
 an issue to me (a message started by message-mode can't be sent by
 another MUA either) but I did want to bring it to people's attention.

I think that's reasonable

 If there is interest, I would take the necessary steps to integrate it
 and prepare a patch.

I'd be interested to see a notmuch integration...

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: RFC: Adding an attachment composition interface to notmuch

2010-04-25 Thread Jesse Rosenthal
On Sun, 25 Apr 2010 19:52:54 -0700, Dirk Hohndel hohn...@infradead.org wrote:
 From your description I can't quite tell if tach is overkill,
 though. When I just attach a file I'd like to be able to do this just
 using the minibuffer to pick a file - not having to open another buffer,
 press +, find the file, etc...

I agree, for the most part -- but if you're attaching multiple files, or
decide to change which file you're attaching, some sort of list view is
necessary. Or at least, at is for me. Anyway, I tried to make it pretty
unobtrusive and intuitive, so hopefully it won't *feel* too much like
overkill.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch