On Sat, 15 Aug 2015 12:42 +0200, David Bremner wrote:
For me compaction is a rare event, so having to take the fallback path
and do a full dump or whatever doesn't seem so bad. If you don't want to
have a fallback path, then I guess you need to guarantee externally that
no bad changes happen
On Fri, 14 Aug 2015 18:47 +0200, David Bremner wrote:
> +``--lastmod``
> + Append lastmod (counter for number of database updates) and UUID
> + to the output. lastmod values are only comparable between databases
> + with the same UUID.
Sorry to keep harping on this, but I'm not
On Fri, 14 Aug 2015 18:47 +0200, David Bremner wrote:
+``--lastmod``
+ Append lastmod (counter for number of database updates) and UUID
+ to the output. lastmod values are only comparable between databases
+ with the same UUID.
Sorry to keep harping on this, but I'm not
Maybe another consistent solution is to add a --format argument to
count, with JSON as one option. That way we could even add more
information to other count results (if that becomes needed at some
point) without breaking code using the JSON interface.
Best regards,
Daniel
Maybe another consistent solution is to add a --format argument to
count, with JSON as one option. That way we could even add more
information to other count results (if that becomes needed at some
point) without breaking code using the JSON interface.
Best regards,
Daniel
This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
test/T150-tagging.sh | 25 +
1 file changed, 25 insertions(+)
diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..8adcabc 100755
---
As Jani pointed out, having a test checking the functionality
with an empty line of tag modification makes more sense than
having two tests with non-empty tags, so here's a fixed version
of the preceding patch.
Best regards,
Daniel
This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
test/T150-tagging.sh | 24
1 file changed, 24 insertions(+)
diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..19539dd 100755
---
This patch removes the restriction on notmuch-tag that disallows using
both --remove-all and --batch. Combining the two options removes tags
on all messages affected by each query before applying the new tags.
---
notmuch-tag.c | 4
1 file changed, 4 deletions(-)
diff --git a/notmuch-tag.c
Hi,
I noticed that it makes sense to combine the --batch and --remove-all
options to notmuch. This can be used, for instance, when synchronizing
tags by transferring the tags for all changed mails.
This series removes this (undocumented) restriction and adds some
tests.
Best regards,
Daniel
Hi,
I noticed that it makes sense to combine the --batch and --remove-all
options to notmuch. This can be used, for instance, when synchronizing
tags by transferring the tags for all changed mails.
This series removes this (undocumented) restriction and adds some
tests.
Best regards,
Daniel
This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
test/T150-tagging.sh | 24
1 file changed, 24 insertions(+)
diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..19539dd 100755
---
This patch removes the restriction on notmuch-tag that disallows using
both --remove-all and --batch. Combining the two options removes tags
on all messages affected by each query before applying the new tags.
---
notmuch-tag.c | 4
1 file changed, 4 deletions(-)
diff --git a/notmuch-tag.c
As Jani pointed out, having a test checking the functionality
with an empty line of tag modification makes more sense than
having two tests with non-empty tags, so here's a fixed version
of the preceding patch.
Best regards,
Daniel
___
notmuch mailing
This patch adds some tests for combining --remove-all with --batch or
--input when calling notmuch-tag.
---
test/T150-tagging.sh | 25 +
1 file changed, 25 insertions(+)
diff --git a/test/T150-tagging.sh b/test/T150-tagging.sh
index 821d393..8adcabc 100755
---
On Mon, 10 Aug 2015 13:32 +0200, David Bremner wrote:
> So compacting is in fact a bit of a strange case, it preserves the
> lastmod counters (because those are just terms on documents), but not
> the uuid. This means from notmuch point of view have no programmatic way
> to know that we can trust
On Sun, 09 Aug 2015 11:24+0200, David Bremner wrote:
> +``--uuid=HEX``
> + Enforce that the database UUID (a unique identifier which
> + persists until e.g. the database is compacted)
> + is HEX; exit with an error if it is not. This is useful to
> + detect rollover in
On Mon, 10 Aug 2015 13:32 +0200, David Bremner wrote:
So compacting is in fact a bit of a strange case, it preserves the
lastmod counters (because those are just terms on documents), but not
the uuid. This means from notmuch point of view have no programmatic way
to know that we can trust the
On Sun, 09 Aug 2015 11:24+0200, David Bremner wrote:
+``--uuid=HEX``
+ Enforce that the database UUID (a unique identifier which
+ persists until e.g. the database is compacted)
+ is HEX; exit with an error if it is not. This is useful to
+ detect rollover in
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> +The **lastmod:** prefix can be used to restrict the result by the
> +database revision number of when messages were last modified (tags
> +were added/removed or filenames changed). This is usually used in
> +conjunction with the
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> +``--db-revision=UUID``
> + Enforce that the database revision is UUID. This is useful to
> + detect rollover in modification counts on messages. You can
> + find this UUID in the first column of output from
> +
Hi,
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> + /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
> + * track modification revisions. Give all messages a
> + * revision of 1.
> + */
> + if (new_features & NOTMUCH_FEATURE_LAST_MOD)
> +
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
+``--db-revision=UUID``
+ Enforce that the database revision is UUID. This is useful to
+ detect rollover in modification counts on messages. You can
+ find this UUID in the first column of output from
+
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
+The **lastmod:** prefix can be used to restrict the result by the
+database revision number of when messages were last modified (tags
+were added/removed or filenames changed). This is usually used in
+conjunction with the
Hi,
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
+ /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
+ * track modification revisions. Give all messages a
+ * revision of 1.
+ */
+ if (new_features NOTMUCH_FEATURE_LAST_MOD)
+
Hi,
I needed a way to synchronize notmuch tags between machines without
having to sync all my mail as well (à la muchsync) and without using
Gmail labels for this. As a result, I ended up writing a small tool to
do this by using normal file synchronizers like seafile[1] or dropbox to
do the
The second argument to notmuch-tag is now called tag-changes, but the
documentation for notmuch-before-tag-hook and notmuch-after-tag-hook
still used the old argument name `tags'. This resulted in broken hooks
when following the documentation.
---
emacs/notmuch-tag.el | 4 ++--
1 file changed, 2
Hi,
for what it's worth, you can simulate a post-tag hook in a somewhat ugly
way by putting a script called "notmuch" in front of the notmuch binary
in your PATH. The script can then call the original notmuch binary as
usual, inspect the first argument, and, if it's "tag", invoke your
script
Hi,
for what it's worth, you can simulate a post-tag hook in a somewhat ugly
way by putting a script called notmuch in front of the notmuch binary
in your PATH. The script can then call the original notmuch binary as
usual, inspect the first argument, and, if it's tag, invoke your
script
Hi Trevor,
yeah I saw that your client implemented that, but didn't want to switch
away from the standard emacs interface. Moreover, by using a daemon like
at the functionality can basically be used with any notmuch interface.
Best regards,
Daniel
On Thu, 06 Nov 2014 20:09 +0100, Trevor Jim
Hi,
inspired by my alarm clock and the snooze feature found in some other
mail clients, I cobbled something together that allows snoozing
(i.e. removing a message from the inbox and adding it again later)
messages in notmuch. It's a small script that removes the inbox tag from
messages and
Hi,
inspired by my alarm clock and the snooze feature found in some other
mail clients, I cobbled something together that allows snoozing
(i.e. removing a message from the inbox and adding it again later)
messages in notmuch. It's a small script that removes the inbox tag from
messages and
Hi Trevor,
yeah I saw that your client implemented that, but didn't want to switch
away from the standard emacs interface. Moreover, by using a daemon like
at the functionality can basically be used with any notmuch interface.
Best regards,
Daniel
On Thu, 06 Nov 2014 20:09 +0100, Trevor Jim
On Sun, 15.07.2012 18:36, David Bremner wrote:
> Are there actual users (other than the author)?
I started using the slrn2maildir script yesterday, but none of the other
scripts. It's working fine so far.
Cheers,
Daniel
-- next part --
A non-text attachment was
On Sun, 15.07.2012 18:36, David Bremner wrote:
Are there actual users (other than the author)?
I started using the slrn2maildir script yesterday, but none of the other
scripts. It's working fine so far.
Cheers,
Daniel
pgpnnUpoMefpM.pgp
Description: PGP signature
On Thu, 28.06.2012 09:41, Albin Stjerna wrote:
> If it didn't make it: what is now the preferred method of wrapping
> long lines when reading emails using notmuch/Emacs?
As far as I can tell, it didn't make it into mainline (yet?). However, it
changes a file that is rarely modified by other
On Thu, 28.06.2012 09:41, Albin Stjerna wrote:
If it didn't make it: what is now the preferred method of wrapping
long lines when reading emails using notmuch/Emacs?
As far as I can tell, it didn't make it into mainline (yet?). However, it
changes a file that is rarely modified by other
On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote:
> I actually rebound these keys immediately after the release, so I'm
> perfectly happy to change back.
Same here.
I think the ratio of cases where I wanted to reply to all
participants instead compared to just to the sender is something
On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote:
I actually rebound these keys immediately after the release, so I'm
perfectly happy to change back.
Same here.
I think the ratio of cases where I wanted to reply to all
participants instead compared to just to the sender is something like
On Tue, 24.04.2012 11:11, Mark Walters wrote:
> The first three patches implement the client side changes: one to
> allow null messages to be output in Json (without upsetting the
> parsing/structure), one to do the command line parsing for
> --entire-thread=false and one to update the schemata.
>
On Tue, 24.04.2012 11:11, Mark Walters wrote:
The first three patches implement the client side changes: one to
allow null messages to be output in Json (without upsetting the
parsing/structure), one to do the command line parsing for
--entire-thread=false and one to update the schemata.
The
Hi Adam,
On Wed, 18.04.2012 17:30, Adam Wolfe Gordon wrote:
>> +(defvar notmuch-wash-wrap-lines-length nil
>> + ?"Wrap line after at most this many characters.
>> +
>> +If this is nil, lines in messages will be wrapped to fit in the
>> +current window. If this is a number, lines will be wrapped
Hi Adam,
On Wed, 18.04.2012 17:30, Adam Wolfe Gordon wrote:
+(defvar notmuch-wash-wrap-lines-length nil
+ Wrap line after at most this many characters.
+
+If this is nil, lines in messages will be wrapped to fit in the
+current window. If this is a number, lines will be wrapped after
+this
On Wed, 07 Mar 2012 20:53:48 +0100, Pieter Praet wrote:
> On Thu, 01 Mar 2012 08:36:33 -0400, David Bremner
> wrote:
> >
> > Pushed, finally. Thanks for both of your hard work on this.
> >
>
> 625 lines changed (425 added, 200 removed), in a *single* commit ?
>
> It's a useful bit of
On Wed, 07 Mar 2012 20:53:48 +0100, Pieter Praet pie...@praet.org wrote:
On Thu, 01 Mar 2012 08:36:33 -0400, David Bremner da...@tethera.net wrote:
Pushed, finally. Thanks for both of your hard work on this.
625 lines changed (425 added, 200 removed), in a *single* commit ?
It's a
On Mar 5, 2012 5:43 PM, "Dmitry Kurochkin"
> I do not buy the argument that we should help users who implement their
> own sorting functions but do not read documentation for functions they
> use. Apparently, those who implemented the `sort' function had similar
> ideas. And I do not think it
On Mon, 05 Mar 2012 06:21:52 +0400, Dmitry Kurochkin wrote:
> On Thu, 1 Mar 2012 21:24:38 +0100, Daniel Schoepe
> wrote:
> > notmuch-saved-search-sort-function might destructively modify its
> > input (`sort' does that, for instance), so it should not be given
> >
On Mon, 05 Mar 2012 06:21:52 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
On Thu, 1 Mar 2012 21:24:38 +0100, Daniel Schoepe dan...@schoepe.org wrote:
notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should
On Mar 5, 2012 5:43 PM, Dmitry Kurochkin dmitry.kuroch...@gmail.com
I do not buy the argument that we should help users who implement their
own sorting functions but do not read documentation for functions they
use. Apparently, those who implemented the `sort' function had similar
ideas. And
On Fri, 02 Mar 2012 01:34:03 +0100, Daniel Schoepe
wrote:
> You can define other section that you can then hide, which was the main
> point of the original patch.
The defining other sections thing that is, not that you have more
things to hide.. :)
-- next part --
On Thu, 01 Mar 2012 22:18:04 +, Mark Walters
wrote:
> This looks fine to me and does speed things up when the "All tags"
> section is hidden (are there other sections I can hide?)
You can define other section that you can then hide, which was the main
point of the original patch.
Michal,
notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
emacs/notmuch-hello.el |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-hello.el
I overlooked that copy-seq is from cl.el. This version uses copy-sequence
instead.
notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
emacs/notmuch-hello.el |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-hello.el
As Jani discovered, `sort' modifies its input list, leading to deleted
saved searches when using notmuch-sort-saved-searches.
As Jani discovered, `sort' modifies its input list, leading to deleted
saved searches when using notmuch-sort-saved-searches.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
emacs/notmuch-hello.el |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-hello.el
I overlooked that copy-seq is from cl.el. This version uses copy-sequence
instead.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-saved-search-sort-function might destructively modify its
input (`sort' does that, for instance), so it should not be given
notmuch-saved-searches directly.
---
emacs/notmuch-hello.el |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/emacs/notmuch-hello.el
On Thu, 01 Mar 2012 22:18:04 +, Mark Walters markwalters1...@gmail.com
wrote:
This looks fine to me and does speed things up when the All tags
section is hidden (are there other sections I can hide?)
You can define other section that you can then hide, which was the main
point of the
On Fri, 02 Mar 2012 01:34:03 +0100, Daniel Schoepe dan...@schoepe.org wrote:
You can define other section that you can then hide, which was the main
point of the original patch.
The defining other sections thing that is, not that you have more
things to hide.. :)
pgpOY8At84Uqb.pgp
Description
On Sun, 26 Feb 2012 11:22:10 +, Patrick Totzke wrote:
> > so it would seem more appropriate that this be done in the backend.
> I agree. I personally think this is a nice feature to have in all
> user interfaces to notmuch and therefore it makes sense to implement it once
> in the lib. Also
On Sun, 26 Feb 2012 11:22:10 +, Patrick Totzke
patricktot...@googlemail.com wrote:
so it would seem more appropriate that this be done in the backend.
I agree. I personally think this is a nice feature to have in all
user interfaces to notmuch and therefore it makes sense to implement it
On Tue, 21 Feb 2012 09:15:09 -, Justus Winter <4winter at
informatik.uni-hamburg.de> wrote:
> Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:
> >Just for completeness: I'm using the nice nottoomuch-addresses.pl script
> >[1] by Tomi Ollila *which doesn't
On Tue, 21 Feb 2012 09:15:09 -, Justus Winter
4win...@informatik.uni-hamburg.de wrote:
Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:
Just for completeness: I'm using the nice nottoomuch-addresses.pl script
[1] by Tomi Ollila *which doesn't require any bindings
On Fri, 17 Feb 2012 18:46:21 +, David Edmondson wrote:
> * daniel at schoepe.org [2012-02-17 Fri 18:34]
> > This introduces a variable to control after how many characters a line
> > is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
> > window width if it is lower).
>
> What
This introduces a variable to control after how many characters a line
is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
window width if it is lower).
---
emacs/notmuch-wash.el | 36 ++--
1 files changed, 26 insertions(+), 10 deletions(-)
diff
On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier wrote:
> Hi again.
>
> I'm trying to setup tab completion for addresses. I appeared to me that
> the simplest solution was notmuch_addresses so I grabbed a copy from
> git. When I hit tab I get this[1] Was I suppose to do something more?
This introduces a variable to control after how many characters a line
is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
window width if it is lower).
---
emacs/notmuch-wash.el | 36 ++--
1 files changed, 26 insertions(+), 10 deletions(-)
diff
On Fri, 17 Feb 2012 18:46:21 +, David Edmondson d...@dme.org wrote:
* dan...@schoepe.org [2012-02-17 Fri 18:34]
This introduces a variable to control after how many characters a line
is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
window width if it is lower).
What
On Thu, 16 Feb 2012 14:12:36 -0500, Philippe LeCavalier
supp...@plecavalier.com wrote:
Hi again.
I'm trying to setup tab completion for addresses. I appeared to me that
the simplest solution was notmuch_addresses so I grabbed a copy from
git. When I hit tab I get this[1] Was I suppose to do
On Mon, 13 Feb 2012 10:29:26 -0500, Austin Clements wrote:
> Quoth Dmitry Kurochkin on Feb 13 at 3:09 pm:
> > The notmuch-show view refresh function (`notmuch-show-refresh-view',
> > bound to "=") accepts an optional RETAIN-STATE argument. The patch
> > allows to set this argument interactively
On Mon, 13 Feb 2012 10:29:26 -0500, Austin Clements amdra...@mit.edu wrote:
Quoth Dmitry Kurochkin on Feb 13 at 3:09 pm:
The notmuch-show view refresh function (`notmuch-show-refresh-view',
bound to =) accepts an optional RETAIN-STATE argument. The patch
allows to set this argument
On Sun, 12 Feb 2012 18:49:37 +, Mark Walters
wrote:
> +int opt_index, ret, entire_thread;
> +notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
> const notmuch_show_format_t *format = _text;
> notmuch_show_params_t params = { .part = -1 };
> int format_sel =
On Sun, 12 Feb 2012 12:46:36 -0800, Jameson Graef Rollins wrote:
> Hey, Mark. I really like the idea, since I've been looking for
> something like this for a while, but there's something I'm confused
> about. Is this meant to replace notmuch-search, or notmuch-show? I had
> been hoping for a
I think notmuch-pick [1] is a better approach and also provides
thread-outlining, so these patches should be obsolete now.
[1] id:"87d39k1gvi.fsf at qmul.ac.uk"
Cheers,
Daniel
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type:
This makes the faces notmuch-pick uses for high/"low"lighting configurable.
Obviously, this requires the rest of the patch series from this thread.
Forgot to reply to the list
On Sun, 12 Feb 2012 10:32:48 +, Mark Walters
wrote:
> Questions/thoughts and known bugs:
>
> Do people like the rough idea?
I think it's a great idea. What I find especially nice about this, is
that it works for both, just showing the structure of one
This makes the faces notmuch-pick uses for high/lowlighting configurable.
Obviously, this requires the rest of the patch series from this thread.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
---
emacs/notmuch-pick.el | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/emacs/notmuch-pick.el b/emacs/notmuch-pick.el
index 4c91d7c..2bf1ae4 100644
--- a/emacs/notmuch-pick.el
+++ b/emacs/notmuch-pick.el
@@ -42,6 +42,22 @@
:group 'notmuch
I think notmuch-pick [1] is a better approach and also provides
thread-outlining, so these patches should be obsolete now.
[1] id:87d39k1gvi@qmul.ac.uk
Cheers,
Daniel
pgptBCwFOhEua.pgp
Description: PGP signature
___
notmuch mailing list
On Sun, 12 Feb 2012 12:46:36 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
Hey, Mark. I really like the idea, since I've been looking for
something like this for a while, but there's something I'm confused
about. Is this meant to replace notmuch-search, or notmuch-show? I
On Sun, 12 Feb 2012 18:49:37 +, Mark Walters markwalters1...@gmail.com
wrote:
+int opt_index, ret, entire_thread;
+notmuch_sort_t sort = NOTMUCH_SORT_NEWEST_FIRST;
const notmuch_show_format_t *format = format_text;
notmuch_show_params_t params = { .part = -1 };
int
Hi Dmitry.
On Sun, 29 Jan 2012 02:48, Dmitry Kurochkin
wrote:
> I only meant trailing whitespaces in test/emacs file in the lines added
> by the patch. Trailing whitespaces in expected results are obviously
> fine.
Ah, okay. I fixed those with delete-trailing-whitespace, but then
noticed that
From: Daniel Schoepe <daniel.scho...@googlemail.com>
---
test/emacs | 37
test/emacs.expected-output/notmuch-hello |3 +-
.../notmuch-hello-new-section |4 ++
.../notmuch-hello-no-saved-se
From: Daniel Schoepe <daniel.scho...@googlemail.com>
This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for ea
Rebased against master.
Hi Dmitry,
On Tue, 24 Jan 2012 03:07, Dmitry Kurochkin
wrote:
> There are some trailing whitespaces in the tests.
those are also produced by the various notmuch-hello functions, and are
also in the existing tests. If someone is bothered by this, it should be
fixed in a separate patch.
>
>
Rebased against master.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
From: Daniel Schoepe daniel.scho...@googlemail.com
This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for each tag
Hi Dmitry.
On Sun, 29 Jan 2012 02:48, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote:
I only meant trailing whitespaces in test/emacs file in the lines added
by the patch. Trailing whitespaces in expected results are obviously
fine.
Ah, okay. I fixed those with delete-trailing-whitespace,
From: Daniel Schoepe <daniel.scho...@googlemail.com>
---
test/emacs | 37
test/emacs.expected-output/notmuch-hello |4 ++-
.../notmuch-hello-new-section |4 ++
.../notmuch-hello-no
From: Daniel Schoepe <daniel.scho...@googlemail.com>
This patch makes the notmuch-hello screen fully customizable
by allowing the user to add and remove arbitrary sections. It
also provides some convenience functions for constructing sections,
e.g. showing the unread message count for ea
On Wed, 14 Dec 2011 07:11:21 +0400, Dmitry Kurochkin wrote:
> Hi Daniel.
>
> I have finished reviewing this patch at last. Sorry, it is a bit messy.
> Overall, I like the patch. It is a very nice improvement.
>
> I am sure I have missed some important points, but I guess this is the
> best I
On Wed, 14 Dec 2011 07:11:21 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
Hi Daniel.
I have finished reviewing this patch at last. Sorry, it is a bit messy.
Overall, I like the patch. It is a very nice improvement.
I am sure I have missed some important points, but I guess
From: Daniel Schoepe daniel.scho...@googlemail.com
---
test/emacs | 37
test/emacs.expected-output/notmuch-hello |4 ++-
.../notmuch-hello-new-section |4 ++
.../notmuch-hello-no-saved-searches
On Mon, 16 Jan 2012 11:33:59 +, David Edmondson wrote:
> Daniel, will you include this in your next version? (I'd like to mark it
> 'obsolete'.)
Yes, it sounds like a great improvement.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type:
On Mon, 16 Jan 2012 10:59:39 +, David Edmondson wrote:
> Daniel, there was a bunch of feedback from Dmitry about the patch and a
> couple of other comments.
>
> Do you plan to produce a new version?
Yes, I plan to do that (I know I already said that in December) and
already have a partially
On Mon, 16 Jan 2012 10:59:39 +, David Edmondson d...@dme.org wrote:
Daniel, there was a bunch of feedback from Dmitry about the patch and a
couple of other comments.
Do you plan to produce a new version?
Yes, I plan to do that (I know I already said that in December) and
already have a
On Mon, 16 Jan 2012 11:33:59 +, David Edmondson d...@dme.org wrote:
Daniel, will you include this in your next version? (I'd like to mark it
'obsolete'.)
Yes, it sounds like a great improvement.
pgpKKoT3xeVRl.pgp
Description: PGP signature
___
1 - 100 of 280 matches
Mail list logo
