Duplicate bug reported in id:87wmtvcor5.fsf@alyssa.is
The error message is nonsense, because notmuch config list actually
includes the database in those two cases.
Currently the --to/--cc/--bcc options add "user@example.com, " to the
message headers, with the the unnecessary ", " separator after the
last address, regardless of how many addresses are being added.
This used to be fine, but with recent emacs mm, trying to send the
email with the trailing commas leads to prompt:
Email address looks invalid; send anyway? (y or n)
Fix this by only adding the commas between addresses, avoiding the
trailing commas.
qsort(3) does not promise stability, and recent versions of glibc have
been showing more unstable behaviour [2]. Michael Gruber observed [1] test
breakage due to changing output order for message properties.
We provide a sorting order of (key,value) pairs that _looks_ stable by
breaking ties based on value if keys are equal. Internally there may
be some instability in the case of duplicate (key,value) pairs, but it
should not be observable via the iterator API.
[1]: id:CAA19uiSHjVFmwH0pMC7WwDYCOSzu3yqNbuYhu3ZMeNNRh313eA@mail.gmail.com
[2]: id:87msv3i44u.fsf@oldenburg.str.redhat.com
According to emacs upstream [1], we can't expect overlay invisibility
and images to get along. This commit uses the previously stashed
undisplayer functions to actually remove the images from the buffer.
When the image is toggled, it is essentially redisplayed from scratch,
using the previously stashed redisplay data.
[1]: https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00593.html
This data will be used to redisplay an image that is hidden by
deleting it from the buffer. We cannot easily delay until the image
is hidden, as we won't have the original data at that point.
For some kinds of MIME parts (at least images), our trickery with
overlays will not work, so save the more drastic function created by
Gnus that actually deletes the part from the buffer. In an ideal world
we would return this function as (part of) a value, but here the call
stack is too complicated for anything that simple, so we stash it in
the part plist and rely on that being preserved (unlike the mm handle,
which is transient).
The function _notmuch_config_load_from_file is only called in two
places in open.cc. Update internal API to match the idiom in open.cc.
Adding a newline is needed for consistency with other status strings.
Based in part on a patch [1] from Eric Blake.
[1]: id:20230906153402.101471-1-eblake@redhat.com
This is a bit fragile w.r.t. glib changing their error message, but it
already helped me find one formatting bug, so for now I think it's
worth it, instead of just grepping for "UTF-8".
For now print a generic error message and exit with error on any
non-success code. Previously the code exited, but with exit code zero,
leading users / scripts to think the command had succeeded.
The python setuputils clean relys on including _notmuch_config.py,
which is cleaned up. Rather than relying on careful ordering, just do
all the cleaning from the GNU Make based build system.
_notmuch_config.py is generated by configure, and cannot be cleaned up
by the current python build system, since it is imported as a module
by that same build system.
Use DISTCLEAN rather than CLEAN for consistency with other configure
related things.
Depending on compiler (gcc, g++, clang) and standard options (c99, c11),
string.h may or may not include strings.h, leading to possibly missing
or conflicting declarations of strcasestr.
Include both so that both detection and compilation phases use the same
(possibly optimised) implementations.
Suggested-by: Thomas Schneider <qsx@chaotikum.eu>
Suggested-by: Florian Weimer <fweimer@redhat.com>
Suggested-by: Tomi Ollila <tomi.ollila@iki.fi>
Native compilation is kindof useless in the test suite because we
throw away the cache after every subtest. The test suite could in
principle share an eln cache within a given test file; for now try to
minimize the amount of native-compilation. There is an intermittent
bug where emacs loses track of its default-directory; I suspect (but
have no proof) that bug is related to native compilation and/or race
conditions. This patch seems to prevent that bug (or at least reduce
its frequency).
According to discussion on
https://gitlab.gnome.org/GNOME/glib/-/issues/3078
it looks like upstream will stop supporting top of file comments.
It is questionable whether we really need this feature, but for now
update notmuch-config to simulate it.
