Usurp more of the utils code than can be re-used without further dependencies in
helpers.
Split off specific parts in their own file.
After the helper/utils changes, update the rest of mu4e to take the changes into
account.
Make mu4e-view-use-gnus obsolete (it's the default now), and add a
variable mu4e-view-use-old (which must be set before starting mu4e).
Update documentation / mentions.
Load the correct view when starting mu4e, so people can customize
e.g. the keymap.
Add some sanity checking.
re-enable the gnus/old split (the key was re-implementing
mu4e-view-message-text for gnus)
split helpers into mu4e-view-common
as a bonus 'go to url' now also works with gnus
mu4e-contact-rewrite-function was obsoleted in 1.4, but the entry in
NEWS.org entry, and the make-obsolete-variable call, referred to it as
mu4e-contacts-rewrite-function. (Should be "contact", not "contacts".)
Instead of a multi-step process to display an unread message (ie. get
the original, notice it's unread, then update it, replace the message
with update one etc.), we now handle that in the (view /./..) command on
the server side.
Simplifies things, and is faster (which could be noticeable, esp. if
e.g. signature verification is part of the process)
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.
*
Due to a breaking change we have to request this explicitly in
Emacs 27. Earlier Emacs versions do the right thing by default.
If the effect of a face does not extend to the edge of the window,
then attributes such as the background color or underline cease to
be used for more that the width of a single character, which is not
appropriate for a face intended to highlight a complete line.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774.
Use "_" as the title of that section so that it is less distracting
when sections are collapsed to get an overview of the library.
Using a separate section is useful because it reduces the risk of
accidentally into the middle of a library.
Placing two semicolons on an otherwise empty line helps to logically
"connect" the surrounding "paragraphs", which in (only) some cases
makes sense.
Previously the three paragraphs of the permission statement were not
connected to each other like this, which is perfectly fine. However
the preceding "This file is not part of GNU Emacs." line was connected
to the first paragraph, which does not make sense considering that the
latter is not connected two the second paragraph, which it relates to
more.
Once those two semicolons are gone, it also makes sense to remove
those from the second line.