mirror of https://github.com/djcb/mu.git
docs: update man-page, NEWS.org
This commit is contained in:
parent
d3e15050c2
commit
0ed03b94ca
45
NEWS.org
45
NEWS.org
|
@ -1,19 +1,37 @@
|
||||||
#+STARTUP:showall
|
#+STARTUP:showall
|
||||||
* NEWS (user visible changes)
|
* NEWS (user visible changes)
|
||||||
|
|
||||||
* 1.4 (unreleased)
|
* 1.3.x (unreleased, experimental/development version)
|
||||||
|
|
||||||
*** mu
|
*** mu
|
||||||
|
|
||||||
- The contacts cache (as uses in ~mu cfind~ and mu4e contact-completion is now
|
- The contacts cache (as uses in ~mu cfind~ and mu4e contact-completion) is
|
||||||
stored as part of the Xapian database rather than as a separate file.
|
now stored as part of the Xapian database rather than as a separate file.
|
||||||
|
|
||||||
|
- mu now defaults to the [[https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html][XDG Base Directory Specification]] for the default
|
||||||
|
locations for various files. E.g. on Unix the mu database now lives under
|
||||||
|
~~/.cache/mu/~ rather than ~~/.mu~. You can still use the old location by
|
||||||
|
passing --muhome=~/.mu to various mu commands, or setting ~(setq
|
||||||
|
mu4e-mu-home "~/.mu")~ for mu. Otherwise, after upgrading, you may wish to
|
||||||
|
delete the old location.
|
||||||
|
|
||||||
|
- The ~--xbatchsize~ and ~--autoupgrade~ options for indexing are gone now; both
|
||||||
|
are determined implicitly now.
|
||||||
|
|
||||||
|
- The ~--maildir~ parameter is only used when initializing the database, and
|
||||||
|
it is stored in that database. Afterwards that its value is used; which
|
||||||
|
means you cannot change the parameter without rebuilding and this is by
|
||||||
|
design.
|
||||||
|
|
||||||
|
- The ~--my-address~ parameter is persistent as well, but can be overwritten;
|
||||||
|
note that an updated value only applies to the messages indexed /after/ the
|
||||||
|
change.
|
||||||
|
|
||||||
*** mu4e
|
*** mu4e
|
||||||
|
|
||||||
- In many cases, ~mu4e~ used to get /all/ contacts after each indexing
|
- In many cases, ~mu4e~ used to receive /all/ contacts after each indexing
|
||||||
operation; this was slow for some users, so we have updated this to only
|
operation; this was slow for some users, so we have updated this to /only/
|
||||||
get the contacts that have changed since the last time ~mu4e~ received that
|
get the contacts that have changed since the last round.
|
||||||
information.
|
|
||||||
|
|
||||||
We also moved sorting the contacts to the mu-side, which speeds things up
|
We also moved sorting the contacts to the mu-side, which speeds things up
|
||||||
further. However, as a side-effect of this, ~mu4e-contacts-rewrite-function~
|
further. However, as a side-effect of this, ~mu4e-contacts-rewrite-function~
|
||||||
|
@ -21,6 +39,19 @@
|
||||||
of those should migrate to ~mu4e-contact-process-function~; see its
|
of those should migrate to ~mu4e-contact-process-function~; see its
|
||||||
docstring for details.
|
docstring for details.
|
||||||
|
|
||||||
|
- Christophe Troestler contributed support for Gnus' calender-invitation
|
||||||
|
handling in mu4e (i.e., you should be able to accept/reject invitations
|
||||||
|
etc.). It's very fresh code, and likely it'll be tweaked in the future.
|
||||||
|
But it's available now for testing. Note that this requires the gnus-based
|
||||||
|
viewer, ie ~(setq mu4e-view-use-gnus t)~
|
||||||
|
|
||||||
|
- Pierre Neidhardt contributed an "Account Setup Helper" which wraps the
|
||||||
|
existing context setup with some niceties for accounts. See the manual for
|
||||||
|
details.
|
||||||
|
|
||||||
|
- When the mu store (database) is not present or not up to date, mu4e will
|
||||||
|
attempt to re-index it automatically.
|
||||||
|
|
||||||
** 1.2
|
** 1.2
|
||||||
|
|
||||||
After a bit over a year since version 1.0, here is version 1.2. This is
|
After a bit over a year since version 1.0, here is version 1.2. This is
|
||||||
|
|
|
@ -100,21 +100,6 @@ indexing only a part of messages (using \fB\-\-maildir\fR). For this reason,
|
||||||
it is necessary to run \fBmu index \-\-rebuild\fR when there is an upgrade in
|
it is necessary to run \fBmu index \-\-rebuild\fR when there is an upgrade in
|
||||||
the database format. \fBmu index\fR will issue a warning about this.
|
the database format. \fBmu index\fR will issue a warning about this.
|
||||||
|
|
||||||
.TP
|
|
||||||
\fB\-\-autoupgrade\fR
|
|
||||||
automatically use \fB\-y\fR, \fB\-\-empty\fR
|
|
||||||
when \fBmu\fR notices that the database version is not up-to-date. This option
|
|
||||||
is for use in cron scripts and the like, so they won't require any user
|
|
||||||
interaction, even when mu introduces a new database version.
|
|
||||||
|
|
||||||
.TP
|
|
||||||
\fB\-\-xbatchsize\fR=\fI<batch size>\fR
|
|
||||||
set the maximum number of messages to process in a single Xapian
|
|
||||||
transaction. In practice, this option is only useful if you find that \fBmu\fR
|
|
||||||
is running out of memory while indexing; in that case, you can set the batch
|
|
||||||
size to (for example) 1000, which will reduce memory consumption, but also
|
|
||||||
substantially reduce the indexing performance.
|
|
||||||
|
|
||||||
.TP
|
.TP
|
||||||
\fB\-\-max-msg-size\fR=\fI<max msg size>\fR
|
\fB\-\-max-msg-size\fR=\fI<max msg size>\fR
|
||||||
set the maximum size (in bytes) for messages. The default maximum
|
set the maximum size (in bytes) for messages. The default maximum
|
||||||
|
|
Loading…
Reference in New Issue