Another attempt at handling text/calendar sensibly

[MacGyverNL]

This is an attempt at fixing the following combination of long-standing issues:

1. Outlook sends calendar invites as text/calendar without a content disposition, so it doesn't show up as an attachment.

2. alot doesn't handle text/calendar as a mimepart without explicitly navigating to it via the mimetree.

3. If a user sets their mailcap to text/calendar; cat '%s'; copiousoutput, the calendar contents get displayed as expected, and may be processed using a pipeto command.

The combination of 1 and 2 make it so that text/calendar invites from outlook are effectively hidden by default in alot.

The existence of 3 makes it so that we can't simply turn text/calendar into attachments.

An early attempt at fixing this by allowing text/calendar to be a preferred mimetype was made in https://github.com/pazz/alot/pull/640 but that seems to have been lost. However, we have to assume that the demonstrated workflow based on decoding with mailcap and using pipeto is in use.

https://github.com/pazz/alot/pull/752 handles this situation by having multiple mailcap lines with different flags. This was merged but then removed in 7a883108b1bc6d8b59ac5a14ebf6265312135be2

Another idea, handling all unrendered parts as attachments, was proposed in https://github.com/pazz/alot/issues/777. Since we now have a mimetree, this is not strictly necessary, but it would be nice to be able to save the inline text/calendar as a .ics-file.

Combining these ideas, this proposal does three things (EDIT: the current state of the PR has slightly modified the approach but the underlying principles are the same. See https://github.com/pazz/alot/pull/1607#issuecomment-1246681646.):

1. Introduce an alot-specific x-alot-openattachment field for mailcap, that alot prefers when opening an attachment. If it is not present, alot will fall back to the standard ('view') field for opening the attachment.

2. Every text/calendar part without a content-disposition gets one forced on it, effectively turning it into an attachment. The resulting attachment is visible in the attachments list and can be handled as any other attachment: saved, and handled by mailcap. However, opening such an attachment via the attachment widget will not display it in the current proposal. Since these weren't attachments before, there's no need to handle them backwards-compatible with issue 3 above.

3. When a part gets selected via the mimetree, alot checks whether there is a separate x-alot-openattachment field defined in the mailcap. If there is, alot will first attempt to display the attachment as mimepart, and then open the attachment as per 2. I expect this to be the most controversial change.

Example mailcap entry: text/calendar; cat '%s'; x-alot-openattachment=tmux-horizontal-split-blocking.sh khal import '%s'; copiousoutput

I should note I'm not too attached (hah) to this approach; I coded it up in an afternoon based on what I thought would sensibly fix it for my own usecase. This PR is mostly intended to discuss how to finally deal with this issue sensibly; if we arrive on the solution in this PR itself, all the better.

[MacGyverNL]

Having thought about this some more, the more sensible solution is probably to define an x-alot-attachmenttotext for mailcap and changing the mime-display codepath, so that mailcap's default handler is the "proper" system handler. I'll rewrite this to take that approach.

[MacGyverNL]

So the current proposal is as follows:

• Assume that the default entry is set up to handle attachments as attachments, i.e. open them in whatever application is supposed to handle them.

• Define x-alot-attachmenttotext that provides a way to render the attachment as text. If defined, opening the attachment through the mime tree will both show it as text and open it. If not defined, opening the attachment through the mime tree will only open it.

• When opening the attachment through the attachment widget, it's still only opened even if an x-alot-attachmenttotext handler is defined.

There is no way to only render the attachment (at the moment). I don't really have a usecase for this myself, but perhaps we could gate the mimetree "open attachment" action behind a prompt if the attachment is rendered using an x-alot-attachmenttotext handler?

Example mailcap entry: text/calendar; tmux-horizontal-split-blocking.sh khal import '%s'; x-alot-attachmenttotext=cat '%s'; copiousoutput

[pazz]

Sorry if this is an inappropriately simple suggestion but why don't we simply hard-code an exception to consider a MIME part an attachment if it is text/calendar even if it is lacking a content-disposition?

[MacGyverNL]

At the time I didn't feel up to messing with that part of the code, iirc.

I'm afraid that work circumstances have steered me back to using Thunderbird and plain Maildir for my mail, so I no longer daily-drive alot. For me it's therefore become a non-issue.