RFC: Adding an attachment composition interface to notmuch
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!
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
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
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
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
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.
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
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
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.
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
[PATCH] Makefile: specify libnotmuch.so location with -rpath
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
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
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!
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
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
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
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
