Neomutt: No priority for `copiousoutput` when `view-attach`

Created on 22 Jul 2019  路  1Comment  路  Source: neomutt/neomutt

Expected Behaviour

There are 2 ways of opening an email attachment : pressing <enter> or m, which would invoke view-attach or view-mailcap respectively.

In mutt, describing a mailcap entry as copiousoutput allows me to open the attachment in mutt when pressing <enter>. In contrast, if there is a matching entry without that option, it will take precedence when using m.

For example:

text/html; (firefox %s &) && sleep 0.5; test=RunningX
text/html; /usr/bin/w3m -I %{charset} -s -T text/html -dump; copiousoutput

Hitting <enter> would use the second entry; with m, the first one is used.

Actual Behaviour

Neomutt always use the first entry, no matters if I use <enter> or m.

Steps to Reproduce

Find an email with a text/html attachment. Put those 2 lines early in your mailcap file. Try to open the attachment using <enter> and m. Both attempts will open the file in firefox.

How often does this happen?

  • Always

When did it start to happen?

I tried to track it back in using git bisect, but I got as early as 2013 commits with the same behavior described above. If I use mutt instead (default version of my distro) with the same configuration files I have for neomutt, the behavior is as expected.

NeoMutt Version

As mentioned above, it did not change when I tried to compile neomutt with several commits, even with date of 2013.

Extra Info

  • Operating System and its version

Ubuntu 19.04

  • Were you using multiple copies of NeoMutt at once?

Yes, my email was open the whole time. I haven't thought about that.

  • Were you using 'screen' or 'tmux'?

No

  • Is your email local (maildir) or remote (IMAP)?

Local (maildir with isync)

confirmed bisect

Most helpful comment

I've bisected this and the cause is f62d8987721265f91d38552705e3facbb20be0c6.
Reverting this fixes _this_ issue, but I haven't considered the original issue #430
See branch devel/mailcap

>All comments

I've bisected this and the cause is f62d8987721265f91d38552705e3facbb20be0c6.
Reverting this fixes _this_ issue, but I haven't considered the original issue #430
See branch devel/mailcap

Was this page helpful?
0 / 5 - 0 ratings