My first problem as a neomutt user: text attachment

[nobrowser]

I use a script to send myself articles of web feeds via email. (The script is like rss2email, but better.) These emails have a MIME part of the type text/uri-list , with a comment line and a link to the feed webpage, like this:

--===============0661327809087214530==
Content-Type: text/uri-list; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

# URL
https://www.debian.org/security/2017/dsa-3908

Mutt 1.5.24, which I have been using up to now, shows the attachment inline in the pager, so I can immediately do the appropriate rodent maneuver with the link and view it in a browser if that seems necessary, as it would be in the above example.

But neomutt says: "text/uri-list is unsupported (use 'v' to view this part)" so I have to spend some 10 more keystrokes to get the link to the screen.

To my knowledge, nothing else that is relevant changed on this system; in particular mime.types is provided by the distro, and I have the same personal .mailcap.

This is a regression, though I cannot be sure if it happened with neomutt or with one of the original mutt releases that I skipped.

[flatcap]

I remember a change to how we treated "text/*" objects. I thought that we'd deemed them always-readable.

However, a lot has changed since 1.5.24. Please can you try plain mutt-1.8.3 and check the behaviour there.

[somini]

The issue @flatcap mentions is #449, but it does the opposite, it doesn't treat all "text/*" MIME as readable. Read #555 too.

The solution is putting this line on you "mailcap":

text/*; cat; copiousoutput

[nobrowser]

Hmm. Ok, that setting works. But, it seems a bit illogical to me for mutt do rely on mailcap to decide what to show inline. To my pointy-eared head, mailcap is for deciding how to show a type externally, once we know that an external viewer is in fact necessary or desired.

I understand the motivation for the change in #449 , but I'm not completely on board with this way of re-purposing the configuration. Was it done this way to avoid the introduction of yet more .muttrc commands or variables?

[somini]

No, there is no repurposing. Mailcap was always used like this.

The copiousoutput token lets mutt know this program outputs human-readable text, so it should be used inline. An an example, I have the following line in mailcap:

application/*; xdg-open %s;
application/zip; zipinfo -hstz %s; copiousoutput; description="ZIP archive";

This shows me the contents of zip file inline (copiousoutput), but I can use the attachment screen to open zipfile using xdg-open.

449 removed a special case that was hardcoded into mutt, which lead to illogical behaviour.

I agree that this very useful feature is not obvious at first, but since it requires so much configuration and human decision, it's definitively advanced usage.

[nobrowser]

But this was an abuse of copiousoutput to start with (if mutt did in fact work this way).

copiousoutput means what it says: the output from the external viewer is expected to be "copious" (i.e. long), this is a hint to the calling program that it should further filter it through something like less.

[somini]

Mutt did work that way, #449 just removed the assumption that all text mimes were human readable.

My take is that copious output shown inline is OK, since the inline viewer is in fact a pager. It can be controlled by the pager variable, defaulting to "builtin", as i recall.

[nobrowser]

Let's beat this dead equine a little harder still ;-) It is OK to show types labelled copiousoutput inline. This issue was about the other side of the coin. Why should non-copious stuff have to be shown externally? If it is about readability by humans in raw form, how does copious versus non-copious matter? I'm going to add disposition=inline to the automatically generated MIME parts and see if it makes a difference. Arguably that was an omission on my side.

[somini]

My guess is that copious output is not a good name. It should mean the output doesn't need a terminal, so it can be show inline. If the program needs a terminal, it must be shown externally. If you missconfigure mailcap and pipe the output to less in a copious entry, less will fail because it will try to take over the same terminal mutt is using.

[nobrowser]

Wait, so because the standard doesn't agree with mutt, the standard is wrong?

mutt didn't invent the mailcap file. It appeared with MIME and the reference implementation of MIME (metamail). It is specified in RFC 1524. That document provides a way to specify that a viewer app doesn't need a terminal, it is the absence of the "needsterminal" flag. Surprise!

And as promised, I improved my program to include a Content-Disposition: inline header. I didn't really expect it to make a difference, and it didn't. My firm position now is that this is a bug in neomutt (and in mutt).

[gahr]

What RFC 1524 fails to specify is a flag indicating whether view-command will convert the file and produce a textual representation that can be put in a pager, in opposite to, say, spawn an X11 viewer. The copiousoutput flag is as near to that as we can get: by indicating that the view-command will generate several lines of output it is implied that it generates some lines to begin with.

Am I missing something?

[nobrowser]

@gahr : true, but there is a mechanism for deciding what MIME parts should appear inline; it is the Content-Disposition header specified in RFC 2183. Given this fact we should not reinterpret copiousoutput as "close enough". I propose that neomutt show inline all MIME parts satisfying all these conditions:

• MIME type matches text/*
• MIME type matches one in an auto_view command in .muttrc
• has Content-Disposition: inline header

and no others. text/plain may be an exception, or not (but if not an exception is still needed for the first such part which is normally the main message - I'm guessing such an exception is in the code now).

[somini]

I agree.

With this proposal, the user can still avoid seeing certain MIMEs by specifying unauto_view MIME. For mailcap where the user explicitly configured as copiousoutput should continue to be shown inline.

[nobrowser]

I have to disagree, copiousoutput should not be part of the criterion. After all #449 was done to simplify the code - I don't want to undo that.

[nobrowser]

A useful exercise may be to look at what other terminal based MUAs do, I can look at Gnus, alpine anyone?

[somini]

If copious output is ignored, how can users control what is shown inline, to force show and force no show? Note this is different from the hints sent in the email, i.e. Content disposition.

[nobrowser]

If you really think that needs to be under user control, add a new .muttrc variable.

[rant] Real simplification is never achieved by making different things look the same. The Unix API would have been better had files and pipes been distinct on the system call level. Then if there are common traits, unify them in a higher level abstraction. [/rant]

[nobrowser]

Everyone seems to agree :-)

So, I'm taking this and I plan to tackle it very soon.

[nobrowser]

Well, I started working on it, but in the process I'm slowly coming over to @gahr 's point of view. I'll leave it around, think some more about it, then maybe scratch it.