| Commit message (Collapse) | Author | Age |
|
|
|
| |
It is only ever called from here, separating them makes little sense.
|
| |
|
|
|
|
|
|
|
|
|
| |
This optimization is wrong, since oldest_first is not a reverse of
newest_first.
oldest_first sorts the threads by the oldest message in each thread,
while newest_first sorts by the newest message in each thread.
That results in 'focus last' changing the thread order, which it should
not do.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of allowing the callers to access the email part directly,
introduce a new class for representing the MIME tree structure. All
interaction with the message content should now happen through this
class (some instances of direct access still remain and will be removed
later).
Encrypted/signed parts are now also handled through this structure
rather than using a fragile hack of attaching the decrypted message to
the encrypted one and using fake headers to signal
encryption/signatures.
Message body rendering is now done by walking through the whole MIME
tree and considering all the parts for rendering rather than picking one
specific part.
|
|
|
|
| |
It is not useful and too complex/fragile to maintain.
|
| |
|
| |
|
|
|
|
|
|
| |
This also prevents it from modifying the message as it previously did
with add_tags. As a consequence, tags are now added to the beginning of
the message rather than at the end of header.
|
|
|
|
| |
Also, stop accessing the email directly.
|
|
|
|
| |
Avoid accessing the email directly.
|
|
|
|
| |
Drop some tests for removed functions.
|
| |
|
| |
|
|
|
|
|
|
|
| |
It has no relation to database, so helper seems like a better place for
it.
As there is nothing left in db/utils, it is removed.
|
| |
|
|
|
|
|
| |
They are only used in a single file, so there is no point in keeping
them elsewhere.
|
|
|
|
|
| |
It is only called from there, so there is no reason to keep it
elsewhere.
|
|
|
|
|
| |
It is only called from there, so there is no reason to keep it
elsewhere.
|
|
|
|
|
| |
It is used in only one place and does something so extremely simple it
does not need to be a special imported function.
|
|
|
|
|
|
|
|
| |
It is almost entirely unnecessary - python's email messages decode the
headers themselves. Do the "normalization" bit directly in the single
place where it is done, though properly there should be more thorough
message text sanitization somewhere (most likely in our message
wrapper).
|
| |
|
|
|
|
|
| |
This simplifies the following refactorings. It will be made asynchronous
later.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The top part displayes the thread structure, the bottom half the message
body. This makes more sense then displaying the message inside the tree
structure and makes it easier to implement features such as folding a
part of the message body.
Drop commands related to folding, since that functionality does not
exist anymore.
|
|
|
|
| |
It is already decoded.
|
| |
|
| |
|
|
|
|
| |
This is more correct.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
They were temporarily removed in the previous commit.
Still not working:
- theming for the decorations
- drawing the connector line properly for expanded messages
- configurable indentation
|
|
|
|
|
|
|
|
|
|
| |
Their API is misdesigned - forces the use of trees for nontree objects
and mixes data relationships with display properties. The result is a
mess that is hard to understand/maintain/extend.
Replace the use of urwidtrees with urwid Pile and ListBox. This
temporarily removes tree-style indentation and decorations for thread
buffers. That will be reimplemented in following commits.
|
|
|
|
|
| |
It should be cleaner and easier to use, and eventually replace the
custom tree walker in the thread display buffer.
|
| |
|
| |
|
|
|
|
| |
It should always be instantiated from a Thread instance.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This functionality is too obscure and dangerous, it should be done
manually instead.
|
|
|
|
| |
It's pointless complexity that I do not need.
|
|
|
|
|
| |
It makes no sense to order messages. Only testing for equality is
meaningful.
|
| |
|
|
|
|
| |
It is an utterly useless number.
|
|
|
|
|
| |
There is no meaningful reason to focus on individual lines, since they
are unactionable.
|
| |
|