| Age | Commit message (Collapse) | Author |
|---|
|
Regexes compiled with regcomp() need to be freed with regfree(). Do that
in a talloc destructor attached to the compiled regex array.
Amended by db: Use C style comment. Add blank line per uncrustify.
|
|
Raise it as a newly added OperationInvalidatedError exception.
|
|
This will be useful for handling NOTMUCH_STATUS_OPERATION_INVALIDATED
errors that will be exposed through the bindings in a following commit.
|
|
The overall goal is to allow clients to restart operations in
situations where that is the response recommended by the underlying
Xapian library.
Amended-by: db, added above explanation
|
|
Silences compiler warnings about redefining a macro.
|
|
While a number of errors can happen when iterating over threads
(DatabaseModifiedError, memory allocation errors, etc.), the API
currently cannot signal them to the caller, and either triggers an
internal error (aborting the caller) or returns NULL from
notmuch_threads_get() with no information on what actually went wrong.
Add a new public function notmuch_threads_status() - similar to
previously added notmuch_messages_status() - that allows propagating
those errors to the caller.
Use this to remove the INTERNAL_ERROR() in _notmuch_thread_create()
(triggered by T642).
Fixes: https://github.com/pazz/alot/issues/1460
Amended-By: db. Resolved whitespace disagreement between emacs and
uncrustify in favour of uncrustify.
|
|
This is similar to previously added T641, except here we iterate over
threads rather than messages.
After f375ea1add121c428f261473512831a169dfe335, the
DatabaseModifiedError raised by Xapian is now handled in
_notmuch_message_create(), resulting in a NULL message being returned to
_notmuch_thread_create(), which currently triggers an internal error.
|
|
The list destructor is always set when necessary (i.e. if the iterator
is successfully created), so there is never a need to invoke it
explicitly, even on failure.
|
|
If an open database is modified sufficiently by other callers, the open
instance becomes invalid and operations on it throw
DatabaseModifiedError. Per Xapian documentation, the caller is then
supposed to reopen the database and restart the query. This exception is
currently not handled in _notmuch_message_create(), leading to the
default handler abort()ing the process.
Catch this exception in _notmuch_message_create() and return an error
instead of crashing. Since the entire query becomes invalid - including
results that have already been read by the caller - this situation
cannot be handled by libnotmuch transparently. A new public function -
notmuch_messages_status() - is added to allow the callers to check
whether the messages iterator was exhausted or terminated early due to
a runtime error. This also allows memory allocation failure to be
signalled to the caller.
Amended-By: David Bremner <david@tethera.net>
[replace use of notmuch_messages_valid]
|
|
This one is raised from _notmuch_message_create().
See also https://github.com/pazz/alot/issues/1460#issuecomment-2994101019
|
|
This docstring has been like this a long time, but recently I noticed
sphinx-doc complaining about :man:. This :any: link seems to work, and
is consistent with the other links to the notmuch-config man page.
|
|
|
|
In particular this gives a place for documenting how to resume editing
drafts.
|
|
The mention of notmuch-tree-button-activate seems to have been an
error / obsolete.
|
|
The amount of space saved here is minimal, but I want to migrate to a
more topic focused manual, as opposed to long alphabetical lists of
commands.
|
|
This is mostly just copying docstrings, but putting them into sections
makes them more discoverable.
|
|
d526797a ("python: move legacy python bindings to contrib.", 2025-02-15)
moved the legacy python bindings away from the location in `bindingss/`.
Do not add that location to the PYTHONPATH since it is obsolete.
|
|
This makes derived-mode matching in display-buffer-alist work.
|
|
|
|
Database docstrings refer to IndexOptions,
so the latter should be public too.
|
|
|
|
The defcustom had a typo that prevented it from working as intended.
|
|
|
|
Based on a suggestion from Jakub Wilk.
|
|
|
|
Those changes are now directly in git.
|
|
merge bugfix uploads from other branch
|
|
|
|
|
|
Identical to 0.39~rc3, except for release related
documentation (e.g. NEWS).
|
|
This is based on my reading of git shortlog. Some more development
specific changes have been omitted.
|
|
|
|
|
|
|
|
Instead of trying to guess in which modes this is safe not to set in,
let's just set it in all of them.
Background (added by db):
untrusted-content was added in Emacs 29.3 and is currently set by Gnus
and used by org-mode to prevent certain unsafe operations. I think the
intent is to use it for blocking more unsafe operations in the future.
|
|
|
|
The cffi bindings raise a LookupError in case a header is not present.
Adjust the docstring to say so.
The legacy bindings behaved differently, and this is one of the things
to be aware of when migrating to the cffi bindings.
|
|
Debian developers with the pure GTK+ variant of emacs (which does not
support X11 at all, as it builds entirely against the GTK Wayland
backend) should also be able to treat the build-dependencies as
satisfied.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
This removes the visual gap/stutter between when the screen fills and
when the hl-line "cursor" is drawn. It is not obviously how to
robustly test this, since it the observable effect is purely a matter
of timing.
|
|
There is a a perceptible gap between when the tree shows up and when
the hl-line is visible, but this is better than the previous state
where the line did not show up at all until the user moved the cursor.
|
|
It isn't clear that this call to hl-line-mode will survive the coming
re-organization to stop relying on hooks, but incrementally this at
least makes the disabling behaviour consistent.
|
|
In the thread at id:87fsfuuxwn.fsf@thinkbox, a bug is discussed where
the point and hl-line overlay get out of sync, leading the user to
open the wrong message. As far as I can tell this is caused by
notmuch-hl-mode being invoked too early.
This change bypasses the logic preventing notmuch-search-hook being
called only once, so that the overlay is updated later after the
buffer is full(er).
This change may lead to the overlay being updated multiple times; if
this is annoying we can add a similar buffer local variable to ensure
it is only called once.
The extra logic to check notmuch-search-target-line reduces the
flicker somewhat by not highlighting the first line every time.
|
|
Most of the known broken tests replicate (my intepretation of) the bug
reported at id:87fsfuuxwn.fsf@thinkbox (or some unreported, but
probably related bugs in tree/unthreaded view). The last 3 broken
tests are just unimplimented planned functionality.
|
|
Currently the presence of hl-line highlighting is controlled
implicitely by hooks. In future commits it will be migrated to use
this variable.
|
|
Workaround for slow riscv64 autobuilders.
|
|
|
|
|
|
|
|
|
