Going GUI...er

[raf]

Akkana Peck wrote:

> Felix Finch writes:
> > On 20200405, Sam Kuper wrote:
> > > In the meantime, you can just reply to the message (which, after all,
> > > was sent as an email):  "Thanks, I accept your invitation to the meeting
> > > at 5pm PDT on 5th May 2020."
> > 
> > Now that's an idea I hadn't considered!  I was thinking more about
> > the calendar program keeping tabs on who had accepted or not.  But
> > you're right, no need to emulate that.  Just reply to the human.

That's what I've always done. Nobody has complained yet
but I don't get invited to many meetings.

> Aside from the question of how to reply to calendar invites, my
> problem is seeing them in the first place. I don't get calendar
> attachments often, but when I do, I never know they're there.
> This happens for two reasons:

> [...]
> 
> Is there any way to configure mutt to alert me at the top of the
> message if there are any text/calendar or image/* attachments
> anywhere in the message, even as part of a multipart/alternative?
> I feel like I miss a lot in mail messages because mutt doesn't tell
> me about attachments.
> 
>         ...Akkana

I think you're looking for these [but I'm wrong, see below]:

  auto_view type[/subtype] [ ... ]
  unauto_view type[/subtype] [ ... ]

    This commands permits you to specify that mutt should
    automatically convert the given MIME types to text/plain
    when displaying messages.  For this to work, there must
    be a mailcap(5) entry for the given MIME type with the
    copiousoutput flag set.  A subtype of “*” matches any
    subtype, as does an empty sub‐ type.


  implicit_autoview
    Type: boolean
    Default: no

    If set to “yes”, mutt will look for a mailcap entry with
    the “copiousoutput” flag set for every MIME attachment
    it doesn't have an internal viewer defined for.  If such
    an entry is found, mutt will use the viewer defined in
    that entry to convert the body part to text form. MIME
    attachments with 'text' types, with the only exception of
    text/html, are excluded: they will be shown as they are
    unless auto_view is specified.

I didn't know about implicit_autoview but I have the same
problem as you. I just never thought to find a solution.
Thanks for asking! I've always had this in my .muttrc:

  auto_view text/calendar

with the appropriate entry in my .mutt.mailcap file:

  text/calendar; $HOME/bin/mutt.vcalendar.filter; copiousoutput

But I didn't know about implicit_autoview so it would
only work if I thought to look for attachments. I've
just added this to my .muttrc:

  set implicit_autoview = yes

Hmm. It didn't work. I assumed that it would
automatically view the attachments with copiousoutput
mailcap entries. It doesn't. It seems that
implicit_autoview is just an alternative to using the
auto_view option and having to list every mimetype.

Sorry this didn't help. It seems that "view" here
actually means translate into something viewable upon
request. It doesn't mean automatically render
attachments for which there is such a translation. Such
an option would be great.

Actually, I've just thought of a non-ideal solution but
it'll take some work. If I add support for translating
text/calendar to my textmail program, then procmail
could be used to process incoming emails just to
translate those attachments into text/plain and then
mutt would render them automatically because it would
see them as text/plain attachments. It implies a
dependency on procmail or similar so it might not be
suitable in all cases but it would work for me. I don't
know how it would work for IMAP accounts. And it would
replace the original attachment with its text/plain
version which might not always be what you want.

A mutt option to automatically render attachments that
are automatically translatable to text would be ideal.
Perhaps it could be called something like
auto_translate / implicit_autotranslate or auto_render
/ implicit_autorender.

cheers,
raf