Use the updated support for HTML messages (even converting plain-text
only). Update the link detection, clean up.
Add links for e-mail addresses too, not just ones that start with
mailto:.
Only show link-indicators when mu4e-view-go-to-url or mu4e-view-save-url
are invoked, or with mu4e-view-always-show-indicator set to non-nil.
Update docs.
Produce HTML-versions of messages, even plain-text ones without an
HTML-part. This allows for uniform handling, e.g. showing a message in
an external browser.
Implement linkification as well.
New stable version:
- silence some MIME part errors
- some emacs 28.1+ modernization
- list org links with M-x mu4e-org-agenda-links
- when replying to a message with some part selected, cite only that
part
- fix parsing of the Keywords: headers. If you use those, you're
recommend to re-index your message
New command mu4e-org-agenda-links to pop up a buffer with a tabulated
list of the mu4e links in your org-agenda-files
x
This is just a little experiment.
Some Gnus commands depend on the existence of a *Summary* buffer; and in
older versions of mu4e we created it, since mu4e depended on it. It no
longer does, but some gnus command users may want to try, do.
So create the Summary buffer once again.
New stable version:
- Improvements in documentation
- Improvements in display of attachments / MIME-parts
- Better HTML toggling
- Support MIME icons
- Bug fixes
In mu4e--view-cleanup-message-text (used for "reply citing") we were
removing all gnus "buttons", however gnus also includes buttons for
addresses, URLs etc., which should stay.
So be a bit let eager and only remove gnus-mm-display-part items.
Issue #2922
Fix the mu4e-view-toggle-html switching, which could re-insert body
parts when an Attachments: header was present.
I.e. specifically toggle the part in the body.
Restrict fields in mu4e-view-fields. Make the defcustom a bit more
helpful by checking for valid fields.
Add :labels to default fields
Remove some unused code.
This scratches an itch of mine: being able to sign messages when they're replies
to signed messages.
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Better handle some 'special' MIME-types where we need a tiny bit of
processing/special casing to invent a proper file-name.
Include size information when displaying the MIME-types in the actions
menu.
Do not consider calender-invitations "attachments"; do mark as
"calendar". Do recognize application/ics as calendar messages.
Update mime-object to expose a message part's disposition.
Change the "is-attachment" heuristic to include inline parts if they
have a filename parameter in their content-disposition.
Note that this doesn't change things radically; the delta is +69 and
-202 for ~6500 attachments.
