Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #240011 > unrolled thread

Mutt/Neomutt and mailcap

Back to article view | Back to linux.debian.user

Contents

  Mutt/Neomutt and mailcap Nate Bargmann <n0nb@n0nb.us> - 2021-09-15 15:40 +0200
    Re: Mutt/Neomutt and mailcap Jonathan Dowland <jon+debian-user@dow.land> - 2021-09-15 17:50 +0200
      Re: Mutt/Neomutt and mailcap Nate Bargmann <n0nb@n0nb.us> - 2021-09-15 20:00 +0200
        Re: Mutt/Neomutt and mailcap Greg Wooledge <greg@wooledge.org> - 2021-09-15 20:20 +0200
          Re: Mutt/Neomutt and mailcap Nate Bargmann <n0nb@n0nb.us> - 2021-09-15 20:20 +0200
          Re: Mutt/Neomutt and mailcap <tomas@tuxteam.de> - 2021-09-15 21:20 +0200
            Re: Mutt/Neomutt and mailcap Nate Bargmann <n0nb@n0nb.us> - 2021-09-15 23:30 +0200
              Re: Mutt/Neomutt and mailcap David Wright <deblis@lionunicorn.co.uk> - 2021-09-16 04:40 +0200
                Re: Mutt/Neomutt and mailcap <tomas@tuxteam.de> - 2021-09-16 08:30 +0200
                Re: Mutt/Neomutt and mailcap Nate Bargmann <n0nb@n0nb.us> - 2021-09-16 12:40 +0200
                  Re: Mutt/Neomutt and mailcap David Wright <deblis@lionunicorn.co.uk> - 2021-09-19 06:50 +0200
          Re: Mutt/Neomutt and mailcap Jonathan Dowland <jon+debian-user@dow.land> - 2021-09-16 09:50 +0200
            Re: Mutt/Neomutt and mailcap <tomas@tuxteam.de> - 2021-09-16 11:10 +0200
            Re: Mutt/Neomutt and mailcap Greg Wooledge <greg@wooledge.org> - 2021-09-16 13:50 +0200
              Re: Mutt/Neomutt and mailcap Jonathan Dowland <jon+debian-user@dow.land> - 2021-09-18 00:30 +0200
    Re: Mutt/Neomutt and mailcap Andrei POPESCU <andreimpopescu@gmail.com> - 2021-09-16 09:40 +0200
      Re: Mutt/Neomutt and mailcap Nate Bargmann <n0nb@n0nb.us> - 2021-09-16 12:10 +0200

#240011 — Mutt/Neomutt and mailcap

[Multipart message — attachments visible in raw view] — view raw

As there are a lot of Mutt/Neomutt users on this list, maybe someone can
point me in the right direction.

Recently via another mailing list a message was posted that included a
diff file with the extension of .patch.  The MIME encoding is shown as
application/octet-stream, using Neomutt's view command.

Pressing Enter on the file name resulting in Geany (GUI text editor)
being opened with the file.  Nothing in my ~/.mailcap nor anything in
/etc/mailcap mapped Geany to this MIME encoding/file name.

As I hadn't been using Geany, I removed it and added the following line
to my ~/.mailcap:

application/octet-stream; vim %s; description=Patch file; nametemplate=%s.patch

Now Neomutt calls less to show the file!

I'm left to be scratching my head as shown here:

$ neomutt -nF /dev/null -Q mailcap_path
set mailcap_path = "~/.mailcap:/usr/share/neomutt/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap"

