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
In message id:YT3ueuZHKW931NW3@localhost, Fabio Natali isolated a
visual glitch caused by running notmuch-search-hook too early. This
change moves the running of that hook to
notmuch-search-process-filter, which ensures there is some output in
the buffer before running the hook. Since n-s-p-f can be called many
times for a given buffer, add a buffer local flag to make sure it is
only run once per buffer.
Since release 0.32, libnotmuch provides searching for database and
configuration paths. This commit changes the python module notmuch2 to
use those facilities.
This fixes the bug reported in [1], along with a couple of the
deprecation warnings in the python bindings.
Database.default_path is deprecated, since it no longer faithfully
reflects what libnotmuch is doing, and it is also no longer used in
the bindings themselves.
This commit choose the default of config=CONFIG.EMPTY (equivalent to
passing "" to notmuch_database_open_with_config). This makes the
change upward compatible API-wise (at least as far as the test suite
verifies), but changing the default to CONFIG.SEARCH would probably be
more convenient for bindings users.
[1]: id:87h7d4wp6b.fsf@tethera.net
If the user passed a path, and we opened it, then we consider that
definitive definition of "database.path". This makes libnotmuch
respond more gracefully to certain erroneous combinations of
NOTMUCH_CONFIG settings and config file contents.
This is arguably user error: having configuration file with bad
settings in it (and/or having a bad NOTMUCH_CONFIG environment
variable). On the other hand returning a different path than was
actually opened is definitely a bug.
The <backtab> binding has always been there, but the docs were
apparently mistakenly changed to say <backspace> [1]
Revert to <backtab> in the documentation.
The commit also drops the C-<tab> binding, since it seems redundant
and it interferes with tab-bar-mode.
[1]: 703dec7754.
Previously the python-cffi bindings either failed to build, or built
for the wrong module by using the installed module.
The fix requires correction the module path, building the bindings
before docs, and helping python find the built libnotmuch.
Based on patch / discussion from Micheal Gruber [1]
[1]: id:cover.1634808719.git.git@grubix.eu
It is confusing to use two different names (sexp vs sexpr) when
compared with the command line option --query=sexp and (furthermore)
singular vs plural when compared with the man page title.
