🐝 I really like where this mua is(was?) headed, but it seems as though there has not been much activity recently.
 
 
 
 
 
Go to file
Manos Pitsidianakis 17a0f31b3e
ui/accounts: split StartupCheck event semantics
UIEvent::StartupCheck was meant to notify the UI that a folder had made
progress and polling its async worker would return a
Result<Vec<Envelope>>. However the StartupCheck was received by
MailListing components which called account.status() which did the
polling. That means that if the polling got back results, the listing
would have to call account.status() again to show them. This is a
problem in configurations with only one account because there aren't any
other sources of event to force the listing to recheck account.status()

A new event UIEvent::WorkerProgress will do the job of notifying an
Account to poll its workers and the account will send a startupcheck if
it has made progress. That way the refresh progress is as follows:

Worker thread sends WorkerProgress event -> State calls appropriate
account's account.status() method -> account polls workers, and if there
are new results send StartupCheck events -> State passes StartupCheck
events to components -> Listings update themselves when they receive the
event
2019-12-14 19:56:43 +02:00
benches melib: remove BackendOpGenerator 2019-07-18 20:14:14 +03:00
debug_printer Fix warnings, lints, and 2018 errors 2019-06-18 21:14:14 +03:00
melib melib/MailBackend: add refresh() method 2019-12-14 18:58:59 +02:00
scripts scripts: remove auto-rustfmt from pre-commit hook 2019-06-10 19:40:33 +03:00
src ui/accounts: split StartupCheck event semantics 2019-12-14 19:56:43 +02:00
testing testing/imap_conn: update imapconn shell use 2019-12-11 00:07:47 +02:00
tests Add tests/ dir and a test 2019-11-17 13:29:12 +02:00
text_processing text_processing: use grapheme length in Truncate 2019-12-12 11:01:13 +02:00
ui ui/accounts: split StartupCheck event semantics 2019-12-14 19:56:43 +02:00
.gdbinit small fixes 2019-11-21 15:44:18 +02:00
.gitignore Revert "Show manuals with command line arguments" 2019-10-24 12:19:29 +03:00
COPYING mailbox: add threads 2019-06-10 19:11:47 +03:00
Cargo.lock JMAP WIP 2019-12-13 00:04:58 +02:00
Cargo.toml Add optional 'jmap' feature in binary Cargo.toml. 2019-12-13 00:39:56 +02:00
Makefile Fix typos in Makefile 2019-12-09 18:33:46 +02:00
README Add optional 'jmap' feature in binary Cargo.toml. 2019-12-13 00:39:56 +02:00
meli.1 Update manpages for JMAP 2019-12-13 00:13:54 +02:00
meli.conf.5 Update manpages for JMAP 2019-12-13 00:13:54 +02:00
rustfmt.toml Run rustfmt 2019-06-10 19:40:39 +03:00
sample-config Small fixes 2019-11-29 12:15:05 +02:00

README

    __
 __/  \__
/  \__/  \__                       .
\__/  \__/  \    , _ , _     ___   │   '
/  \__   \__/    │' `│  `┒ .'   `  │   │
\__/  \__/  \    │   │   │ |────'  │   │
   \__/  \__/    │       / `.___, /\__ /
      \__/
                                    ,-.
                                    \_/
        terminal mail user agent   {|||)<
                                    / \
                                    `-'
DOCUMENTATION
=============

After installing meli, see meli(1) and meli.conf(5) for documentation.

BUILDING
========

meli requires rust 1.39 and rust's package manager, Cargo. Information on how
to get it on your system can be found here:

https://doc.rust-lang.org/cargo/getting-started/installation.html

With Cargo available, the project can be built with

# make

The resulting binary will then be found under target/release/meli

Run:

# make install

to install the binary and man pages. This requires root, so I suggest you override the default paths and install it in your $HOME:

# make PREFIX=$HOME/.local install

See meli(1) and meli.conf(5) for documentation.

You can build and run meli with one command:

# cargo run --release

While the project is in early development, meli will only be developed for the
linux kernel and respected linux distributions. Support for more UNIX-like OSes
is on the roadmap.

BUILDING IN DEBIAN
==================

Building with Debian's packaged cargo might require the installation of these
two packages: librust-openssl-sys-dev and librust-libdbus-sys-dev

BUILDING WITH NOTMUCH
=====================

To use the optional notmuch backend feature, you must have libnotmuch installed in your system. In Debian-like systems, install the "libnotmuch" package.

To build with notmuch support, prepend the environment variable "MELI_FEATURES='notmuch'" to your make invocation:

# MELI_FEATURES="notmuch" make

or if building directly with cargo, use the flag '--features="notmuch"'.

BUILDING WITH JMAP
=====================

To build with JMAP support, prepend the environment variable "MELI_FEATURES='jmap'" to your make invocation:

# MELI_FEATURES="jmap" make

or if building directly with cargo, use the flag '--features="jmap"'.

DEVELOPMENT
===========

Development builds can be built and/or run with

# cargo build
# cargo run

There is a debug/tracing log feature that can be enabled by using the flag
`--feature debug-tracing` after uncommenting the features in `Cargo.toml`. The logs
are printed in stderr, thus you can run meli with a redirection (i.e `2> log`)

Code style follows the default rustfmt profile.

CONFIG
======

meli by default looks for a configuration file in this location:
# $XDG_CONFIG_HOME/meli/config

You can run meli with arbitrary configuration files by setting the MELI_CONFIG
environment variable to their locations, ie:

# MELI_CONFIG=./test_config cargo run

TESTING
=======

How to run specific tests:

# cargo test -p {melib, ui, meli} (-- --nocapture) (--test test_name)

PROFILING
=========

# perf record -g target/debug/bin
# perf script | stackcollapse-perf | rust-unmangle | flamegraph > perf.svg