only ~/.mailcap and /etc/mailcap exist on my system.  I see that less
only shows twice in /etc/mailcap for text/plain and text/*, though the
latter is followed by a text/* that specifies vim.  In ~/.mailcp less is
not shown anywhere.

I'm rather puzzled, to say the least.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [next] | [standalone]

#240020

On Wed, Sep 15, 2021 at 08:37:51AM -0500, Nate Bargmann wrote:
>application/octet-stream; vim %s; description=Patch file; nametemplate=%s.patch

application/octet-stream is a fairly generic mime type (and an odd
choice for a text file, but so it goes). You may find vim is not a
suitable tool for other attachments with that mime type.

That aside,

What does this command report?

     ;see --norun application/octet-stream:/dev/null


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#240024

[Multipart message — attachments visible in raw view] — view raw

* On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> On Wed, Sep 15, 2021 at 08:37:51AM -0500, Nate Bargmann wrote:
> > application/octet-stream; vim %s; description=Patch file; nametemplate=%s.patch
> 
> application/octet-stream is a fairly generic mime type (and an odd
> choice for a text file, but so it goes). You may find vim is not a
> suitable tool for other attachments with that mime type.

It looks like the email came from the SourceForge Web mail server and it
apparently assigned the MIME attachment type.

> That aside,
> 
> What does this command report?
> 
>     ;see --norun application/octet-stream:/dev/null

In the message window, "key not bound", in the view attachment window,
"no tagged entries".  If I tag the file attachment, then ; is accepted
and s is interpreted as 'save file' and the rest of the command string
becomes the proposed file name to save.

I tried preceding the command with : instead and that failed.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#240025

On Wed, Sep 15, 2021 at 12:58:10PM -0500, Nate Bargmann wrote:
> * On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> > What does this command report?
> > 
> >     ;see --norun application/octet-stream:/dev/null
> 
> In the message window, "key not bound", in the view attachment window,
> "no tagged entries".  If I tag the file attachment, then ; is accepted
> and s is interpreted as 'save file' and the rest of the command string
> becomes the proposed file name to save.
> 
> I tried preceding the command with : instead and that failed.

Jonathan's message confused me too.  As far as I can tell, "see" is
a *shell* command, not a mutt command.  I don't know why there's a ";"
in front of it.

unicorn:~$ see --norun application/octet-stream:/dev/null
Error: no "view" mailcap rules found for type "application/octet-stream"

Nothing else I tried made any more sense than that.  Even using ":"
instead of ";" (to invoke it as a mutt command) didn't work, because "see"
isn't a mutt command.

[toc] | [prev] | [next] | [standalone]

#240026

[Multipart message — attachments visible in raw view] — view raw

* On 2021 15 Sep 13:02 -0500, Greg Wooledge wrote:
> On Wed, Sep 15, 2021 at 12:58:10PM -0500, Nate Bargmann wrote:
> > * On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> > > What does this command report?
> > > 
> > >     ;see --norun application/octet-stream:/dev/null
> > 
> > In the message window, "key not bound", in the view attachment window,
> > "no tagged entries".  If I tag the file attachment, then ; is accepted
> > and s is interpreted as 'save file' and the rest of the command string
> > becomes the proposed file name to save.
> > 
> > I tried preceding the command with : instead and that failed.
> 
> Jonathan's message confused me too.  As far as I can tell, "see" is
> a *shell* command, not a mutt command.  I don't know why there's a ";"
> in front of it.

Ahh!  Thanks for that bit of info, Greg!  I'll admit that is one command
I don't recall running across in 25 years of using Linux.

The man page synopsis:

run‐mailcap, view, see, edit, compose, print - execute programs via en‐
tries in the mailcap file

> unicorn:~$ see --norun application/octet-stream:/dev/null
> Error: no "view" mailcap rules found for type "application/octet-stream"

Here it is apparently picking up my ~/.mailcap definition:

$ see --norun application/octet-stream:/dev/null
vim /dev/null

But Neomutt is picking up less instead.  This after closing and
restarting Neomutt after changing the file.

> Nothing else I tried made any more sense than that.  Even using ":"
> instead of ";" (to invoke it as a mutt command) didn't work, because "see"
> isn't a mutt command.

Thanks for restoring my limited sanity.  ;-D

I 'see' what was intended now.

The manual page leads me to the mime.types file, of which I only have a
copy in /etc.  For 'application/octet-stream' it shows this:

application/octet-stream                        bin deploy msu msp

which is not the extension of the attached file.  The .patch extension
appears to be:

text/x-diff                                     diff patch

Of course, we're now dealing with a Web mail server of some kind that is
possibly misconfigured and the odds of getting that fixed are likely
vanishingly small.

Plan B, detach the file and view it manually which I've already done.

Thanks!

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#240027

[Multipart message — attachments visible in raw view] — view raw

On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:
> On Wed, Sep 15, 2021 at 12:58:10PM -0500, Nate Bargmann wrote:
> > * On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> > > What does this command report?
> > > 
> > >     ;see --norun application/octet-stream:/dev/null

> Jonathan's message confused me too.  As far as I can tell, "see" is
> a *shell* command, not a mutt command [...]

Perhaps the semicolon was intended to be an exclamation mark (!)
(although, assuming Jonathan has a USish keyboard layout they are
far apart indeed).

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#240029

[Multipart message — attachments visible in raw view] — view raw

* On 2021 15 Sep 14:20 -0500, tomas@tuxteam.de wrote:
> On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:
> > On Wed, Sep 15, 2021 at 12:58:10PM -0500, Nate Bargmann wrote:
> > > * On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> > > > What does this command report?
> > > > 
> > > >     ;see --norun application/octet-stream:/dev/null
> 
> > Jonathan's message confused me too.  As far as I can tell, "see" is
> > a *shell* command, not a mutt command [...]
> 
> Perhaps the semicolon was intended to be an exclamation mark (!)
> (although, assuming Jonathan has a USish keyboard layout they are
> far apart indeed).

Indeed!  That works.

I missed it in the help list as my mind was fixated on the ;.  Other
programs like Vim use ! as a means to execute a shell command.

It should have been so obvious...

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#240030

On Wed 15 Sep 2021 at 16:21:12 (-0500), Nate Bargmann wrote:
> * On 2021 15 Sep 14:20 -0500, tomas@tuxteam.de wrote:
> > On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:
> > > On Wed, Sep 15, 2021 at 12:58:10PM -0500, Nate Bargmann wrote:
> > > > * On 2021 15 Sep 10:44 -0500, Jonathan Dowland wrote:
> > > > > What does this command report?
> > > > > 
> > > > >     ;see --norun application/octet-stream:/dev/null
> > 
> > > Jonathan's message confused me too.  As far as I can tell, "see" is
> > > a *shell* command, not a mutt command [...]
> > 
> > Perhaps the semicolon was intended to be an exclamation mark (!)
> > (although, assuming Jonathan has a USish keyboard layout they are
> > far apart indeed).
> 
> Indeed!  That works.
> 
> I missed it in the help list as my mind was fixated on the ;.  Other
> programs like Vim use ! as a means to execute a shell command.
> 
> It should have been so obvious...

I think what your system is doing is as follows:

You probably have in your (default) /etc/Muttrc:

  # Use mime.types to look up handlers for application/octet-stream. Can
  # be undone with unmime_lookup.
  mime_lookup application/octet-stream

That sends mutt looking in /etc/mime.types where it finds the line:

  text/x-diff                                     diff patch

Your attachment had the extension ".patch", so it searches your
and the system's mailcap files for "text/x-diff", fails to find it,
and eventually hits the default entry:

   text/*; less '%s'; needsterminal

which it obeys.

BTW, your shell command,

  !see --norun application/octet-stream:/dev/null

will give you an answer in the context of a subshell, and
not necessarily in the context of mutt itself. For example,
on my shell:

$ see --norun text/html:/dev/null
/usr/bin/sensible-browser /dev/null
$ 

but the special mailcap prioritised by my mutt defines:

  text/html; /usr/bin/lynx -force-html -localhost -stdin

and any subshell would know nothing about that.

About the ";", it could also be an accidentally unshifted ":",
and it might be easy to mis-remember:

    ":" is mutt's keystroke for entering mutt commands, whereas
    "!" is mutt's keystroke for entering shell commands.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#240037

[Multipart message — attachments visible in raw view] — view raw

On Wed, Sep 15, 2021 at 09:34:50PM -0500, David Wright wrote:

[...]

> BTW, your shell command,
> 
>   !see --norun application/octet-stream:/dev/null
> 
> will give you an answer in the context of a subshell, and
> not necessarily in the context of mutt itself [...]

Definitely, that's another point. I was just mulling over the
semicolon and came up with a minimal patch ;-)

> About the ";", it could also be an accidentally unshifted ":",
> and it might be easy to mis-remember:

The keyboard (and semantic) distance would be much shorter, this
makes this option attractive -- but there is no `:see' command in
"my" mutt, and, as far as I remember Nate seems to have tried it
unsuccessfully, too.

> 
>     ":" is mutt's keystroke for entering mutt commands, whereas
>     "!" is mutt's keystroke for entering shell commands.

That is why I went for "!" after realising that there's a `see'
shell command but no homonymous mutt command...

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#240048

[Multipart message — attachments visible in raw view] — view raw

* On 2021 15 Sep 21:36 -0500, David Wright wrote:
> I think what your system is doing is as follows:
> 
> You probably have in your (default) /etc/Muttrc:

In my case, /etc/neomuttrc, and the following does exist.

My assumptions have been that the system RC is ignored when a user's RC
exist.  I am finding this is not entirely true in all cases.

>   # Use mime.types to look up handlers for application/octet-stream. Can
>   # be undone with unmime_lookup.
>   mime_lookup application/octet-stream
> 
> That sends mutt looking in /etc/mime.types where it finds the line:
> 
>   text/x-diff                                     diff patch

> Your attachment had the extension ".patch", so it searches your
> and the system's mailcap files for "text/x-diff", fails to find it,

> and eventually hits the default entry:
> 
>    text/*; less '%s'; needsterminal
> 
> which it obeys.

Exactly, and is followed immediately by:

text/*; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; needsterminal

which I have now added to  ~/.mailcap as:

text/x-diff; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; needsterminal

and now the offending attachment is opened in Vim from the view
attachments screen when I press Enter on it.

> BTW, your shell command,
> 
>   !see --norun application/octet-stream:/dev/null
> 
> will give you an answer in the context of a subshell, and
> not necessarily in the context of mutt itself. For example,
> on my shell:
> 
> $ see --norun text/html:/dev/null
> /usr/bin/sensible-browser /dev/null
> $ 
> 
> but the special mailcap prioritised by my mutt defines:
> 
>   text/html; /usr/bin/lynx -force-html -localhost -stdin
> 
> and any subshell would know nothing about that.
> 
> About the ";", it could also be an accidentally unshifted ":",
> and it might be easy to mis-remember:
> 
>     ":" is mutt's keystroke for entering mutt commands, whereas
>     "!" is mutt's keystroke for entering shell commands.

Thanks for the helpful pointers through the maze!

The problem is that I visit something like this once about every several
years and it's all new again.  Sigh...

Finally, the Web mailer that assigned application/octet-stream may not
be that far off if it is assuming the recipient's MUA and MIME handling
is configured correctly, which it actually is.  I was just a bit annoyed
at the end result and now I have it set per my preference.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [next] | [standalone]

#240134

On Thu 16 Sep 2021 at 05:37:43 (-0500), Nate Bargmann wrote:
> * On 2021 15 Sep 21:36 -0500, David Wright wrote:
> > I think what your system is doing is as follows:
> > 
> > You probably have in your (default) /etc/Muttrc:
> 
> In my case, /etc/neomuttrc, and the following does exist.
> 
> My assumptions have been that the system RC is ignored when a user's RC
> exist.  I am finding this is not entirely true in all cases.

I can't speak for neomutt, but mutt has started by reading /etc/Muttrc
(unless you tell it not to, with -n) ever since it entered Debian in
hamm (1998). Being read after Muttrc, your own .muttrc can overwrite
mutt's defaults.

There are programs that behave in the way you suggested;
for example, xpdf comes to mind.

> Thanks for the helpful pointers through the maze!
> 
> The problem is that I visit something like this once about every several
> years and it's all new again.  Sigh...

Yes, same here, which is partly why I tried tracking it through.
I actually have a ~/.mutt/mailcap-mutt defined that matches only
a very select set of file types.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#240042

On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:
>Jonathan's message confused me too.  As far as I can tell, "see" is
>a *shell* command, not a mutt command.

Sorry for the confusion, I should have been clearer that it was a shell
command, intended to narrow the problem down to either mailcap or
neomutt. It seems David has provided the ultimate solution.

>I don't know why there's a ";" in front of it.

That's (part of) my shell prompt. It's a convention originating in the
rc shell (although I learned of it from another); it permits you to copy
and paste directly from the shell buffer if you want to repeat a
sequence of commands.

My complete shell prompt, sans control characters, is

     : coil ▶;

where "coil" is my local hostname. With control characters, the colon
and semi-colon are disguised as part of colouring the prompt.  I vary
the colours I use depending on user@hostname. The implementation is
here: <https://github.com/jmtd/punctual/blob/main/punctual.sh>


-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#240043

[Multipart message — attachments visible in raw view] — view raw

On Thu, Sep 16, 2021 at 08:47:32AM +0100, Jonathan Dowland wrote:
> On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:

[...]

> >I don't know why there's a ";" in front of it.
> 
> That's (part of) my shell prompt [...]

AAAAaaah :-)

Thanks for clearing that up. My hunch was at least as far away from
truth as both keys are in standard US keyboard ;-P

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#240050

On Thu, Sep 16, 2021 at 08:47:32AM +0100, Jonathan Dowland wrote:
> On Wed, Sep 15, 2021 at 02:01:23PM -0400, Greg Wooledge wrote:
> > I don't know why there's a ";" in front of it.
> 
> That's (part of) my shell prompt. It's a convention originating in the
> rc shell (although I learned of it from another); it permits you to copy
> and paste directly from the shell buffer if you want to repeat a
> sequence of commands.

Unfortunately, it breaks in Bourne-family shells.

unicorn:~$ ;true
bash: syntax error near unexpected token `;'

In Bourne/POSIX/bash, semicolon is a command terminator or separator,
and may not appear by itself, or at the start of a command.  It may
appear at the end.

Ksh seems to be an exception, and tolerates it at the beginning as well.

[toc] | [prev] | [next] | [standalone]

#240084

On Thu, Sep 16, 2021 at 07:43:25AM -0400, Greg Wooledge wrote:
>Unfortunately, it breaks in Bourne-family shells.
snip
>In Bourne/POSIX/bash, semicolon is a command terminator or separator,
>and may not appear by itself, or at the start of a command.  It may
>appear at the end.

Good catch! I never actually tried a plain ';', so I hadn't hit that.
When I appropriated the idea, I prefixed it with ':' in order to get
my hostname into the line too (: hostname ;), side-stepping the issue.

-- 

Jonathan Dowland
https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#240039

[Multipart message — attachments visible in raw view] — view raw

On Mi, 15 sep 21, 08:37:51, Nate Bargmann wrote:
> As there are a lot of Mutt/Neomutt users on this list, maybe someone can
> point me in the right direction.
> 
> Recently via another mailing list a message was posted that included a
> diff file with the extension of .patch.  The MIME encoding is shown as
> application/octet-stream, using Neomutt's view command.
> 
> Pressing Enter on the file name resulting in Geany (GUI text editor)
> being opened with the file.  Nothing in my ~/.mailcap nor anything in
> /etc/mailcap mapped Geany to this MIME encoding/file name.
> 
> As I hadn't been using Geany, I removed it and added the following line
> to my ~/.mailcap:
> 
> application/octet-stream; vim %s; description=Patch file; nametemplate=%s.patch
> 
> Now Neomutt calls less to show the file!
> 
> I'm left to be scratching my head as shown here:
> 
> $ neomutt -nF /dev/null -Q mailcap_path
> set mailcap_path = "~/.mailcap:/usr/share/neomutt/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap"
> 
> only ~/.mailcap and /etc/mailcap exist on my system.  I see that less
> only shows twice in /etc/mailcap for text/plain and text/*, though the
> latter is followed by a text/* that specifies vim.  In ~/.mailcp less is
> not shown anywhere.

For neomutt in buster I have this in .neomuttrc:

# neomutt disabled viewing text/* as text (except text/plain)
# re-enable common file types received (requires corresponding .mailcap entry)
auto_view text/x-diff
auto_view text/x-patch
auto_view text/x-gettext


Corresponding .mailcap entries:

text/x-diff;    nvim %s
text/x-patch;   nvim %s
text/x-gettext; nvim %s
text/x-diff;    cat %s; copiousoutput
text/x-patch;   cat %s; copiousoutput
text/x-gettext; cat %s; copiousoutput


As far as I recall the 'auto_view' and the 'copiousoutput' lines are for 
automatic display in (neo)mutt's pager, the other ones for attachment 
menu.


Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#240046

[Multipart message — attachments visible in raw view] — view raw

* On 2021 16 Sep 02:35 -0500, Andrei POPESCU wrote:
> For neomutt in buster I have this in .neomuttrc:
> 
> # neomutt disabled viewing text/* as text (except text/plain)
> # re-enable common file types received (requires corresponding .mailcap entry)
> auto_view text/x-diff
> auto_view text/x-patch
> auto_view text/x-gettext
> 
> 
> Corresponding .mailcap entries:
> 
> text/x-diff;    nvim %s
> text/x-patch;   nvim %s
> text/x-gettext; nvim %s
> text/x-diff;    cat %s; copiousoutput
> text/x-patch;   cat %s; copiousoutput
> text/x-gettext; cat %s; copiousoutput
> 
> 
> As far as I recall the 'auto_view' and the 'copiousoutput' lines are for 
> automatic display in (neo)mutt's pager, the other ones for attachment 
> menu.

Thanks, Andrei.  I can add those for future attachments that are
assigned a proper MIME type.  In this case, the attachment was assigned
the application/octet-stream MIME type by the SourceForge.net Web mailer
(at least that is what I gleaned from the headers).

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web