[PATCH v2] emacs: show: lazy part bugfix

The lazy part handling had a subtle bug. Notmuch stores the part information as a text property with the displayed part so attachment handling (saving viewing etc work). Now, some mime parts have subparts and to avoid overwriting the sub-part data notmuch checks and if part data is already

Re: [PATCH 0/4] contrib: pick: extra tests

Mark Walters markwalters1...@gmail.com writes: This series adds some tests for various existing and recently added functionality. The only thing to note is that the xapian tag database and the displayed tags are update separately so we need to test both. pushed, d

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

Hi; Both are superceded by code in the main tree, and should probably not be shipped in the next release. I suppose there are some packagers packaging contrib/notmuch-deliver, but they will have to adapt at some point anyway. Comments? d ___

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

On Wed, Sep 04 2013, David Bremner da...@tethera.net wrote: Hi; Both are superceded by code in the main tree, and should probably not be shipped in the next release. I suppose there are some packagers packaging contrib/notmuch-deliver, but they will have to adapt at some point anyway.

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

is actually someone using notmuch deliver? i was thinking to use is as my 'implementation' of emailing uses remote access via SSH. This one is considerably slower (especially when slow uplink) than local access and hence if notmuch-deliver would be in a shape, that would spare at least some time

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

+1 from me for getting rid of the vim plug in mainline notmuch. Cheers, /p signature.asc Description: signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

David Belohrad da...@belohrad.ch writes: is actually someone using notmuch deliver? i was thinking to use is as my 'implementation' of emailing uses remote access via SSH. This one is considerably slower (especially when slow uplink) than local access and hence if notmuch-deliver would be in

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

David Bremner da...@tethera.net writes: Both are superceded by code in the main tree, and should probably not be shipped in the next release. I suppose there are some packagers packaging contrib/notmuch-deliver, but they will have to adapt at some point anyway. Comments? +1. I don't

Re: proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

Hi David, On Wed, Sep 04, 2013 at 07:25:09AM -0300, David Bremner wrote: David Belohrad da...@belohrad.ch writes: is actually someone using notmuch deliver? i was thinking to use is as my 'implementation' of emailing uses remote access via SSH. This one is considerably slower (especially

[ALT PATCH] emacs: target one-notmuch.el[c] -- emacs client in one .el[c] file

Added Makefile recipes to create notmuch emacs client in just one .el[c] file. This is an experimental feature and not built by default. This is useful for example when one wants to build the latest emacs client and then distribute the elisp file to many machines. This is also useful for

Re: [PATCH v2] emacs: show: lazy part bugfix

Quoth Mark Walters on Sep 04 at 8:30 am: The lazy part handling had a subtle bug. Notmuch stores the part information as a text property with the displayed part so attachment handling (saving viewing etc work). s/ work)/) work/ Now, some mime parts have subparts and to avoid overwriting

Re: [PATCH v2] emacs: show: lazy part bugfix

Quoth Jameson Graef Rollins on Sep 04 at 8:50 am: On Wed, Sep 04 2013, Austin Clements amdra...@mit.edu wrote: Now, some mime parts have subparts and to avoid overwriting the sub-part data notmuch checks and if part data is already recorded it does not overwrite it. Now with lazy part

Re: [PATCH v2] emacs: show: lazy part bugfix

On Wed, Sep 04 2013, Austin Clements amdra...@mit.edu wrote: Now, some mime parts have subparts and to avoid overwriting the sub-part data notmuch checks and if part data is already recorded it does not overwrite it. Now with lazy part handling this could fail: there is already part data

Re: [ALT PATCH] emacs: target one-notmuch.el[c] -- emacs client in one .el[c] file

On Wed, Sep 04 2013, David Bremner da...@tethera.net wrote: Tomi Ollila tomi.oll...@iki.fi writes: can be used to quickly experiment with new development. What about explicitely putting this under devel? I'm a bit nervous about promoting this feature since mismatch between CLI and emacs

[PATCH 1/1] emacs: fix notmuch-mua-reply point placement when signature involved

From: Tomi Ollila tomi.oll...@iki.fi When composing a reply, notmuch-mua-reply attempts to cite the the original message by inserting it before the user signature, if one is present. The existing method used to search the signature separator backward from the end of the buffer and then move one

notmuch-mutt: switch to using the new --duplicate flag

This patch series changes notmuch-mutt to use the new built-in --duplicate flag for removing duplicates by message-id. This should speed up duplicate removal, since we no longer need to scan and compute sha sums. However, it does now allow search results to be hidden in the event of accidental

[PATCH 2/2] debian: remove unneeded notmuch-mutt dependencies

Switching away from fdupes removes the dependency on libfile-which-perl and the need to recommend fdupes. --- debian/control | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/debian/control b/debian/control index 74a5161..81b9b12 100644 --- a/debian/control +++

[PATCH 1/2] notmuch-mutt: use notmuch --duplicate flag

Change notmuch-mutt to use the new --duplicate=1 flag for duplicate removal. This will remove duplicates based on message-id at the notmuch level. Previously we were using fdupes or generating sha sums after the search. This version will be faster, but will enable the possibility of hiding

[BUG] Decryption fails if message was signed with an unknown key

Dear notmuch developers, This is now the second time the following has happened to me: # $ notmuch show --decrypt id:x...@example.com message{ id:x...@example.com depth:0 match:1 excluded:0 filename:/home/simon/*** header{ John Doe sen...@example.com (Today 21:52) (encrypted inbox new)

[PATCH v2] emacs: show: lazy part bugfix

