Since the bug was first reported in [1], notmuch has gained the
ability to have the database located outside the mail root, hence this
this change differs slightly from Jani's proposed solution [2] in not
using notmuch_database_get_path, but rather the already retrieved
mail_root.
[1]: id:87mwhifu9a.fsf@trouble.defaultvalue.org
[2]: id:87ios5v59p.fsf@nikula.org
In [1] Rob observed that notmuch new ignored directories called
.notmuch everywhere in the tree, where they should only (and now, with
split configs, at most) be ignored at the top level. Add a test to
demonstrate the problem.
[1]: id:87mwhifu9a.fsf@trouble.defaultvalue.org
If we know the configuration is split, but there is no mail root
defined, this indicates a (lack of) configuration error. Currently
this can only arise in XDG configurations.
The extra talloc struct "local" was left over from before the notmuch
struct was allocated earlier. Having the notmuch struct available in
this function will allow more flexibility to track the configuration
variations (e.g. split vs. non-split).
If notmuch_database_open_with_config finds a database, but that
database is not in a legacy, non-split configuration, then it
currently incorrectly deduces the mail root and returns SUCCESS. Add
to two tests to demonstrate this bug.
emacs-mac that compiled with OS X system API for image display
support cannot correctly render svg without xmlns parameter [1].
[1]: id:tencent_127AA231767438AC66FEE4DDB4BBF51DF909@qq.com
As stressed by the gpg documentation, the non-'with-colons' output
format is subject to change, and indeed it did in 2.3.x (x<=3). This
should make the the test suite more robust against such changes.
New notmuch-show-header-line customizable boolean to allow inhibiting
a header line in notmuch-show-mode buffers (for instance, because one
prefers to just include Subject in notmuch-message-headers).
The previous (pre-0.34.2) constructor searched for a config file but
only if the database path was not specified, and only to retrieve
database.path. Neither of the available options (CONFIG.SEARCH or
CONFIG.NONE) matches this semantics exactly, but CONFIG.SEARCH causes
less breakage for people who relied on the old behaviour to set their
database.path [1]. Since it also seems like the friendlier option in
the long run, this commit switches to CONFIG.SEARCH as default.
This requires a certain amount of updating the pytest tests, but most
users will actually have a config file, unlike the test environment.
[1]: id:87fsqijx7u.fsf@metapensiero.it
If we return regular Message objects, python will try to destroy them,
and the underlying notmuch object, causing e.g. the crash [1].
[1]: id:87sfu6utxg.fsf@tethera.net
This reproduces the bug reported at [1]. The second test hints at the
solution, making reply return OwnedMessage objects.
[1]: id:87sfu6utxg.fsf@tethera.net
Since mail store and database directory can be different,
path and folder completions must use the directory given by
database.mail_root, not by database.path.
The mail store directory is given by database.mail_root,
which can be different from database.path.
However, notmuch-insert documentation was still referencing the latter
as the provider of the maildir directory instead of the former.
Existing users of the legacy python bindings use
message.get_flags(Message.FLAG.MATCH) to determine which messages in a
thread matched. Since the bindings don't provide get_flags anymore,
they should provide a property analogous to the existing "excluded"
property.
In addition to avoiding problems with user specified include paths
picking up an installed version of notmuch.h, this should also enable
users to override more options (in particular they could override
warning options since the last one takes effect).
[1]: id:7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com
In [1] Ryan Schmidt reported a problem on macports [2] with notmuch
finding an existing installed version of notmuch.h during the build.
This is a partial fix; the user might also specify -I in CFLAGS.
[1]: id:7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com
[2]: The problem does not arise when notmuch.h is installed into a
"system" include path that the compiler searches by default.
In [1] Ryan Schmidt reported a problem on macports [2] with notmuch
finding an existing installed version of libnotmuch during the build
when the user specified LDFLAGS including the libnotmuch install
directory.
This change should prevent that.
LDFLAGS also occurs in FINAL_LIBNOTMUCH_LDFLAGS. The only built
library linked to that is util/libtnotmuch_util.a, and that passed as
explicit (relative) path, and is thus not affected by -L.
[1]: id:7851CAB5-4556-4931-A0A2-37003E56C927@ryandesign.com
[2]: The problem does not arise when libnotmuch is installed into a
"system" library path that the compiler/linker searches by default.
Jani reported that lines prefixed with '>' (as opposed to '> ') are
not highlighted properly [1]. David E responded with a updated regex
[2]. This change implements David E's suggestion.
[1]: id:87a8b5pcky.fsf@nikula.org
[2]: id:m2pok1e3gv.fsf@dme.org
This will correct the current use of an undefined variable when
setting LD_LIBRARY_PATH in doc/Makefile.local
It is tempting to try to replace the use of test/export-dirs.sh, but
this is not as simple as it looks, as NOTMUCH_BUILDDIR is used to
locate sh.config, so probably cannot also sensibly be used to define
it.
It makes perfect sense for users to want to pre-create .notmuch,
e.g. to install hooks, so we should handle the case of a .notmuch
directory without an actual xapian database more gracefully.
`notmuch new' should go ahead and create the xapian database if it is
missing, even in the case where the parent .notmuch (or equivalent)
directory exists.
In [1] Mark Walters reported a problem with messages being removed
from the database when the parent directory was renamed. Jani Nikula
proposed [2] these tests but observed
This test is not suitable for merging since it's not deterministic.
After applying Jani's patch [3], the tests now pass deterministically,
and could usefully act as regression tests.
[1]: id:87siray6th.fsf@qmul.ac.uk
[2]: id:1393191650-28333-1-git-send-email-jani@nikula.org
[3]: id:1441445731-4362-2-git-send-email-jani@nikula.org
In [1] Daniel observed that the gzipped man pages were only being
rebuild every second time when building with `make -j4'. This may be
caused by a race condition between sphinx-build rebuilding the roff
files and the recipe to gzip them. This commit sequentializes these
two steps by making the stamp file a prerequisite for (all of) the
gzip files.
[1]: id:87tveotn1g.fsf@fifthhorseman.net
emacs/notmuch-logo.svg is handcrafted scalable vector graphics version
of the notmuch logo.
Emacs on graphic displays render this image four times in size compared
to the emacs/notmuch-logo.png, and the image is much sharper.
The rendered image size, 100x100 pixels, fits reasonably well with
text shown in various font sizes.
Scaling the image -- if desired -- may come in the future. For now
this is improvement on how the logo looked in notmuch-hello window.
The docstrings for notmuch-tree-match-author-face and
notmuch-tree-no-match-author-face incorrectly match the docstring of
notmuch-tree-match-date-face.
Since set -u is used, without bash or perl, configure would fail.
This has gone unnoticed as (almost) everyone always had both
bash and perl installed (and in $PATH).
Thanks to FreeBSD ports this bug became visible; this change is
verbatim copy of `patch-configure` in FreeBSD ports tree.
The remaining problem in this test is fixed upstream in Emacs
28. While most people are using earlier versions of emacs, the test
still provides some documentation of a known bug.
The main idea is to replace the hack of copying version.txt into the
bindings source with a generated _notmuch_config.py file.
This will mean that the bindings only build after configuring and
building notmuch itself. Given those constraints, "pip install ."
should work.
