| Age | Commit message (Collapse) | Author |
|---|
|
oops. If only there was some editor facility that allowed replacing
all instances of a string.
|
|
|
|
|
|
|
|
|
|
|
|
Remove incorrect skipping to first match from init(), and add explicit
skip_to() and check() methods to work around xapian-core bug (the
check() method will also improve speed when filtering by one of
these).
|
|
|
|
|
|
The documentation for this was overlooked when adding the subcommand
handling. This seems like the proper place for it.
|
|
|
|
It seems these need to be exported from the library in order for
exception handling to work.
|
|
|
|
|
|
|
|
The test description is used for log output, I think the intention is
to keep it as a one-liner. Leave the rest of the long description as a
comment.
|
|
This backports the fix from emacs master (commit
77bbca8c82f6e553c42abbfafca28f55fc995d00) to notmuch-emacs to wrap
long headers.
This fixes the test introduced in the previous changeset.
|
|
Headers of more than 998 characters should be folded when sending.
However, until recently, emacs did not do this.
This adds a (known broken) test for this when sending messages in
emacs. We will backport the fix to notmuch-emacs in the next
changeset.
|
|
We filter added exclude at add time, rather than modifying the query by
count search. As noted in the comments, there are several ignored
conditions here.
|
|
The main goal is to prepare the way for non-destructive (or at least
less destructive) exclude tag handling. It does this by having a
pre-parsed query available for further processing. This also allows us
to provide slightly more precise error messages.
|
|
Fix warning caught by clang:
lib/regexp-fields.cc:41:2: warning: 'delete' applied to a pointer that was allocated
with 'new[]'; did you mean 'delete[]'? [-Wmismatched-new-delete]
delete buffer;
^
[]
lib/regexp-fields.cc:37:17: note: allocated with 'new[]' here
char *buffer = new char[len];
^
|
|
mid: is the url scheme suggested by URL 2392. We also plan to
introduce more flexible searches for mid: than are possible with
id: (in order not to break assumptions about the special behaviour of
id:, e.g. identifying at most one message).
|
|
the idea is that you can run
% notmuch search subject:/<your-favourite-regexp>/
% notmuch search from:/<your-favourite-regexp>/
or
% notmuch search subject:"your usual phrase search"
% notmuch search from:"usual phrase search"
This feature is only available with recent Xapian, specifically
support for field processors is needed.
It should work with bindings, since it extends the query parser.
This is easy to extend for other value slots, but currently the only
value slots are date, message_id, from, subject, and last_mod. Date is
already searchable; message_id is left for a followup commit.
This was originally written by Austin Clements, and ported to Xapian
field processors (from Austin's custom query parser) by yours truly.
|
|
This is a bit more code than hardcoding the two existing field
processors, but it should make it easy to add more.
|
|
|
|
With the mailto: handling in notmuch-emacs-mua, we can update the
desktop file to advertize we can be set as the default application to
handle email. While at it, add GenericName and Comment to be more
informative.
With --hello, notmuch-emacs-mua will run (notmuch) if mailto: url is
not given.
|
|
With subcommand handling for external commands we can easily complete
'notmuch emacs-mua' using the existing completion system.
|
|
Second gnugpg test suite fix
|
|
|
|
|
|
|
|
When opening configuration file fails, ENOENT (file not found) is
handled specially -- in setup missing file is ok (often expected),
and otherwise user can be informed to run notmuch setup.
In any other case the the reason is unknown, so there is no other
option but to print generic error message to stderr.
|
|
The help command does not really need to try to open the config
file. So don't.
|
|
notmuch 0.23.6 release
|
|
Help the clients decide how to display parts.
Test updates by Mark Walters <markwalters1009@gmail.com>.
One more test fix by db
|
|
Reduce duplication in follow-up work. As a side effect, handle error
returns from g_mime_content_disposition_get_disposition() without
segfaulting.
|
|
We already use this directory for dtach sockets, so it makes sense to
put gnupg sockets there as well. There doesn't seem to be a clean way
to put a fully functional socket in a different location than
GNUPGHOME.
|
|
This reverts commit 12f7d4e61d30fb9a5c99e128ab1aab0bf069cdb4.
Since we're not using gpgconf anymore, drop the unneeded test in
configure.
|
|
This reverts commit e7b88e8b0a93ca83d807edc00e0c97af54c5b5f1.
It turns out that this does not work well in environments without a
running systemd (or some other provider of /run/user)
|
|
|
|
|
|
Apparently our test system does not use the same flags for compiling
tests as it does for compiling notmuch. Make the test compatible with
C89. Also remove one unused loop index.
|
|
Add prefix completion for query and property, with value completion
for query. Apparently there's no way to get at the available
properties in the cli.
|
|
Gnus seems to display application/zip and application/tar by
default. This doesn't seem desirable so we override it.
We only override if the user has not customized
mm-inline-override-types themselves.
|
|
Schemata v3 changed message filename field to a list. Test both
versions 2 and 3.
|
|
Instead of just having the first filename for the message, list all
duplicate filenames of the message as a list in the formatted
outputs. This bumps the format version to 3.
|
|
Fix the deprecation warning:
In notmuch-maildir-fcc-make-uniq-maildir-id:
emacs/notmuch-maildir-fcc.el:279:53:Warning: ‘system-name’ is an obsolete
variable (as of 25.1); use (system-name) instead
I've used (system-name) since at least 2011, so it must have been
around quite a while.
|
|
Currently the view number is incremented by notmuch_database_reopen
|
|
The retries are hardcoded to a small number, and error handling aborts
than propagating errors from notmuch_database_reopen. These are both
somewhat justified by the assumption that most things that can go
wrong in Xapian::Database::reopen are rare and fatal. Here's the brief
discussion with Xapian upstream:
24-02-2017 08:12:57 < bremner> any intuition about how likely
Xapian::Database::reopen is to fail? I'm catching a
DatabaseModifiedError somewhere where handling any further errors is
tricky, and wondering about treating a failed reopen as as "the
impossible happened, stopping"
24-02-2017 16:22:34 < olly> bremner: there should not be much scope for
failure - stuff like out of memory or disk errors, which are probably a
good enough excuse to stop
|
|
The main expected use is to recover from a Xapian::DatabaseChanged
exception.
|
