From: Mohsin Kaleem
Hi,
I've finally managed to come back to this patch series. Since last time
I've collapsed all the separate commits into 3 main ones. The first adds
the new option and then updates the commands and tests that should be
affected by it. The second allows you to configure messag
Currently the simplest way to open the notmuch database properly a
client must do:
$config = IO.popen(%w[notmuch config list]) do |io|
io.each(chomp: true).map { |e| e.split('=') }.to_h
end
$db_name = config['database.path']
$db = Notmuch::Database.new($db_name)
While this works and i
As well as allowing headers to be specified in the various result
format lists, allow functions that can be used to implement per-user
logic when generating the results.
David Edmondson (3):
emacs: Use pcase in notmuch-search-insert-field
emacs: Allow functions in notmuch-search-result-format
support for format=flowed text display
This patch improves the display of format=flowed text parts.
I suspect that format=flowed display and some of the other content
washing might interact in annoying ways, but the only way to be sure
is to see how people feel about the results.
v2:
- Update
On Fri 2016-06-03 13:49:52 -0400, Mark Walters
wrote:
> This is a new version of the WIP patch at
> id:1464915472-5669-1-git-send-email-markwalters1...@gmail.com
>
> So far it seems to deal with all cases that I have tried, and the
> CAVEATS list is rather smaller than before.
>
> The bindings ar
This is a new version of the WIP patch at
id:1464915472-5669-1-git-send-email-markwalters1...@gmail.com
So far it seems to deal with all cases that I have tried, and the
CAVEATS list is rather smaller than before.
The bindings are C-x C-s to save a draft (in notmuch-message-mode) C-c
C-p to postp
Improve the display of matching/non-matching authors.
Distinguishing between matching and non-matching authors in the emacs
interface is currently done by parsing the :authors attribute of a
search result. If one of the authors uses the pipe symbol (|) in their
'From' address this parsing incorre
Improve the display of matching/non-matching authors.
Distinguishing between matching and non-matching authors in the emacs
interface is currently done by parsing the :authors attribute of a
search result. If one of the authors uses the pipe symbol (|) in their
'From' address this parsing incorre
This is v2 of the final three patches of [1]. The failure paths have
been improved further still, with some new warning messages on any
cleanup errors as well. Man pages have been updated.
Tests are still lacking. The post-insert hook should be simple, but I
haven't had a sudden outburst of creati
This is v2 of the final three patches of [1]. The failure paths have
been improved further still, with some new warning messages on any
cleanup errors as well. Man pages have been updated.
Tests are still lacking. The post-insert hook should be simple, but I
haven't had a sudden outburst of creati
Felipe Contreras writes:
> A few trivial updates, and an important fix.
>
> Changes since v1: improved commit messages.
I have pushed these to release and master.
d
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Felipe Contreras writes:
> A few trivial updates, and an important fix.
>
> Changes since v1: improved commit messages.
I have pushed these to release and master.
d
pgpFeATpEBPAw.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuc
A few trivial updates, and an important fix.
Changes since v1: improved commit messages.
Felipe Contreras (2):
vim: fix count_threads variable check
vim: improve the way messages are sent
Paul Roberts (1):
vim: make the html handler configurable
vim/notmuch.vim | 39 +
A few trivial updates, and an important fix.
Changes since v1: improved commit messages.
Felipe Contreras (2):
vim: fix count_threads variable check
vim: improve the way messages are sent
Paul Roberts (1):
vim: make the html handler configurable
vim/notmuch.vim | 39 +
On Tue, Aug 27 2013, Mark Walters wrote:
> v2 of this series is at
> id:1377460214-4795-1-git-send-email-markwalters1009 at gmail.com
>
> v2 had a bug on refresh view (which I should have tested more). The
> main pick view only worked by fluke as the initial call to pick-worker
> was inside a let
On Tue, Aug 27 2013, Mark Walters wrote:
> v2 of this series is at
> id:1377460214-4795-1-git-send-email-markwalters1...@gmail.com
>
> v2 had a bug on refresh view (which I should have tested more). The
> main pick view only worked by fluke as the initial call to pick-worker
> was inside a let bi
I should have included a diff from v2: see below (obviously the test in
patch 3 is also new).
Best wishes
Mark
diff --git a/contrib/notmuch-pick/notmuch-pick.el
b/contrib/notmuch-pick/notmuch-pick.el
index f6710e9..5d46d42 100644
--- a/contrib/notmuch-pick/notmuch-pick.el
+++ b/contrib/notm
I should have included a diff from v2: see below (obviously the test in
patch 3 is also new).
Best wishes
Mark
diff --git a/contrib/notmuch-pick/notmuch-pick.el
b/contrib/notmuch-pick/notmuch-pick.el
index f6710e9..5d46d42 100644
--- a/contrib/notmuch-pick/notmuch-pick.el
+++ b/contrib/notm
v2 of this series is at
id:1377460214-4795-1-git-send-email-markwalters1009 at gmail.com
v2 had a bug on refresh view (which I should have tested more). The
main pick view only worked by fluke as the initial call to pick-worker
was inside a let binding.
This version fixes the bug, moves the call
v2 of this series is at
id:1377460214-4795-1-git-send-email-markwalters1...@gmail.com
v2 had a bug on refresh view (which I should have tested more). The
main pick view only worked by fluke as the initial call to pick-worker
was inside a let binding.
This version fixes the bug, moves the call to
This is v2 of id:1376332839-22825-1-git-send-email-amdragon at mit.edu.
This fixes an unintentional temporary test breakage and two typos in
the last patch's commit message. There's no version diff from v1
because the final trees are the same.
Mark Walters writes:
> This is a trivial rebase of
> id:1369551008-30697-1-git-send-email-markwalters1009 at gmail.com to
> current master. I have included the dependent patch
> id:1369550458-30562-1-git-send-email-markwalters1009 at gmail.com
Pushed,
d
This is a trivial rebase of
id:1369551008-30697-1-git-send-email-markwalters1009 at gmail.com to
current master. I have included the dependent patch
id:1369550458-30562-1-git-send-email-markwalters1009 at gmail.com
As I said in id:87sj00xapn.fsf at qmul.ac.uk this removes the worst piece
of code
On Sun, May 26, 2013 at 1:57 AM, Mark Walters
wrote:
> This is a slightly tweaked version of
> id:1367672478-12247-1-git-send-email-markwalters1009 at gmail.com minus
> the first two patches which have already been pushed.
>From a quick read-through, this series looks good to me. I applied the
p
On Sun, May 26, 2013 at 1:57 AM, Mark Walters wrote:
> This is a slightly tweaked version of
> id:1367672478-12247-1-git-send-email-markwalters1...@gmail.com minus
> the first two patches which have already been pushed.
>From a quick read-through, this series looks good to me. I applied the
patch
This is a slightly tweaked version of
id:1367672478-12247-1-git-send-email-markwalters1009 at gmail.com minus
the first two patches which have already been pushed.
The second patch of the previous series obsoleted the handler
notmuch-show-insert-part-inline-patch-fake-part so we remove that and
we
This is a slightly tweaked version of
id:1367672478-12247-1-git-send-email-markwalters1...@gmail.com minus
the first two patches which have already been pushed.
The second patch of the previous series obsoleted the handler
notmuch-show-insert-part-inline-patch-fake-part so we remove that and
we up
Hi
On Sat, 30 Mar 2013, Jani Nikula wrote:
> This is v2 of [1], rebased against master and with a better commit
> message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
> be merged. There was debate on the actual stuff 2/3 and 3/3 [2].
>
> I don't think adding a --reply-to=list o
Hi
On Sat, 30 Mar 2013, Jani Nikula wrote:
> This is v2 of [1], rebased against master and with a better commit
> message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
> be merged. There was debate on the actual stuff 2/3 and 3/3 [2].
>
> I don't think adding a --reply-to=list o
Jani Nikula writes:
> This is v2 of [1]. Added comments per David's request, and while at it,
> added a third patch to conform the existing conditional build in notmuch
> show to the same style. The whole series should have no functional
> changes, and thus v2 should have no functional changes si
Jani Nikula writes:
> This is v2 of [1]. Added comments per David's request, and while at it,
> added a third patch to conform the existing conditional build in notmuch
> show to the same style. The whole series should have no functional
> changes, and thus v2 should have no functional changes si
On Sun, Mar 31 2013, Tomi Ollila wrote:
> On Sat, Mar 30 2013, Jani Nikula wrote:
>
>> This is v2 of [1]. Added comments per David's request, and while at it,
>> added a third patch to conform the existing conditional build in notmuch
>> show to the same style. The whole series should have no fu
On Sat, Mar 30 2013, Jani Nikula wrote:
> This is v2 of [1]. Added comments per David's request, and while at it,
> added a third patch to conform the existing conditional build in notmuch
> show to the same style. The whole series should have no functional
> changes, and thus v2 should have no f
On Sun, Mar 31 2013, Tomi Ollila wrote:
> On Sat, Mar 30 2013, Jani Nikula wrote:
>
>> This is v2 of [1]. Added comments per David's request, and while at it,
>> added a third patch to conform the existing conditional build in notmuch
>> show to the same style. The whole series should have no fu
On Sat, Mar 30 2013, Jani Nikula wrote:
> This is v2 of [1]. Added comments per David's request, and while at it,
> added a third patch to conform the existing conditional build in notmuch
> show to the same style. The whole series should have no functional
> changes, and thus v2 should have no f
This is v2 of [1], rebased against master and with a better commit
message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
be merged. There was debate on the actual stuff 2/3 and 3/3 [2].
I don't think adding a --reply-to=list option to notmuch reply is a good
idea. We should just d
This is v2 of [1]. Added comments per David's request, and while at it,
added a third patch to conform the existing conditional build in notmuch
show to the same style. The whole series should have no functional
changes, and thus v2 should have no functional changes since v1. ;)
I have not tested
This is v2 of [1], rebased against master and with a better commit
message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
be merged. There was debate on the actual stuff 2/3 and 3/3 [2].
I don't think adding a --reply-to=list option to notmuch reply is a good
idea. We should just d
This is v2 of [1]. Added comments per David's request, and while at it,
added a third patch to conform the existing conditional build in notmuch
show to the same style. The whole series should have no functional
changes, and thus v2 should have no functional changes since v1. ;)
I have not tested
Hi
I now have a version which does this `right': using invisibility as with
citations and signatures etc. It is working but I need to look through
more carefully before posting.
Best wishes
Mark
On Mon, 03 Dec 2012, Mark Walters wrote:
> This is rather more polished version of
> id:1351152563
Hi
I now have a version which does this `right': using invisibility as with
citations and signatures etc. It is working but I need to look through
more carefully before posting.
Best wishes
Mark
On Mon, 03 Dec 2012, Mark Walters wrote:
> This is rather more polished version of
> id:1351152563
This is rather more polished version of
id:1351152563-27277-1-git-send-email-markwalters1009 at gmail.com.
The first patch modifies the behaviour of show refresh buffer to keep
state more accurately where possible. It can never be perfect but it
makes a reasonable attempt. This is independent of p
This is rather more polished version of
id:1351152563-27277-1-git-send-email-markwalters1...@gmail.com.
The first patch modifies the behaviour of show refresh buffer to keep
state more accurately where possible. It can never be perfect but it
makes a reasonable attempt. This is independent of patc
On Wed, Nov 14 2012, Ethan Glasser-Camp wrote:
> Austin Clements writes:
>
>> This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
>> This makes Jani's suggested additions to the regexp and adds support
>> for RFC 2392 mid: links, as suggested by Sascha.
>
> This series looks
On Wed, Nov 14 2012, Ethan Glasser-Camp wrote:
> Austin Clements writes:
>
>> This is v2 of id:"1351650561-7331-1-git-send-email-amdra...@mit.edu".
>> This makes Jani's suggested additions to the regexp and adds support
>> for RFC 2392 mid: links, as suggested by Sascha.
>
> This series looks fin
Austin Clements writes:
> This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
> This makes Jani's suggested additions to the regexp and adds support
> for RFC 2392 mid: links, as suggested by Sascha.
This series looks fine to me.
Ethan
Austin Clements writes:
> This is v2 of id:"1351650561-7331-1-git-send-email-amdra...@mit.edu".
> This makes Jani's suggested additions to the regexp and adds support
> for RFC 2392 mid: links, as suggested by Sascha.
This series looks fine to me.
Ethan
_
This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
This makes Jani's suggested additions to the regexp and adds support
for RFC 2392 mid: links, as suggested by Sascha.
This is v2 of id:"1351650561-7331-1-git-send-email-amdra...@mit.edu".
This makes Jani's suggested additions to the regexp and adds support
for RFC 2392 mid: links, as suggested by Sascha.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmai
The first commit is tangentally related. An expected test case output
in test/crypto previously had a filename left unnormalised by
notmuch_json_show_sanitize because it was not followed by comma.
The next commit causes the comma to be present, breaking the expected
output.
In the 2nd commit, a c
The first commit is tangentally related. An expected test case output
in test/crypto previously had a filename left unnormalised by
notmuch_json_show_sanitize because it was not followed by comma.
The next commit causes the comma to be present, breaking the expected
output.
In the 2nd commit, a c
On Fri, 04 May 2012, Mark Walters wrote:
> On Wed, 02 May 2012, Jameson Graef Rollins
> wrote:
>> On Sun, Apr 29 2012, Austin Clements wrote:
>>> I haven't really looked at this series yet, but I do have a quick
>>> high-level question. Why use separate customization variables for the
>>> colo
On Fri, 04 May 2012, Mark Walters wrote:
> On Wed, 02 May 2012, Jameson Graef Rollins wrote:
>> On Sun, Apr 29 2012, Austin Clements wrote:
>>> I haven't really looked at this series yet, but I do have a quick
>>> high-level question. Why use separate customization variables for the
>>> colors
On Thu, May 03 2012, Mark Walters wrote:
> There are a couple of extra reasons why I like the show ones
> separate. One is that I like to colour headerlines of matching messages to
> highlight them, but in search mode that would highlight every
> line. Secondly, I colour some things "negatively" i
On Thu, May 03 2012, Mark Walters wrote:
> There are a couple of extra reasons why I like the show ones
> separate. One is that I like to colour headerlines of matching messages to
> highlight them, but in search mode that would highlight every
> line. Secondly, I colour some things "negatively" i
On Wed, 02 May 2012, Jameson Graef Rollins
wrote:
> On Sun, Apr 29 2012, Austin Clements wrote:
>> I haven't really looked at this series yet, but I do have a quick
>> high-level question. Why use separate customization variables for the
>> colors in search and show mode? Wouldn't it make mor
On Wed, 02 May 2012, Jameson Graef Rollins wrote:
> On Sun, Apr 29 2012, Austin Clements wrote:
>> I haven't really looked at this series yet, but I do have a quick
>> high-level question. Why use separate customization variables for the
>> colors in search and show mode? Wouldn't it make more
On Sun, Apr 29 2012, Austin Clements wrote:
> I haven't really looked at this series yet, but I do have a quick
> high-level question. Why use separate customization variables for the
> colors in search and show mode? Wouldn't it make more sense to set
> the colors just once and use them in both
On Sun, Apr 29 2012, Austin Clements wrote:
> I haven't really looked at this series yet, but I do have a quick
> high-level question. Why use separate customization variables for the
> colors in search and show mode? Wouldn't it make more sense to set
> the colors just once and use them in both
On Mon, 30 Apr 2012, Austin Clements wrote:
> I haven't really looked at this series yet, but I do have a quick
> high-level question. Why use separate customization variables for the
> colors in search and show mode? Wouldn't it make more sense to set
> the colors just once and use them in bot
This is a rebased (but otherwise unchanged) version of
id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com".
It's probably too late for 0.13 but in case anyone would like to look
at it this version applies cleanly to master so should be easier to
test.
The first two patches are bas
I haven't really looked at this series yet, but I do have a quick
high-level question. Why use separate customization variables for the
colors in search and show mode? Wouldn't it make more sense to set
the colors just once and use them in both modes?
BTW, I like how this clearly distinguishes t
On Mon, 30 Apr 2012, Austin Clements wrote:
> I haven't really looked at this series yet, but I do have a quick
> high-level question. Why use separate customization variables for the
> colors in search and show mode? Wouldn't it make more sense to set
> the colors just once and use them in bot
I haven't really looked at this series yet, but I do have a quick
high-level question. Why use separate customization variables for the
colors in search and show mode? Wouldn't it make more sense to set
the colors just once and use them in both modes?
BTW, I like how this clearly distinguishes t
This is a rebased (but otherwise unchanged) version of
id:"1334431301-27303-1-git-send-email-markwalters1...@gmail.com".
It's probably too late for 0.13 but in case anyone would like to look
at it this version applies cleanly to master so should be easier to
test.
The first two patches are basica
Hi,
I don't know how it works in gnus, but at least on the vim mode, the output
generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
field is needed, and also is nice to have the User-Agent.
Besides, in order to avoid creating a new message by hand (possibly fetching
the
Hi Felipe,
On Wed, Apr 18, 2012 at 06:39, Felipe Contreras
wrote:
> I don't know how it works in gnus, but at least on the vim mode, the output
> generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
> field is needed, and also is nice to have the User-Agent.
In the emacs
Hi Felipe,
On Wed, Apr 18, 2012 at 06:39, Felipe Contreras
wrote:
> I don't know how it works in gnus, but at least on the vim mode, the output
> generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
> field is needed, and also is nice to have the User-Agent.
In the emacs
Hi,
I don't know how it works in gnus, but at least on the vim mode, the output
generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
field is needed, and also is nice to have the User-Agent.
Besides, in order to avoid creating a new message by hand (possibly fetching
the
Austin Clements writes:
> This version fixes two minor formatting issues that Tomi pointed out
> [1]. There are no other changes.
>
> [1] id:"m2d382ia9d.fsf at guru.guru-group.fi"
pushed,
d
Austin Clements writes:
> This version fixes two minor formatting issues that Tomi pointed out
> [1]. There are no other changes.
>
> [1] id:"m2d382ia9d@guru.guru-group.fi"
pushed,
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuc
This version fixes two minor formatting issues that Tomi pointed out
[1]. There are no other changes.
[1] id:"m2d382ia9d.fsf at guru.guru-group.fi"
This version fixes two minor formatting issues that Tomi pointed out
[1]. There are no other changes.
[1] id:"m2d382ia9d@guru.guru-group.fi"
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
v2 of id:"cover.1332604895.git.jani at nikula.org" with the following
non-functional changes, addressing David's concerns in mail and IRC:
- do not use C99 style struct assignment in patch 1
- for now, keep tag_message() local to notmuch-restore.c in patch 3
BR,
Jani.
Jani Nikula (3):
cli: r
v2 of id:"cover.1332604895.git.j...@nikula.org" with the following
non-functional changes, addressing David's concerns in mail and IRC:
- do not use C99 style struct assignment in patch 1
- for now, keep tag_message() local to notmuch-restore.c in patch 3
BR,
Jani.
Jani Nikula (3):
cli: refa
On Wed, 14 Mar 2012 12:26:51 +, Mark Walters
wrote:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-exi
On Wed, 14 Mar 2012 12:26:51 +, Mark Walters
wrote:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1...@gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existe
On Wed, 14 Mar 2012 12:26:51 +, Mark Walters
wrote:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1...@gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existe
On Wed, 14 Mar 2012 12:26:51 +, Mark Walters
wrote:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-exi
Quoth Mark Walters on Mar 14 at 12:26 pm:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existent
> "=" tag
Quoth Mark Walters on Mar 14 at 12:26 pm:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1...@gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existent
> "=" tag (i.
The test in the previous patches
id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
triggered the bug accidentally. It accidentally set the exclude tags
to be "=" and "deleted" rather than just "deleted". The non-existent
"=" tag (i.e., the tag that does not occur anywhere in the X
The test in the previous patches
id:"1331551914-28323-1-git-send-email-markwalters1...@gmail.com"
triggered the bug accidentally. It accidentally set the exclude tags
to be "=" and "deleted" rather than just "deleted". The non-existent
"=" tag (i.e., the tag that does not occur anywhere in the Xapi
On Mon, 13 Feb 2012 14:35:31 +0530, "Aneesh Kumar K.V" wrote:
> On Sun, 12 Feb 2012 18:49:36 +, Mark Walters gmail.com> wrote:
> > Here is a rebased version of the notmuch-pick patch set
> > id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly
> > to master since Jani's notmuch-show co
On Sun, 12 Feb 2012 18:49:36 +, Mark Walters
wrote:
> Here is a rebased version of the notmuch-pick patch set
> id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly
> to master since Jani's notmuch-show command line parsing
> has been pushed.
>
> It includes the significant bug fix (
On Mon, 13 Feb 2012 14:35:31 +0530, "Aneesh Kumar K.V"
wrote:
> On Sun, 12 Feb 2012 18:49:36 +, Mark Walters
> wrote:
> > Here is a rebased version of the notmuch-pick patch set
> > id:"87d39k1gvi@qmul.ac.uk". It now applies directly
> > to master since Jani's notmuch-show command line
On Sun, 12 Feb 2012 18:49:36 +, Mark Walters
wrote:
> Here is a rebased version of the notmuch-pick patch set
> id:"87d39k1gvi@qmul.ac.uk". It now applies directly
> to master since Jani's notmuch-show command line parsing
> has been pushed.
>
> It includes the significant bug fix (at
On Sun, 12 Feb 2012 12:39:13 -0800, Jameson Graef Rollins wrote:
> On Sun, 12 Feb 2012 18:49:36 +, Mark Walters gmail.com> wrote:
> > Here is a rebased version of the notmuch-pick patch set
> > id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly
> > to master since Jani's notmuch-show
Here is a rebased version of the notmuch-pick patch set
id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly
to master since Jani's notmuch-show command line parsing
has been pushed.
It includes the significant bug fix (at least for anyone working
with a dark background) from Daniel makin
On Sun, 12 Feb 2012 12:39:13 -0800, Jameson Graef Rollins
wrote:
> On Sun, 12 Feb 2012 18:49:36 +, Mark Walters
> wrote:
> > Here is a rebased version of the notmuch-pick patch set
> > id:"87d39k1gvi@qmul.ac.uk". It now applies directly
> > to master since Jani's notmuch-show command l
On Sun, 12 Feb 2012 18:49:36 +, Mark Walters
wrote:
> Here is a rebased version of the notmuch-pick patch set
> id:"87d39k1gvi@qmul.ac.uk". It now applies directly
> to master since Jani's notmuch-show command line parsing
> has been pushed.
Hey, Mark. Thanks for working on this. How
On Sun, 12 Feb 2012 18:49:36 +, Mark Walters
wrote:
> Here is a rebased version of the notmuch-pick patch set
> id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly
> to master since Jani's notmuch-show command line parsing
> has been pushed.
Hey, Mark. Thanks for working on this.
Here is a rebased version of the notmuch-pick patch set
id:"87d39k1gvi@qmul.ac.uk". It now applies directly
to master since Jani's notmuch-show command line parsing
has been pushed.
It includes the significant bug fix (at least for anyone working
with a dark background) from Daniel making m
This revision addresses Jani's comments. It removes some
const-stripping casts (at the cost of dropping a const from the API),
fixes a delayed free, and cleans up some aesthetics.
This revision addresses Jani's comments. It removes some
const-stripping casts (at the cost of dropping a const from the API),
fixes a delayed free, and cleans up some aesthetics.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/m
On Thu, 19 Jan 2012 00:22:53 +0400, Dmitry Kurochkin wrote:
> Changes in v2 since v1:
>
> * expected results changes for tests moved from patch 2 to 1 where it belong
The patch set looks good to me.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Changes in v2 since v1:
* expected results changes for tests moved from patch 2 to 1 where it belong
Regards,
Dmitry
On Thu, 19 Jan 2012 00:22:53 +0400, Dmitry Kurochkin
wrote:
> Changes in v2 since v1:
>
> * expected results changes for tests moved from patch 2 to 1 where it belong
The patch set looks good to me.
pgpNMumAPxq0s.pgp
Description: PGP signature
___
n
Changes in v2 since v1:
* expected results changes for tests moved from patch 2 to 1 where it belong
Regards,
Dmitry
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Fri, 13 Jan 2012 18:07:01 -0500, Austin Clements wrote:
> This addresses Jani's comments and improves some of the text and code
> comments.
This is a really nice feature addition, Austin. And it works like a
charm. ++1.
A couple of small comments to follow.
jamie.
pgp6BJym8ezVU.pgp
Descr
1 - 100 of 129 matches
Mail list logo
