This was a misfeature where notmuch had extra code that just threw
away legitimate information. It was never indexing an initial "Re"
term in a subject. But some users have legitimately wanted to search
for this term.
The original code was written this way merely for strict compatiblity
with the indexing performed by sup, but we're not taking advantage of
that now anyway.
As mentioned in the recent test commits, this also fixes the missing
'[' and ']' characters in the --format=json variant of "notmuch search
--output=tags" as well.
This testing *does* capture the bug of missing '[' and ']' characters
int "notmuch search --output=tags" case. This is another manifestation
of the same bug causing the missing final newline (as mentioned in the
previous commit).
This code simply wasn't being exercised by the test suite before, so
this will be useful.
Meanwhile, there's currently a bug in "notmuch search --output=tags"
in that it doesn't print a final newline. But the current test suite
isn't able to catch this bug since the $() construct of the shell
doesn't preserve the distinction of whether the final newline is
present or not.
Emacs22 lacks apply-partially and mouse-event-p, so define them if emacs
version is less than 23. With this change, I was able to begin using
notmuch in emacs22.
The definitions of apply-partially and mouse-event-p are copied from
the emacs 23 distribution, (which is distributed under the GPLv3+ just
as notmuch).
This test script does some initial test setup (generating a few
messages), which is all well and good, but we don't need to print that
as a test result---particularly since the test result was effectively
hard-coded to always pass.
When test_begin_subtest is not followed by corresponding test_expect_equal,
the output of the rest of the test script is errornously suppressed. Add
code to detect these bugs in test scripts.
Break notmuch-test whenever a test script returns non-zero status.
This happens either when some test from the script fails or when there
is an error in the script.
This is especially useful in the latter case since the error may not
appear in the final aggregated results.
The newline was removed from say_color in commit 222926ab to allow
printing test status in the beginning of the line. Error messages are
never followed by other text so we add the newline to error function.
Git-style tests (test_expect_success etc.) suppress stdout and stderr
unless -v is given. Notmuch-style tests (created by test_begin_subtest
and test_expect_equal) do not have this behavior so implement it the
same.
Additionally, for both test styles, the test-lib.sh is changed so that
the content of suppressed stdout and stderr is shown in case of failed
test.
Finally a test for this functionality is added to basic tests.
Explained-by: Carl Worth: This gives convenient keybindings for
navigating the file and for quitting from the buffer, (since, with a
raw message file the user will generally want to just view the
message, not edit it).
With --modversion we were asking for output that we were just throwing
away anyway. The --exists option does just what we want, (no output
and communivating only via return value).
Also, --exists allows for testing versions of the package as well.
The big change here is the support for maildir-flag synchronization.
But there are a number of other thigns as well---library support for
multiple filenames, new ruby bindings, improvements to the vim
interface, and a few tweaks to the emacs interface.
This add a "stash-map" for search-mode, just like in show-mode, and
adds one function, bound to "i" to stash the thread-id of the current
selected thread.
Couldn't think of the correct way to stash other thread info, so I
didn't add any other stash functions for now.
Here we move the notmuch-show/notmuch-show-do-stash function to
notmuch-lib/notmuch-common-do-stash. Nothing in this function is
notmuch-show mode specific, so this move will make it cleaner to be
used by other modes (such as notmuch-search).
Re-work the declaration and definition of `notmuch-fcc-dirs'. The
variable now allows three types of values:
- nil: no Fcc header is added,
- a string: the value of `notmuch-fcc-dirs' is the name of the
folder to use,
- a list: the folder is chosen based on the From address of the
current message using a list of regular expressions and
corresponding folders:
((\"Sebastian@SSpaeth.de\" . \"privat\")
(\"spaetz@sspaeth.de\" . \"OUTBOX.OSS\")
(\".*\" . \"defaultinbox\"))
If none of the regular expressions match the From address, no
Fcc header will be added.
Remove 're: ' or 'Re: ' from anywhere within a subject line rather
than just at the beginning. This is to accommodate threads where a
mailing list sometimes inserts a subject prefix.
For example, if a thread has the subjects:
[Orgmode] org-indent, org-inlinetask: patches on github
Re: [Orgmode] org-indent, org-inlinetask: patches on github
[Orgmode] Re: org-indent, org-inlinetask: patches on github
the last of these would not have been considered the same and would
therefore have been shown.
This is to prevent notmuch from destroying any information the user
has encoded as flags in the maildir filename. Tests are also added to
the test suite to verify the documented behavior.
Some people use notmuch with non-maildir files, (for example, email
messages in MH format, or else cool things like using sluk[*] to suck
down feeds into a format that notmuch can index).
To better support uses like that, don't do any renaming for files that
are not in a directory named either "new" or "cur".
[*] https://github.com/krl/sluk/
I had originally hoped for better semantics, such as doing nothing in
non-maildir directories, and preserving unknown maildir flags that
happen to be present.
We could still do those things, of course, but for now, remove them
from the documentation since the implementation does not do these
things yet.
The intent of "notmuch setup" is that it adds new, documented sections
to configuration files that were created before such sections were
defined. But to make this work, we have to explicitly set an option
in the maildir group if it didn't exist previously.
The FCC code saves a message in maildir format, and sets the S flag by
default, so now, automatically, FCC messages will not show up as
"unread", (which seems natural enough).
This synchronization is one of those features that should just happen
automatically. We allow for customization in case someone *really*
wants to turn it off, but we don't need to prompt for this
interactively.
People with special needs can find the configuration file on their
own.
It is totally legitimate for a non-maildir directory to be named "new"
(and not have a directory next to it named "cur"). To support this
case at least, be silent about any rename failure.
There's nothing in the current API documentation that would suggest
the behavior being tested here. Attempt to implement this could have
some nasty side effects, (such as notmuch_message_maildir_flags_to_tags
implicitly calling notmuch_message_tags_to_maildir_flags and maybe
even opening up some bad looping possibilities).
Much better to stick with what we have documented, which we believe will
actually be useful, (and easy enough to comprehend).
If a filename has no maildir info at all, (that is, it does not
contain the sequence ":2,"), we consider this distinct from a filename
with an empty maildir info, (the ":2," separator is present, but no
flags characters follow).
Specifically, we regard a missing info field as providing no
information, so tags will remain unchanged. On the other hand, an info
field that is present but has no flags set will cause various tags to
be cleared, (or in the case of "unread", added).
This fixes the "remove info" case of the maildir-sync tests in the
test suite.
When a file in the mailstore is renamed, this appears to "notmuch new"
as both an added file and a removed file (for the same message). We
want the synchronization of the maildir_flags to reflect the final
state, (after the rename is complete). Therefore, it's incorrect to
perform the synchronization immediately after adding a new
file. Instead we queue up these synchronizations (by message ID[*])
and perform them after the removals are complete.
With this change, the "dump/restore" case of the maildir-sync tests,
as well as the recent "remove 'S'" case both now pass where they were
failing before.
Interestingly, the "remove info" test was passing before, but now
fails. This is actually due to a separate bug, (and the bug just fixed
was masking it, by preventing the test from performing as desired).
[*] It's important to queue by message ID---queueing actual message
objects does not work since the message objects will retain stale data
such as the old filenames.
Previously the documentation of notmuch_message_maildir_flags_to_tags
suggested that the presence of a flag would cause tags to be added,
(or in the case of "unread", removed). But the case of absent maildir
flags was not explicitly described.
What we actually want, is that for supported flags, the absence of the
flag in all messages causes the corresponding tag to be removed,
(or in the case of "unread", added). So document that explicitly.
This is the case recently added to the test suite as a failing test,
(so we'll need to do bug fixing before the documentation is honest
here).
