Failing to update this string in globals.py causes failures when the
SONAME changes. In order to hopefully reduce the number of such
errors, automate the process of setting the SONAME in the python
bindings.
Notmuch uses long options exclusively all around. The short options in
notmuch-emacs-mua are intentionally just a compatible subset of
mutt(1). Keep it this way, if only to make documenting the fact easy!
The Notmuch style --client long option remains, of course.
If seconds are not specified in the string to be parsed, they're not
set according to the reference time (in the no rounding case) nor
rounded properly (in the rounding up cases). Fix this.
The bug caused searches such as date:10:30..10:30 to match messages
with date exactly 10:30:00 only, and not in range 10:30:00..10:30:59
(inclusive) as documented.
Note that date searches referring "noon" or "5pm" will still be
interpreted as exact to the second.
Extract and add some more tests relating to rounding seconds into a
separate subtest, and flag it as broken. If seconds are not specified,
the time is not set or rounded according to the interface defined in
parse-time-string/parse-time-string.h. Instead, seconds are always set
to 00 in reality, which is broken.
Set the reference time to 12:13:14 instead of 11:11:00 to ensure hours
and minutes are not mixed up, and seconds are really set instead of
defaulted to 00.
This is actually generated by the script in
id:1420289900-29717-2-git-send-email-david@tethera.net
We may as well update the list of commands while we decide if it's
worth automating the process. Note that there is a bit more noise than
expected because it alphabetizes all of the commands with their own
man pages.
The install_name of libnotmuch.dylib on Mac OS X is what is written
into a program that links against it. If it is just the name of the
shared library file, as opposed to the full path, the program won't be
able to find it when it runs and will abort. Instead, the install_name
should be the full path to the shared library (in its final installed
location).
Why does Notmuch work without this patch when installed via Homebrew?
The answer is twofold. One, /usr/local/lib is a special location in
which the dynamic linker will look by default to find shared libraries.
Homebrew highly recommends installing to /usr/local, and, assuming it
has been configured this way, the Notmuch library will end up installed
in /usr/local/lib, and the dynamic linker will find it. Two, Homebrew
globally corrects all install names in dynamically shared libraries and
binaries for each package it installs. So, even if the install names in
a package's binaries and libraries are incorrect, Homebrew corrects them
automatically, and no one ever knows.
Why does Notmuch work without this patch when installed via MacPorts?
The answer is that MacPorts applies a patch just like this patch to fix
the same problem.
This indicates upwardly compatible changes, namely adding new symbols.
Although we don't formally need to do this until the next release,
there is no hard in doing it now, as long as we don't bump the minor
version for every addition between now and the release.
This at least allows distinguishing between out of memory and Xapian
exceptions. Adding finer grained status codes would allow different
Xapian exceptions to be preserved.
Adding wrappers allows people to transition gradually to the new API,
at the cost of bloating the library API a bit.
Fix the following warning produced by clang 3.5.0:
notmuch-search.c:730:25: warning: initializing 'void *' with an
expression of type 'const notmuch_opt_desc_t (*)[4]' discards
qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
{ NOTMUCH_OPT_INHERIT, &common_options, NULL, 0, 0 },
^~~~~~~~~~~~~~~
1 warning generated.
When the shell builtin `command -v` operates normally, it either
prints the path of the arg given to it and returns zero -- or it
returns nonzero and prints nothing.
In abnormal situations something might be printed to stderr and
in that case we want to know about it; therefore the used
command -v stderr redirections to /dev/null have been removed.
The `hash` (builtin) command in ksh returns zero even the arg
given to is is not found in path. For that and for consistency
the one appearance of it has been converted to `command -v`.
For those messages, compute a synthetic Message-ID based on the SHA1
of the whole message, in the same way that notmuch would do. See:
http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/sha1.c
To do the above, rewrite get_message_id() to accumulate header lines,
parse them to check for Message-ID, and fallback to SHA1 computation
if it is not present.
Thanks to:
- Jan N. Klug for preliminary versions of this patch
- Tomi Ollila for suggesting an elegant implementation
Besides generally cleaning up the code and separating the general
content ID handling from the w3m-specific code, this fixes several
problems.
Foremost is that, previously, the code roughly assumed that referenced
parts would be in the same multipart/related as the reference.
According to RFC 2392, nothing could be further from the truth:
content IDs are supposed to be globally unique and globally
addressable. This is nonsense, but this patch at least fixes things
so content IDs can be anywhere in the same message.
As a side-effect of the above, this handles multipart/alternate
content-IDs more in line with RFC 2046 section 5.1.2 (not that I've
ever seen this in the wild). This also properly URL-decodes cid:
URLs, as per RFC 2392 (the previous code did not), and applies crypto
settings from the show buffer (the previous code used the global
crypto settings).
Unibyte strings are meant for representing binary data. In practice,
using unibyte versus multibyte strings affects *almost* nothing. It
does happen to matter if we use the binary data in an image descriptor
(which is, helpfully, not documented anywhere and getting it wrong
results in opaque errors like "Not a PNG image: <giant binary spew
that is, in fact, a PNG image>").
`notmuch-get-bodypart-content' could do two very different things,
depending on conditions: for text/* parts other than text/html, it
would return the part content as a multibyte Lisp string *after*
charset conversion, while for other parts (including text/html), it
would return binary part content without charset conversion.
This commit completes the split of `notmuch-get-bodypart-content' into
two different and explicit APIs: `notmuch-get-bodypart-binary' and
`notmuch-get-bodypart-text'. It updates all callers to use one or the
other depending on what's appropriate.
The new function, `notmuch-get-bodypart-binary', replaces
`notmuch-get-bodypart-internal'. Whereas the old function was really
meant for internal use in `notmuch-get-bodypart-content', it was used
in a few other places. Since the difference between
`notmuch-get-bodypart-content' and `notmuch-get-bodypart-internal' was
unclear, these other uses were always confusing and potentially
inconsistent. The new call clearly requests the part as undecoded
binary.
This is step 1 of 2 in separating `notmuch-get-bodypart-content' into
two APIs for retrieving either undecoded binary or decoded text.
Questions related to the way that probabilistic prefixes and phrases
are handled come up quite often and it is nicer to have the documentation self contained. Hopefully putting it in subsections prevents it from being overwhelming.
Adds new entry to the NEWS file, and updates the search terms section
of the man page. The search terms section needs to be updated again
once the new section in the documentation covering probablistic terms
has been committed.
This adds the indexing support for the "mimetype:" term and removes
the broken test flag. The indexing is probablistic in Xapian terms,
which gives a better experience to end users. Standard content-types
of the form "foo/bar" are automatically interpreted as phrases in
Xapian due to the embedded slash.
Assume, separate messages with application/pdf and application/x-pdf
are indexed, then:
- mimetype:application/x-pdf will find only the application/x-pdf
- mimetype:application/pdf will find only the application/pdf
- mimetype:pdf will find both of the messages
This feature will exist in all newly created databases, but there is
no upgrade provided for it. If this flag exists, it indicates that
the database was created after the indexed MIME-types feature was
added.
Adds three failing unit tests for searching of mime-types.
An attempt was made at adding a negative test (i.e. searching for a
non-existent mime-type and ensuring it didn't return a message), but
that test would always pass making it pointless.
We set header-line-format to the message subject, but if the subject
contains percents, the next character is interpreted as a formatting
control, which is not desired.
