Commits on Sep 14, 2022

1. Another attempt at handling text/calendar sensibly …

   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 <pazz#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.
   
   <pazz#752> handles this situation by having
   multiple mailcap lines with different flags. This was merged but then
   removed in 7a88310
   
   Another idea, handling all unrendered parts as attachments, was proposed
   in <pazz#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:
   
   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```

   

   MacGyverNL committed Sep 14, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 16c388c
   • Browse repository at this point

   Copy the full SHA

   16c388c View commit details

   Browse the repository at this point in the history

2. Invert mailcap logic: x-alot-attachmenttotext …

   Rather than use x-alot-openattachment, and rely on the default ('view')
   mailcap entry to dump the attachment to text, 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.
   
   Instead, 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.

   

   MacGyverNL committed Sep 14, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 463f9c6
   • Browse repository at this point

   Copy the full SHA

   463f9c6 View commit details

   Browse the repository at this point in the history