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 (Today 21:52) (encrypted inbox new)
Subject: foobar
Fr
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 one
line up. In case of
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 pr
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
+++ b/debian/control
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
searc
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 or
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
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
+++ b/debian/control
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
searc
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 or
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
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 (initia
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 slow
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
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/20
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?
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 one
line up. In case of
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
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 wh
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 overwriti
nts/20130904/34bdf25a/attachment.pgp>
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
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 pr
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
__
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 handling this could fail: there is already part
>> data stored.
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
as scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20130904/9acba2bd/attachment.pgp>
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
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 recorde
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 overwriti
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
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 (initia
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
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
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 slow
David Bremner 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 pack notmuch-de
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
+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
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 wh
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?
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
___
notmuch
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
___
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 recorde
43 matches
Mail list logo