It turns out that using nm -P isn't as portable as hoped. In
particular with some ELF ABIs (e.g. ppc64 ELFv1), the desired symbols
end up in the data section instead of text.
The test is currently only functional on ELF based architectures, so I
think it's legit to depend on readelf instead of nm.
The switch to readelf has the advantage that we can explicitely ask
for all of the symbols with global visibility, rather than grepping
for notmuch. That seems a more robust approach since it will catch any
strangely named global symbols.
Under a sufficiently high level of parallelism [1] there seems to be a
a race condition that allows sphinx-build to start running before the
docstrings are extracted. This change moves the docstring stamp from
the phony targets sphinx-html and sphinx-info to the file targets that
they depend on. I'm not sure why this makes things better, but I am
fairly confident it does not make things worse, and experimentally it
seems to eliminate the race condition.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976934
One should never bind unnamed commands in keymaps because doing that
makes it needlessly hard for users to change these bindings.
Replace such anonymous bindings with named commands that are generated
using macros and some boilerplate. Using macros is better than using a
simple loop because that makes it possible for `find-function' to find
the definitions. Eat your boilerplate--it forms character.
Admittedly this approach is quite ugly and it might be better to teach
the original commands to support different buffers directly instead of
requiring wrapper commands to do just that.
Never-the-less as a short-term solution this is better than what we
had before.
Inline a simplified version of `notmuch-documentation-first-line'
into its only caller. The new code snippet differs from the
removed function in that it returns nil instead of the empty string
for symbols that have no function documentation. That value is
ultimately used as an argument to `concat', which treats nil like
the empty string. So we can do the logical thing without changing
the behavior.
Since [1: f8bdba37] no key is bound to this command and it is
redundant because the behavior of `push-command' is identical
when called as a command.
1: f8bdba37d3
emacs: tree: remove binding for pressing button in message pane
We could just have switched to using `cl-remove-if-not' instead,
but the two uses of the *remove-if-not function are pretty strange
to begin with so we refactor to not use any such function at all.
The first sentence should fit on the first line. It is okay if
the first sentence/line does not contain all the information that
the rest of the doc-string covers.
Previously it was defined in "notmuch-hello.el" and its name contained
"hello" solely because it replaced an anonymous function that was
mistakenly only bound in `notmuch-hello-mode-map'. But it makes more
sense to bind it in all notmuch modes and even if we did not change
that aspect it still would make no sense to have "hello" in its name.
Notmuch requires at least version 25 of Emacs now.
Adjust comments that previously referenced version 24 specifically,
even though they also apply to later releases. Remove documentation
and code that no longer applies.
- `mm-shr' no longer references `gnus-inhibit-images'.
This fixes a regression introduced in [1: 7e20d264]. If the argument
RETURN-ACTION was non-nil then we should pass along the value of that
argument. Instead we passed along the constant symbol `return-action'.
1: 7e20d26480
emacs: Fix mail composition under Emacs 23
Key bindings should not be defined at the top-level but inside
a `defvar' form. Doing it at the top-level makes it harder to
reliably customize key bindings.
Building Notmuch on macOS is known to cause problems because the Notmuch
distribution archive contains two files named "version". These names
clash with the <version> header as defined in C++20. Therefore, the
existing naming will likely become a problem on other platforms as well,
once compilers adopt the new standard.
Signed-off-by: Ralph Seichter <github@seichter.de>
Amended-by: db s/keyword/header/ in commit message.
As diagnosed by Olivier Taïbi in
id:20201027100916.emry3k2wujod4xnl@galois.lan, if an exception is
thrown while the initialization is happening (e.g. if the function is
called on a closed database), then the destructor is (sometimes)
invoked on an uninitialized Xapian object.
Solve the problem by moving the setting of the destructor until after
the placement new successfully completes. It is conceivable this might
cause a memory leak, but that seems preferable to crashing, and in any
case, there seems to be nothing better to be done if the
initialization is failing things are in an undefined state by
definition.
