| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Not in master because it doesn't seem to be the bottleneck, didn't check
whether the difference is measurable.
|
|
|
|
|
|
|
| |
Add only tags that are not present on the message, remove only tags
that are present.
Otherwise the no-op modification results in an actual db write, even
though nothing changes.
|
|
|
|
| |
Allows to apply multiple operations together as a single unit.
|
|
|
|
|
| |
There is no point in having more, as the database cannot have more than
one writer at any moment.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Allows computing message/thread counts asynchronously in a separate
thread.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As far as I can tell using a separate process doesn't actually improve
performance, it makes it worse. The work that we're passing off to the
separate function isn't necessarily work that's well suited to being
handed off, there isn't a lot of computation and the objects that need
to be passed across the pipe are fairly large (at least when considering
a pipe). Converting the function to a generator gives better performance
and simplifies the implementation.
|
|
|
|
|
|
|
|
| |
Those are tags like attachment, signed, sent, etc., which are set
automatically based on message properties and are typically not changed
manually.
Such designated tags are not affected by the retag operation.
|
| |
|
|
|
|
|
| |
They are supposed to replace the original notmuch python bindings,
providing a safer and more pythonic interface.
|
|
|
|
| |
Remove the unused afterwards callback, make tags mandatory.
|
|
|
|
|
| |
This is not implemented in notmuch2 and does not really belong in alot.
It can be done better through the notmuch utility.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This functionality is too obscure and dangerous, it should be done
manually instead.
|
|
|
|
| |
This reverts commit e7e0c52db9093a9ecd9dcaa0766e66515a546a75.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As far as I can tell using a separate process doesn't actually improve
performance, it makes it worse. The work that we're passing off to the
separate function isn't necessarily work that's well suited to being
handed off, there isn't a lot of computation and the objects that need
to be passed across the pipe are fairly large (at least when considering
a pipe). Converting the function to a generator gives better performance
and simplifies the implementation.
|
| |
|
|
|
|
|
|
| |
Python3 only supports "new-style" classes (those extending object),
and we don't need to explicitly inherit from this root class any more.
See http://pylint-messages.wikidot.com/messages:c1001
|
|
|
|
|
|
|
| |
"async" is a reserved keyword in Python 3.7, so cannot be used for
method names.
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
|
|
|
|
|
| |
This is the obvious thing to do, and it works, but it does introduce
some latency into starting alot.
|
|
|
|
| |
these can be used to define/remove new named query strings
|
| |
|
|
|
|
| |
They are not needed for python >= 3.0.
|
| |
|
| |
|
|
|
|
| |
This probably isn't completely right, but it's a start.
|
|
|
|
|
|
|
|
|
| |
this adds exclude tags to every query object. Just as in notmuch (option
search.exclude_tags), this will essentially render messages invisible if
tagged with one of those tags, unless they explicitly appear in the
query. See also man notmuch-config(1).
closes #732
|
|\ |
|
| |
| |
| |
| |
| | |
This mostly shortens lines down to <=79 chars and fixes some other small
things I found using the pep8 tool.
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
This can create circular imports in unittests, which causes difficult to
debug errors.
Fixes #1076
|
|
|
|
|
|
| |
Fixes #707 and #332.
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch replaces a large number (but not all) unused arguments with
the standard ``_`` placeholder. This has the advantage of signaling that
these values are unused.
There are a number of places that I've chosen not to apply this, largely
in methods that have publicly define signatures that they inherit
(usually from urwid).
|
|
|
|
|
|
|
|
|
|
|
| |
It's pretty easy to get caught up using dict.keys (or iterkeys) when
one doesn't need to. This patch corrects two cases where it's not
needed, the first is the case of inclusion. ``x in mydict.keys()`` is
equivalent to ``x in mydict``, but without the need to generate a list
and walk it. The second case is when calling set() on a dict,
``set(mydict)`` will create a set object of the dict's keys, without the
need to create one in memory and is significantly faster than
``set(mydict.keys())`` or even ``set(mydict.iterkeys())``.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are a number of cases of mutable keyword arguments (list and dict
in this case). Mutable keyword arguments are rather dangerous, since any
mutation of the default value is persistent, which will inevitably lead
to bugs.
For example, imagine this code:
def func(def=[]):
def.append('foo')
return def
>>> func()
['foo']
>>> func()
['foo', 'foo']
This is almost certainly not what was intended. This code generally uses
the idiom of setting the default value to None, and then assigning with
or `value = value or []` which will replace value with the empty list
(or dict) when value is falsey, like None or another empty list.
|
|
|
|
|
|
| |
- use relative imports if possible
- group imports into standard library, third party, and alot modules
- sort imports alphabetically
|
| |
|
|
|
|
| |
see also issue #794
|
| |
|