The lazy part handling had a subtle bug. Notmuch stores the part information as a text property with the displayed part so attachment handling (saving viewing etc work). Now, some mime parts have subparts and to avoid overwriting the sub-part data notmuch checks and if part data is already

[PATCH 0/4] contrib: pick: extra tests

Mark Walters writes: > This series adds some tests for various existing and recently added > functionality. > > The only thing to note is that the xapian tag database and the > displayed tags are update separately so we need to test both. > pushed, d

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

Hi; Both are superceded by code in the main tree, and should probably not be shipped in the next release. I suppose there are some packagers packaging contrib/notmuch-deliver, but they will have to adapt at some point anyway. Comments? d

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

On Wed, Sep 04 2013, David Bremner wrote: > Hi; > > Both are superceded by code in the main tree, and should probably not be > shipped in the next release. I suppose there are some packagers > packaging contrib/notmuch-deliver, but they will have to adapt at some > point anyway. > > Comments?

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

is actually someone using notmuch deliver? i was thinking to use is as my 'implementation' of emailing uses remote access via SSH. This one is considerably slower (especially when slow uplink) than local access and hence if notmuch-deliver would be in a shape, that would spare at least some time

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

nts/20130904/34bdf25a/attachment.pgp>

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

David Belohrad writes: > is actually someone using notmuch deliver? i was thinking to use is as > my 'implementation' of emailing uses remote access via SSH. This one is > considerably slower (especially when slow uplink) than local access and > hence if notmuch-deliver would be in a shape, that

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

don't pack notmuch-deliver for Gentoo. -- Amadeusz ?o?nowski -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/2013090

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

Hi David, On Wed, Sep 04, 2013 at 07:25:09AM -0300, David Bremner wrote: > David Belohrad writes: > > > is actually someone using notmuch deliver? i was thinking to use is as > > my 'implementation' of emailing uses remote access via SSH. This one is > > considerably slower (especially when

[ALT PATCH] emacs: target one-notmuch.el[c] -- emacs client in one .el[c] file

Added Makefile recipes to create notmuch emacs client in just one .el[c] file. This is an experimental feature and not built by default. This is useful for example when one wants to build the latest emacs client and then distribute the elisp file to many machines. This is also useful for

proposal to remove contrib/notmuch-vim and contrib/notmuch-deliver

Hello, On 2013-04-09, David Bremner wrote: > David Belohrad writes: > >> is actually someone using notmuch deliver? I am using notmuch-deliver with maildrop. This allows me to filter and tag based on any header field of the message. >> [...] > > notmuch-deliver is replaced by notmuch insert

[PATCH v2] emacs: show: lazy part bugfix

Quoth Mark Walters on Sep 04 at 8:30 am: > The lazy part handling had a subtle bug. Notmuch stores the part > information as a text property with the displayed part so attachment > handling (saving viewing etc work). s/ work)/) work/ > > Now, some mime parts have subparts and to avoid

[PATCH v2] emacs: show: lazy part bugfix

available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130904/9acba2bd/attachment.pgp>

[PATCH v2] emacs: show: lazy part bugfix

Quoth Jameson Graef Rollins on Sep 04 at 8:50 am: > On Wed, Sep 04 2013, Austin Clements wrote: > >> Now, some mime parts have subparts and to avoid overwriting the > >> sub-part data notmuch checks and if part data is already recorded it > >> does not overwrite it. > >> > >> Now with lazy part

[ALT PATCH] emacs: target one-notmuch.el[c] -- emacs client in one .el[c] file

Tomi Ollila writes: > can be used to quickly experiment with new development. What about explicitely putting this under devel? I'm a bit nervous about promoting this feature since mismatch between CLI and emacs code is already a source of problems for users. d

[ALT PATCH] emacs: target one-notmuch.el[c] -- emacs client in one .el[c] file

On Wed, Sep 04 2013, David Bremner wrote: > Tomi Ollila writes: > >> can be used to quickly experiment with new development. > > What about explicitely putting this under devel? I'm a bit nervous about > promoting this feature since mismatch between CLI and emacs code is > already a source of

[PATCH] emacs: distinguish tag `flagged' on terminal

Change foreground color to `blue' like lines representing threads with flagged messages in notmuch-search. Before tag `flagged' was shown in notmuch-show buffers as image star on graphical frames while there was no visible distinction to other flags on terminal frames. --- With this patch applied

[PATCH 1/1] emacs: fix notmuch-mua-reply point placement when signature involved

From: Tomi Ollila When composing a reply, notmuch-mua-reply attempts to cite the the original message by inserting it before the user signature, if one is present. The existing method used to search the signature separator backward from the end of the buffer and then move

notmuch-mutt: switch to using the new --duplicate flag

This patch series changes notmuch-mutt to use the new built-in --duplicate flag for removing duplicates by message-id. This should speed up duplicate removal, since we no longer need to scan and compute sha sums. However, it does now allow search results to be hidden in the event of accidental

[PATCH 2/2] debian: remove unneeded notmuch-mutt dependencies

Switching away from fdupes removes the dependency on libfile-which-perl and the need to recommend fdupes. --- debian/control | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/debian/control b/debian/control index 74a5161..81b9b12 100644 --- a/debian/control +++

[PATCH 1/2] notmuch-mutt: use notmuch --duplicate flag

Change notmuch-mutt to use the new --duplicate=1 flag for duplicate removal. This will remove duplicates based on message-id at the notmuch level. Previously we were using fdupes or generating sha sums after the search. This version will be faster, but will enable the possibility of hiding