Re: [PATCH 0/6] notmuch cli config changes
On Thu, Feb 07 2013, David Bremner wrote: > In my experience the environment variable is somewhat dangerous to use > while testing. If left set to the wrong value, it can lead the loss of > tag information. I have never noticed this to be an issue, but if it is variables can be applied only at run time as well: NOTMUCH_CONFIG=/path/to/foo notmuch >> In general, I am a strong advocate of keeping the CLI slim. IMHO, >> adding more options makes the interface clunkier, and the manual harder >> to parse, and I'm against adding things that a normal user would likely >> never use. > > Well, it's are reasonable heuristic, although I might disagree in > general where the cutoff for "normal use" is, as I do in this case. My main point is that shoving every possible thing that can be tweaked into CLI options is imho a bad idea. Look at gpg. The interface is horrible, and the man page is basically impenetrable because it's so loaded with options that it's impossible to figure out how to do the one basic operation you're looking for. But you're right that I'm making a pretty arbitrary distinction. The notmuch CLI already includes options to handle output formatting, etc. that normal users are probably never going to use in their infrequent use of the CLI. In that regard an option to point to a alternate config file doesn't seem that unreasonable. I just don't want to see notmuch fall into the same UI black hole that e.g. gpg did. jamie. pgpQdDZoA5tm9.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/6] notmuch cli config changes
On Thu, Feb 07 2013, David Bremner wrote: > In my experience the environment variable is somewhat dangerous to use > while testing. If left set to the wrong value, it can lead the loss of > tag information. I have never noticed this to be an issue, but if it is variables can be applied only at run time as well: NOTMUCH_CONFIG=/path/to/foo notmuch >> In general, I am a strong advocate of keeping the CLI slim. IMHO, >> adding more options makes the interface clunkier, and the manual harder >> to parse, and I'm against adding things that a normal user would likely >> never use. > > Well, it's are reasonable heuristic, although I might disagree in > general where the cutoff for "normal use" is, as I do in this case. My main point is that shoving every possible thing that can be tweaked into CLI options is imho a bad idea. Look at gpg. The interface is horrible, and the man page is basically impenetrable because it's so loaded with options that it's impossible to figure out how to do the one basic operation you're looking for. But you're right that I'm making a pretty arbitrary distinction. The notmuch CLI already includes options to handle output formatting, etc. that normal users are probably never going to use in their infrequent use of the CLI. In that regard an option to point to a alternate config file doesn't seem that unreasonable. I just don't want to see notmuch fall into the same UI black hole that e.g. gpg did. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130211/95469afd/attachment.pgp>
Re: proposal, move nmbug from ./contrib to ./devel
On Sun, Feb 10 2013, David Bremner wrote: > I mentioned this again on IRC today, and nobody seemed too upset by the > idea. I propose to move nmbug from the contrib subdirectory to the > devel subdirectory. It seems relatively integral to the notmuch > development process at this point, and at least two of the regular > contributors are helping maintain it. > > I'm not posting this as a patch, because file renames are not very > interesting patches. +1 > > d Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: Reply all - issue
On Wed, Jan 30 2013, David Bremner wrote: > Let me step back a level and say that special casing git patch series > strikes me as not yet seeing the problem in enough generality. Others > might disagree, of course. I agree with this statement. So I encounter the thread hijacking problem occasionally, but not frequently enough that I would trust a particular heuristic to cover it. I think I would prefer to just split hijacked threads manually as I encounter them. Just a thought: what if messages with a given tag (e.g. "new-thread") were always treated as the source of a new thread? A message with the given tag could just be (re)indexed with any In-Reply-To/References headers stripped before indexing. This would allow users to break threads manually, and it would mean dump && restore would always return the same state. The actual thread breaking, or specifically where it happens, would have to be thought through a bit. Maybe this could be rolled into notmuch new somehow? Or some other top-level function that applies operations to messages based on tags? jamie. pgpAqCwrFS4TQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Reply all - issue
On Wed, Jan 30 2013, David Bremner wrote: > Let me step back a level and say that special casing git patch series > strikes me as not yet seeing the problem in enough generality. Others > might disagree, of course. I agree with this statement. So I encounter the thread hijacking problem occasionally, but not frequently enough that I would trust a particular heuristic to cover it. I think I would prefer to just split hijacked threads manually as I encounter them. Just a thought: what if messages with a given tag (e.g. "new-thread") were always treated as the source of a new thread? A message with the given tag could just be (re)indexed with any In-Reply-To/References headers stripped before indexing. This would allow users to break threads manually, and it would mean dump && restore would always return the same state. The actual thread breaking, or specifically where it happens, would have to be thought through a bit. Maybe this could be rolled into notmuch new somehow? Or some other top-level function that applies operations to messages based on tags? jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130211/ad7bdfae/attachment.pgp>
notmuch-mutt: Use of uninitialized value.
Since I don’t get your bug tracking system (d’oh ;), here is a bug I encountered with notmuch-mutt using this macro I guess was from the “official” tutorial: # Construct a thread ouf of the marked mail (or something like that, # doesn’t work atm (errors out)) macro index \ "unset wait_key \ /usr/bin/notmuch-mutt thread \ ~/.cache/notmuch/mutt/results/ \ set wait_key" \ "search and reconstruct owning thread (using notmuch)" I hope this still works, best to put it on one line I guess. Error message: Use of uninitialized value in pattern match (m//) at /usr/bin/notmuch-mutt line 124, line 28. Use of uninitialized value $mid in concatenation (.) or string at /usr/bin/notmuch-mutt line 145, line 28. ~Profpatsch -- Proudly written in Mutt with Vim on Archlinux. Q: Why is this email five sentences or less? A: http://five.sentenc.es ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Search using email headers does not work
Hi, I'd like to search for all emails with a defined email header. According notmuch-search(1) [1] this should be a trivial. But I got a very limited results $ notmuch count --exclude=false "X-Mailinglist" 2 where simple $ grep -R "^X-Mailinglist" . ./new/1360572283.M251897P7737Q200Ra1da4988633e0842.zelvantb:X-Mailinglist: opensuse-factory ./new/1360315438.M35384P12994Q25807R1a5203f9da8b1b28.zelvantb:X-Mailinglist: opensuse ./new/1360315441.M705450P13019Q25830R71a1deb928bb7cf3.zelvantb:X-Mailinglist: opensuse ./new/1360315436.M459220P12984Q25797R13d6f3a1f39d2148.zelvantb:X-Mailinglist: opensuse ./new/1360315381.M437845P12634Q25464R3bccd68f2b8fd54f.zelvantb:X-Mailinglist: opensuse ./new/1360315556.M414918P13763Q26528R614e01d632d1c3d8.zelvantb:X-Mailinglist: opensuse ^C shows me, there are hundreds and hundreds of such emails in my local maildir. I use very simple setup generated by notmuch-setup with a basic set of inbox, undread signed and similar tags. Can anyone point me on a correct query string for such search? I have following versions of xapian and notmuch installed $ rpm -q libxapian22 notmuch libxapian22-1.2.8-2.1.2.x86_64 notmuch-0.14-20.3.x86_64 [1] http://notmuchmail.org/manpages/notmuch-search-1/ BTW: please CC me in a reply, I've just signed to the ML, but did not get the you-were-subscribed email from mailman. Thanks for a help Michal Vyskocil -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20130211/01474fc9/attachment.pgp>
Search using email headers does not work
Hi, I'd like to search for all emails with a defined email header. According notmuch-search(1) [1] this should be a trivial. But I got a very limited results $ notmuch count --exclude=false "X-Mailinglist" 2 where simple $ grep -R "^X-Mailinglist" . ./new/1360572283.M251897P7737Q200Ra1da4988633e0842.zelvantb:X-Mailinglist: opensuse-factory ./new/1360315438.M35384P12994Q25807R1a5203f9da8b1b28.zelvantb:X-Mailinglist: opensuse ./new/1360315441.M705450P13019Q25830R71a1deb928bb7cf3.zelvantb:X-Mailinglist: opensuse ./new/1360315436.M459220P12984Q25797R13d6f3a1f39d2148.zelvantb:X-Mailinglist: opensuse ./new/1360315381.M437845P12634Q25464R3bccd68f2b8fd54f.zelvantb:X-Mailinglist: opensuse ./new/1360315556.M414918P13763Q26528R614e01d632d1c3d8.zelvantb:X-Mailinglist: opensuse ^C shows me, there are hundreds and hundreds of such emails in my local maildir. I use very simple setup generated by notmuch-setup with a basic set of inbox, undread signed and similar tags. Can anyone point me on a correct query string for such search? I have following versions of xapian and notmuch installed $ rpm -q libxapian22 notmuch libxapian22-1.2.8-2.1.2.x86_64 notmuch-0.14-20.3.x86_64 [1] http://notmuchmail.org/manpages/notmuch-search-1/ BTW: please CC me in a reply, I've just signed to the ML, but did not get the you-were-subscribed email from mailman. Thanks for a help Michal Vyskocil signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: Reply all - issue
>From many replies I understand manual thread-joining and -breaking exists with >mutt's manual commands and default subject breaking -as Gmail does- would not >be preferred, while not only version control systems vary subjects within a >thread, but also discussions with slight off-topic forks and therefore >slightly changed subjects should stay in the same thread. The reason why I asked my question in the first place is because I have lots of mail-discussions going on between about 10 board-members who are not able to meet in real life often enough to decide everything by conference, so our mailboxes pile up with suggestions, remarks with longer growing thread-histories and evolving addressee-lists. Those addressee-lists vary by individual choice, often without confirmation of other participants to involve some new addressee's, sometimes resulting in leakage. I thought to revive mail2forum, a plug-in for phpBB, to force people to use existing addressee-lists per 'circle' and archive all e-maildiscussions in a forum, so people wouldn't be e-mailed for every subject and could lose/drop their own mail. Threads should be compressed to keep mostly only original messages - if available -, and small citations, or links to original texts if needed. This thread-compression is functionality the existing mail2forum doesn't have, so that's where for example notmuch comes in. Discussing around I understand that phpBB misses the very basic feature of thread-forking: Every slightly off-topic remark in a phpBB-message can only be splitted to a completely new thread. I wonder whether that is blocking for my own situation, as participants in our discussions don't change the subject-line very often, but it could probably affect the viability of mail2forum as an open source-project. I don't see how I can easily manually manipulate threads with a mail client when mail2forum automatically reads and processes new incoming mail, so my efforts with notmuch will probably stick to the 'optional' subject-splitting-solution. As, however, mail2forum should handle postponed e-mail as well (and exchange former quotes with their original texts), probably patching from a manually altered maildir wouldn't be such a big step. I however haven't studied all that's needed there yet. By the way, before I spend too much time on mail2forum - does anyone know an (open source?) group-mail project with user authentication to centrally stored messages that already does have satisfying thread-compression? ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] convert bitmap to unsigned char
Robert Mast writes: > --- Hi Robert, It looks like the git exercise is proving useful. Keep it up! If you look through the git logs a bit you'll find that the overwhelming convention is for a commit message to have a single-line summary followed by a (potentially longer) expanded comment. The convention I like best is for the single-line summary to efficiently describe everything about "what" the patch does. If it's hard to fit this into a single line there's a good chance your patch should be split up. With your commit message here, the one-line summary is great, (and much better than in your first submission). The expanded comment should describe the "why" of the change. And here, your commit message doesn't have anything. So I'm left wondering why your commit exists. Does this save memory? Does this fix some type error or expected alignment somewhere? etc. Please re-submit your patch with a little more explanation of the motivation behind the patch. -Carl PS. I do know that you did have more in the commit message originally, and Austin recommended removing "snide" issues, (doubts and meta-questions about the patch---things that don't belong in the commit history). Your previous commit message was: Reading it in detail I thought it allocated way too much memory and didn't use the full size of the allocated unsigned ints for storing bits. Am I right, and is this the right way to patch code to notmuch? I'm not actually looking at the code in context now, so I can't render a correct commit message, but this attempted rewording should hopefully give you the idea: Using char instead of int allows for simpler definitions of the DOCIDSET macros so the code is easier to understand. --- Am I reading that correctly? Or is there also some space saving happening here as well? Please re-submit a new patch with a commit message that makes things clear one way or the other. Do you see how this "why" part of the commit message is ready to stand alone in our commit history (assuming it's correct and accepted). Meta-questions like "is this even a sane way of doing things?" are great to ask, and very helpful for code reviewers, but best placed after the "---" so that they don't become part of the commit message. Thanks for playing with notmuch! -Carl -- carl.d.worth at intel.com -- 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/20130211/793c744e/attachment.pgp>
Re: [PATCH] convert bitmap to unsigned char
Robert Mast writes: > --- Hi Robert, It looks like the git exercise is proving useful. Keep it up! If you look through the git logs a bit you'll find that the overwhelming convention is for a commit message to have a single-line summary followed by a (potentially longer) expanded comment. The convention I like best is for the single-line summary to efficiently describe everything about "what" the patch does. If it's hard to fit this into a single line there's a good chance your patch should be split up. With your commit message here, the one-line summary is great, (and much better than in your first submission). The expanded comment should describe the "why" of the change. And here, your commit message doesn't have anything. So I'm left wondering why your commit exists. Does this save memory? Does this fix some type error or expected alignment somewhere? etc. Please re-submit your patch with a little more explanation of the motivation behind the patch. -Carl PS. I do know that you did have more in the commit message originally, and Austin recommended removing "snide" issues, (doubts and meta-questions about the patch---things that don't belong in the commit history). Your previous commit message was: Reading it in detail I thought it allocated way too much memory and didn't use the full size of the allocated unsigned ints for storing bits. Am I right, and is this the right way to patch code to notmuch? I'm not actually looking at the code in context now, so I can't render a correct commit message, but this attempted rewording should hopefully give you the idea: Using char instead of int allows for simpler definitions of the DOCIDSET macros so the code is easier to understand. --- Am I reading that correctly? Or is there also some space saving happening here as well? Please re-submit a new patch with a commit message that makes things clear one way or the other. Do you see how this "why" part of the commit message is ready to stand alone in our commit history (assuming it's correct and accepted). Meta-questions like "is this even a sane way of doing things?" are great to ask, and very helpful for code reviewers, but best placed after the "---" so that they don't become part of the commit message. Thanks for playing with notmuch! -Carl -- carl.d.wo...@intel.com pgp_QJvrmT3C4.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] bitmap:improve memory usage using CHAR_BITS and unsigned CHAR
A little bug-fix to learn how to contribute to nutmuch, this time a combined
commit with git rebase to provide one patch from 15.1.
---
lib/query.cc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/query.cc b/lib/query.cc
index e9c1a2d..7381a54 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -39,12 +39,12 @@ typedef struct _notmuch_mset_messages {
} notmuch_mset_messages_t;
struct _notmuch_doc_id_set {
-unsigned int *bitmap;
+unsigned char *bitmap;
unsigned int bound;
};
-#define DOCIDSET_WORD(bit) ((bit) / sizeof (unsigned int))
-#define DOCIDSET_BIT(bit) ((bit) % sizeof (unsigned int))
+#define DOCIDSET_WORD(bit) ((bit) / CHAR_BIT)
+#define DOCIDSET_BIT(bit) ((bit) % CHAR_BIT)
struct visible _notmuch_threads {
notmuch_query_t *query;
@@ -359,11 +359,11 @@ _notmuch_doc_id_set_init (void *ctx,
GArray *arr)
{
unsigned int max = 0;
-unsigned int *bitmap;
+unsigned char *bitmap;
for (unsigned int i = 0; i < arr->len; i++)
max = MAX(max, g_array_index (arr, unsigned int, i));
-bitmap = talloc_zero_array (ctx, unsigned int, 1 + max / sizeof (*bitmap));
+bitmap = talloc_zero_array (ctx, unsigned char, DOCIDSET_WORD(max) + 1);
if (bitmap == NULL)
return FALSE;
--
1.7.9.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: another bug fix release: 0.15.2, in progress.
da...@tethera.net writes: > I plan to do another quick bug fix release, with aidecoe's parallel > build fix and a patch originally from Tomi to make the Emacs tests not > commit suicide right away on certain OSes. > > I didn't include the parallel building patch here since it's already > in master. Apparently not so quick. I've been busy, and it turned out the bug I fixed in the Hurd build process revealed another bug, I think in Emacs, namely that emacs on Hurd segfaults running the notmuch test suite. Anyway, I guess we may as well push these fixes out; I'm a bit curious if Robert is going to revise id:1359917491-17178-1-git-send-email-beheer...@tekenbeetziekten.nl in the near future; in that case I might include that fix as well. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [Spam-verdenking][english 100%] Re: another bug fix release: 0.15.2, in progress.
Robert Mast writes: > David/Austin, > > I sent it as a patch to my previous patch. Is that correct, or should I first > 'revert' the file to 15.1? > > Robert Hi Robert; I didn't see any followup patch from you on the list; can you tell me the message-id? In any case, in general you should send complete patches or or patch series against git master, since we care both about the commit message, and what changes are part of each commit. Most people use the git rebase command to update patches before re-sending them. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
proposal, move nmbug from ./contrib to ./devel
I mentioned this again on IRC today, and nobody seemed too upset by the idea. I propose to move nmbug from the contrib subdirectory to the devel subdirectory. It seems relatively integral to the notmuch development process at this point, and at least two of the regular contributors are helping maintain it. I'm not posting this as a patch, because file renames are not very interesting patches. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] nmbug: only push master branch on nmbug push
Jani Nikula writes: > nmbug pull only merges upstream master, but nmbug push tries to push > all local branches. The asymmetry results in conflicts whenever there > have been changes in the config branch in the origin: LGTM d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: the future of notmuch-vim?
David Bremner writes: > I'm not sure what, if anything to do about the vim frontend. > So, nobody has jumped to the defence of the vim plugin. Unless some better idea emerges in the next week or so, I plan to move it to the contrib/ directory and mark it as deprecated in NEWS. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] nmbug: only push master branch on nmbug push
On Sun, Feb 10 2013, Jani Nikula wrote:
> nmbug pull only merges upstream master, but nmbug push tries to push
> all local branches. The asymmetry results in conflicts whenever there
> have been changes in the config branch in the origin:
>
> $ nmbug push
> To nm...@nmbug.tethera.net:nmbug-tags
> ! [rejected]config -> config (non-fast-forward)
> error: failed to push some refs to 'nm...@nmbug.tethera.net:nmbug-tags'
> hint: Updates were rejected because a pushed branch tip is behind its remote
> hint: counterpart. If you did not intend to push that branch, you may want to
> hint: specify branches to push or set the 'push.default' configuration
> hint: variable to 'current' or 'upstream' to push only the current branch.
> 'git push origin' exited with nonzero value
>
> To fix this, only push the master branch on nmbug push. Any config
> changes need to be done manually via git anyway.
> ---
LGTM.
Tomi
> contrib/nmbug/nmbug |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/nmbug/nmbug b/contrib/nmbug/nmbug
> index f003ef9..fe103b3 100755
> --- a/contrib/nmbug/nmbug
> +++ b/contrib/nmbug/nmbug
> @@ -331,7 +331,7 @@ sub do_log {
> sub do_push {
>my $remote = shift || 'origin';
>
> - git ('push', $remote);
> + git ('push', $remote, 'master');
> }
>
>
> --
> 1.7.10.4
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
RE: [Spam-verdenking][english 100%] Re: another bug fix release: 0.15.2, in progress.
David/Austin, I sent it as a patch to my previous patch. Is that correct, or should I first 'revert' the file to 15.1? Robert -Oorspronkelijk bericht- Van: David Bremner [mailto:da...@tethera.net] Verzonden: zondag 10 februari 2013 2:17 Aan: notmuch@notmuchmail.org CC: Robert Mast Onderwerp: [Spam-verdenking][english 100%] Re: another bug fix release: 0.15.2, in progress. da...@tethera.net writes: > I plan to do another quick bug fix release, with aidecoe's parallel > build fix and a patch originally from Tomi to make the Emacs tests not > commit suicide right away on certain OSes. > > I didn't include the parallel building patch here since it's already > in master. Apparently not so quick. I've been busy, and it turned out the bug I fixed in the Hurd build process revealed another bug, I think in Emacs, namely that emacs on Hurd segfaults running the notmuch test suite. Anyway, I guess we may as well push these fixes out; I'm a bit curious if Robert is going to revise id:1359917491-17178-1-git-send-email-beheer...@tekenbeetziekten.nl in the near future; in that case I might include that fix as well. d . ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] convert bitmap to unsigned char
---
lib/query.cc | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/query.cc b/lib/query.cc
index 046663a..7381a54 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -39,12 +39,12 @@ typedef struct _notmuch_mset_messages {
} notmuch_mset_messages_t;
struct _notmuch_doc_id_set {
-unsigned int *bitmap;
+unsigned char *bitmap;
unsigned int bound;
};
-#define DOCIDSET_WORD(bit) ((bit) / (sizeof (unsigned int) * CHAR_BIT))
-#define DOCIDSET_BIT(bit) ((bit) % (sizeof (unsigned int) * CHAR_BIT))
+#define DOCIDSET_WORD(bit) ((bit) / CHAR_BIT)
+#define DOCIDSET_BIT(bit) ((bit) % CHAR_BIT)
struct visible _notmuch_threads {
notmuch_query_t *query;
@@ -359,11 +359,11 @@ _notmuch_doc_id_set_init (void *ctx,
GArray *arr)
{
unsigned int max = 0;
-unsigned int *bitmap;
+unsigned char *bitmap;
for (unsigned int i = 0; i < arr->len; i++)
max = MAX(max, g_array_index (arr, unsigned int, i));
-bitmap = talloc_zero_array (ctx, unsigned int, (DOCIDSET_WORD(max) + 1) *
sizeof (*bitmap));
+bitmap = talloc_zero_array (ctx, unsigned char, DOCIDSET_WORD(max) + 1);
if (bitmap == NULL)
return FALSE;
--
1.7.9.5
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
