| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
provide retagprompt command in thread mode
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
retagprompt in search mode allows to retag a whole thread. The new
thread mode version allows to do the same for each selected message.
The common command infers its mode from the UI object that it is passed
when applied. Therefore, the docstring (and everything else) is
mode-agnostic.
When this command command is registered for the wrong mode and applied
it raises a KeyError (on purpose).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduce a new source file common.py for common commands and, as a
first example, define RetagPromptCommand there and register it from
search.py.
This shows how to "decorate" a class that is defined somewhere else, and
thus how to decorate it multiple times.
|
| |/
|
|
|
| |
.. that accidentally got dropped during c86623d9c7daaa2f9a832135a11870a0d91110a3
This fixes #1255
|
| |
|
|
|
|
|
|
|
| |
This prevents SettingsManager from reading the config files right when
it is isntantiated and instead waits for the main module to call
`read_[notmuch]config` with the right path.
This should prevent problems with accidentally reading the default
config paths despite being told otherwise (via commandline options)
|
| |\
| |
| | |
envelope: Update encryption keys when CC, To, or From is changed
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the encryption keys will only be updated when they are
toggled, which means that if you change a Cc or To then the keys
encrypted to might be wrong, either too many keys will be encrypted to,
or not enough, or just the wrong ones.
This patches fixes this by calling set_encrypt whenever the 'To', 'Cc',
or 'From' headers are changed by set or unset.
Fixes #1227
|
| | |
| |
| |
| | |
see also #1250
|
| | |
| |
| |
| |
| | |
This splits buffers.py, which contained all buffer classes, into several smaller files.
issue #1226
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
imp is deprecated in favor of importlib.
|
| |/ /
| |
| |
| | |
They are not needed for python >= 3.0.
|
| | |
| |
| |
| | |
fixes #1244
|
| | | |
|
| | |
| |
| |
| |
| | |
This might be a little sloppy, but there are legitimate cases where
stdin is bytes, and cases where it is a string.
|
| | |
| |
| |
| | |
because the data is in bytes not strings.
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The typical current message looks like:
unable to load hooks file:/home/teto/.config/alot/hooks.py
without telling why python couldn't load the hook.
This commit prints the exception, thus helping users to solve the issue
(in my case encoding + wrong imports).
|
| | | | |
|
| | | | |
|
| |\| |
| | |
| | |
| | |
| | | |
And attempts to fix handling of non text/plain parts by leaving them as
bytes until they've been passed to the program that will render them.
|
| | |/
| |
| |
| |
| |
| |
| | |
This moves out the plaintext rendering of email parts (that are
not multipart/* and not text/plain) into a separate utility function
render_part. This function looks up and calls the apropriate mailcap
handler.
|
| | |
| |
| |
| | |
oops
|
| |\ \
| | |
| | |
| | |
| | | |
One small conflict caused by "db/utils: correctly handle 8bit encoded
mail"
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The `assert` statement is not always executed (it can be optimised
away) so is not a suitable run-time check. Also, an exception allows
for a better error message.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
I've run into this with misconfigured git-send-email messages, where the
encoding is utf-8, but the declared encoding is true or 8bit.
|
| |/ / |
|
| | |
| |
| |
| |
| | |
For reasons I don't understand python sometimes converts 8bit to a
string properly, and other times it doesn't. This is a bit of a hack.
|
| | |
| |
| |
| |
| |
| | |
Because python's mail will use raw-unicode-escape for anything that
isn't ascii we need to encode back into the original raw bytes, then
decode into the proper encoding.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The builtin for this assumes that inside of a Content-Transfer-Encoding
that the format must be ascii. That is pretty silly, since the reason to
use something like base64 is to transfer something that is not ascii,
like utf-8. This attempts to handle the base64 and quoted-printable
cases manually.
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
magic struggles to decode a number of encodings, particularly it
struggles with windows-1252, which Exchange *loves* to silently
re-encode mail in, without updated the charset of the payload. Chardet
successfully guesses these oddball encodings much more often.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
We don't want to be comparing bytes anyway, the decode would use utf-8,
and that isn't right. Instead make the caller convert to a str of
Address first.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
currently _handle_signatures will pass `False~ for the error_msg if
there is no error, but the documentation for add_signature_headers says
it only accepts strings.
Don't do either of these, instead use None if there is no error,
otherwise a string, and updated the assert and documentation to match.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Attachments are encoded into bytes, but the file we open to write them
into was being opened in text mode. That doesn't work. Open the file in
bytes mode instead.
|
| |\ \ \
| | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
.. from "caller" to "ui", as used throughout all subclasses.
The inconsistent naming causes the codacity code checker (pylint) to
complain every time we add a new command subclass.
|
| | |\ \
| | | |
| | | | |
crypto: Handle message that is encrypted, but the signature is invalid
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
One case of this would be not having the public key of the signer. If
the verification of the signatures fails, then use the signatures from
the error, and try to redecrypt without verification.
I have no tests yet, and this probably deserves tests.
Fixes #1157
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I had made the assumption early on that this would get bytes, but when I
added `assert isinstance(header, bytes)` alot would crash on startup,
changing `bytes` to `str` fixed that. I noticed this when trying to fix
the warning generated in the logging call.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't want to be comparing bytes anyway, the decode would use utf-8,
and that isn't right. Instead make the caller convert to a str of
Address first.
|
