Re: Specific Handling for text/calendar MIME Type
On Sun, Jul 21, 2019 at 01:12:19PM -0700, Andrew Marks wrote: What do you think about implementing something like ~M for $index_format? %M is already taken for something else.I'd really like these special emails to be quickly identifiable in the index. Maybe index-format-hook: set index_format="... %1@hascal@ ..." index-format-hook hascal "~M text/calendar" "C" -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Specific Handling for text/calendar MIME Type
Very Nice! This must mean that there is other attachment counting code somewhere. What do you think about implementing something like ~M for $index_format? %M is already taken for something else.I'd really like these special emails to be quickly identifiable in the index. -Andrew On Sun, Jul 21, 2019 at 12:15:39PM -0700, Kevin J. McCarthy wrote: > On Sun, Jul 21, 2019 at 11:40:21AM -0700, Andrew Marks wrote: > >2. Another option is to implement a new limit, specific for finding > >emails which contain text/calendar, this could sort of be a duplicate of > >using attachments with ~X, but perhaps the attachment counting code > >could be isolated and re-used for some more specific limits to be added? > > You may want to try the ~M pattern. As you mention, ~X doesn't recurse > multipart/alternative but I'm not convinced it should. > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
Re: Specific Handling for text/calendar MIME Type
On Sun, Jul 21, 2019 at 11:40:21AM -0700, Andrew Marks wrote: 2. Another option is to implement a new limit, specific for finding emails which contain text/calendar, this could sort of be a duplicate of using attachments with ~X, but perhaps the attachment counting code could be isolated and re-used for some more specific limits to be added? You may want to try the ~M pattern. As you mention, ~X doesn't recurse multipart/alternative but I'm not convinced it should. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Specific Handling for text/calendar MIME Type
I'll get on my soapbox and state that text/calendar mime attachments to e-mail is a horrific way to manage events and/or invites. Also this is currently the bane of my existence because no mail reader makes it easy to manage the many text/calendar attachments I receive. I think the RFC's involved could be and should be used by calendaring software independently of e-mail, the two should never have been combined. END SOAPBOX Regardless, I want to make it easier to manage text/calendar mime attachments in mutt and there are several features I'm considering working on to do this: 1. The easiest approach is to use attachments, however it's not currently possible because multipart/alternative is not recursively counted by the attachments code, and these text/calendar attachments are typically children of multipart/alternative. To fix this I can make a setting which toggles this behavior, so I can count all members of multipart/alternative and change my attachments settings to only count text/calendar. 2. Another option is to implement a new limit, specific for finding emails which contain text/calendar, this could sort of be a duplicate of using attachments with ~X, but perhaps the attachment counting code could be isolated and re-used for some more specific limits to be added? 3. A third thing I've been considering is adding more specific support to index_format for this, again, using attachments and %X could potentially do this, but it could be nice to have a specific option for finding and highlighting e-mail that has text/calendar mime attachments In all cases, the bodies of every e-mail must be inspected, so performance will not be great if your mailbox is not local. I don't see any way around this unless there is some secret header that I am unaware of. If nobody has any better ideas or constructive feedback, I'll probably start with number 1 and go from there. -Andrew
