reimplement the old mu-log.[ch] into mu-logging.{cc,hh}
If available (and using an appropriately equipped glib), log to the
systemd journal
Only g_criticals have stderr output, all the other g_* go to the log
file / journal.
We were trying to start mu4e asynchronously, then compose the mail but
this doesn't quite work the way some external packages expected, and
this would fail.
Fixes#1710Fixes#1698
For the new symlink-support, it's better to use the *canonical* path than
the *realpath(3)* for files, so removing a symlinked maildir will work as
expected.
For bookmarks, which specify the key combo instead of using the first
character of the string had an off-by-one error in the mouse
highlighting since it wasn't consuming that first letter.
Until now, mu would _not_ follow symlinks; with these changes, we do.
There were some complications with that ~10 years ago, but I forgot the
details. So let's re-enable. At least one thing is in place now: moving
between file systems.
Fixes#1489Fixes#1628 (technically, this came with slightly earlier commit)
When calling mu_maildir_move_message with the new_name
options (workaround for mbsync's), do the src=target check *without* first
creating that new name.
This avoids some unnecessary moves.
Isync uses this by default on Windows where ':' is an invalid character
in file names. Also try to preserve the existing separator character
when generating a new file name.
The text:
Optionally, you can add the following:
`:hide' - if t, maildir is hdden from the main-view and speedbar.
`:hide-unread' - do not show the counts of unread/total number
of messages for the maildir in the main-view.
is not true for the current version, so let's remove it.
*
The code still has some problems, and the original author has moved
elsewhere (which is fine of course), but it's not ready enough for
1.4.... yet. So let's remove it for now and check again with 1.5+.
Some completion engines (like "flx") decorate the strings that they
return. If MU4E passes such a string down to MU, the "format" call
preserves the text properties in the generated S-expression, producing
an invalid query. MU4E itself has no interest in those decorations,
so strip them out as early as possible from all prompts that use
mu4e-completing-read-function.
