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.
Although the rebuild does not take long, it is a bit noisy, so assume
if it succeeds once, it doesn't need to re-invoke setup.py until the
shared library is rebuilt. This is a partial fix for [1].
[1]: id:87r29wwgq2.fsf@fifthhorseman.net
The directory is (neccesarily) not updated by the build, so it keeps
trying to build. The proposed fix is to use the name of the dynamic
library containing the extension. This is a partial fix for the
rebuilding reported at [1].
[1]: id:87r29wwgq2.fsf@fifthhorseman.net
Apparently this messes up various third party completion
frameworks. This change does mean that users will have to hit space
after completing a tag change in order to enter another change.
As a bonus, remove the call to #'delete, since
completing-read-multiple already promises to remove empty strings.
There is a certain amount of boilerplate to pass the call on the
original function, so abstract it out as a C preprocessor macro, plus
some extra includes in notmuch-test.h
Unlike the previous g_key_file_get_value, this version processes
escape codes for whitespace and \. The remaining two broken tests from
the last commit are because "notmuch config get" treats every value as
a list, and thus the previously introduces stripping of leading
whitespace applies.
glib generates the following escape characters with their usual
meanings: \n, \t, \r, and \\, along with \s for _leading_
spaces. Currently notmuch fails to unescape these on reading the
config files. These tests demonstrate this bug; the one new test that
passes is because apparently glib only escapes tabs at the beginning
of a key.
In [1] Ciprian observed that it was easy for users to mistakenly
introduce leading and trailing space to new.tags when editing a
notmuch config file. This commit strips spaces on either side of the
';' delimiter when splitting.
In principle it would be possible to support tags (or other config
values) with leading or trailing spaces by processing '\s' escapes in
the input string. Currently such processing is not done.
[1]: id:CA+Tk8fzjPLaEd3vL1f9ebk_bF_RV8PDTLzDupraTkCLCpJAmCg@mail.gmail.com
