Re: [PATCH] doc: define and use semantic markup for configuration items
David Bremner writes: > This makes sure each configuration item is cross referenceable without > extra markup, and also adds index entries. applied to master d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: document/defcustom notmuch-multipart/alternative-discouraged
David Bremner writes: > This variable is important for people who want to change the default > behaviour when displaying multipart/alternative messages. Previously > it was undocumented. Add a defcustom to help users and copy some > documentation from the wiki. The usual machinery of re-using > docstrings is a bit tricky to use here because it mangles the example > lisp code, and the link to the info node should not be in e.g. the > html page. > > Add a simple test to make sure the switch from defvar to defcustom did > not break something obvious. applied to master d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: WIP: promote nmbug to user sync tool
Hello, On Sat 07 May 2022 at 09:01pm -03, David Bremner wrote: > Sean Whitton writes: > >> Just looking at my current usage, there are two cases where I've wrapped >> nmbug in some additional myrepos scripting. The first is a status >> command: >> >> status = >> nmbug-spw status | grep -v "^U\s" || true >> # `nmbug status` does not catch committed but unpushed changes >> git --no-pager log --branches \ >> --not --remotes \ >> --simplify-by-decoration --decorate --oneline >> >> Possibly notmuch-git could learn how to do this? > > Perhaps. I think I would prefer something a bit more concise like a > count of unpushed commits. Do you tend to actually have meaningful > commit messages? I don't. I just want output if there are unpushed changes and no output if not. A count sounds good to me. > Personally I would be more worried about checkout (e.g. after init) > wiping out my notmuch database, since an errant commit can always be > reverted. Both cases seem to be covered by your heuristic. Perhaps we > could just count the size of the update, and insist on a --force option > if it is too large. I think you're right. It makes sense to build in safety features only for the case of accidentally wiping out the db. Either instead or in addition to something size-based, how about requiring --force if there do not exist any tags with the prefix in the notmuch database already? The size thing is brittle; in my scripting attempts, I've encountered several annoying edge cases. > For what it's worth, you can already call > > notmuch git -C $HOME/lib/nmbug-spw -p spw:: ... > > if that is more convenient. > > The defaults have already changed in my latest working branch so the > default repo is under $XDG_DATA_HOME/notmuch/$NOTMUCH_PROFILE/git, and > the default prefix is ''. But re-reading this, I see see we polled two > people and got two answers for what a reasonable default prefix is, so a > configuration item is definitely needed for prefix. Probably it is also > reasonable to have one for repo location. Coolio. -- Sean Whitton ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [BUG] notmuch_message_tags_to_maildir_flags does not always invalidate filenames_list
Eliza Velasquez writes:
> Hello notmuch,
>
> As the subject says, it seems like the filename cache for a message is
> not reliably invalidated when notmuch_message_tags_to_maildir_flags is
> called, causing the following series of function calls to behave
> unexpectedly.
>
> - notmuch_database_index_file
> - notmuch_message_get_filenames
> - notmuch_message_tags_to_maildir_flags
> - notmuch_message_get_filenames (stale list returned)
>
> According to the investigator [1], this happens about 10% of the time,
> but it's possible that this is just because there is some quirk in the
> client-side code causing it to trigger only sometimes.
that cache is supposed to be invalidated by calls to
_notmuch_message_add_filename and
_notmuch_message_remove_filename. There is one unchecked call to
_notmuch_message_add_term that looks a bit suspect. The obvious thing
that can go wrong is filename getting too long. Here is a patch to maybe
return better diagnostics in that case
diff --git a/lib/message.cc b/lib/message.cc
index 63b216b6..bebc5f6a 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -169,6 +169,7 @@ _notmuch_message_create_for_document (const void
*talloc_owner,
message->doc = doc;
message->termpos = 0;
+message->modified = FALSE;
return message;
}
@@ -937,6 +938,7 @@ _notmuch_message_add_filename (notmuch_message_t *message,
{
const char *relative, *directory;
notmuch_status_t status;
+notmuch_private_status_t private_status;
void *local = talloc_new (message);
char *direntry;
@@ -960,7 +962,11 @@ _notmuch_message_add_filename (notmuch_message_t *message,
/* New file-direntry allows navigating to this message with
* notmuch_directory_get_child_files() . */
-_notmuch_message_add_term (message, "file-direntry", direntry);
+private_status = _notmuch_message_add_term (message, "file-direntry",
direntry);
+status = COERCE_STATUS (private_status,
+ "Unexpected error from _notmuch_message_add_term");
+if (status)
+ return status;
_notmuch_message_add_folder_terms (message, directory);
_notmuch_message_add_path_terms (message, directory);
The other issue that might cause intermittent failures is uncaught
exceptions. We cleaned a bunch of those up a few years ago, but it looks
like we missed a few spots. Off hand I'm not sure what would be causing
such exceptions, but _notmuch_message_add_term and
_notmuch_message_remove_term should probably have the Xapian operations
wrapped in try / catch blocks.
It might be worth running the failing test under gdb to see if you can
spot exceptions.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [bug] possible condition depending on uninitialized value in _notmuch_message_sync
Eliza Velasquez writes: > On Mon, May 16 2022 at 06:47 -03, David Bremner wrote: > >> Ideally of course I'd like a reproducer in C. It would help to have >> line numbers in the valgrind output. It might be enough you install the >> notmuch debug symbols? > > Took me a while to figure out the debugging workflow in NixOS, but I > managed to capture the line numbers. At messsage.cc:1333, at the second > condition below: > [snip] > So I guess `message->modified' isn't correctly initialized, at least > according to valgrind. > > -- > Eliza Can you see if the following change quiets valgrind? diff --git a/lib/message.cc b/lib/message.cc index 63b216b6..bd3cb5af 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -169,6 +169,7 @@ _notmuch_message_create_for_document (const void *talloc_owner, message->doc = doc; message->termpos = 0; +message->modified = FALSE; return message; } ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[BUG] notmuch_message_tags_to_maildir_flags does not always invalidate filenames_list
Hello notmuch, As the subject says, it seems like the filename cache for a message is not reliably invalidated when notmuch_message_tags_to_maildir_flags is called, causing the following series of function calls to behave unexpectedly. - notmuch_database_index_file - notmuch_message_get_filenames - notmuch_message_tags_to_maildir_flags - notmuch_message_get_filenames (stale list returned) According to the investigator [1], this happens about 10% of the time, but it's possible that this is just because there is some quirk in the client-side code causing it to trigger only sometimes. [1] https://github.com/elizagamedev/mujmap/pull/10#issuecomment-1131587169 -- Eliza ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
