Inline display of gzipped files

["Adam Sjøgren" <asjo@koldfront.dk>]

When I get an attachment with a single zipped file in it:

  [1. application/zip; google.com!koldfront.dk!1573257600!1573343999.zip]

I can get it displayed directly inline in Gnus by pressing RET on it.
This is very nice.

When I get an attachment which is a gzip'ed file like this:

  [2. application/tlsrpt+gzip; google.com!koldfront.dk!1573257600!1573343999!001.json.gz]...

RET prompts me for where to save the attachment, which makes it slightly
more cumbersome to inspect the contents.

I was about to ask if somebody knew how to change this, but let me start
chasing it myself first.

It looks like RET runs "Toggle Display", which for the application/zip
becomes "View As Text, In This Buffer", from the "MIME Part" menu.

If I go i ("View As Text, In This Buffer") on the gzip'ed file, the
contents are displayed inline as I wanted.

So it's just the "do what I mean" part of "Toggle Display" I have to
figure out how to modify.

C-h k RET says "Toggle Display" runs (gnus-article-press-button) in
gnus-art.el, and that ... just calls a function defined on the text. Hm.
What function would that be.. I guess I can just M-x edebug-defun
gnus-article-press-button and then try.

Stepping through the function reveals that it is gnus-mm-display-part
which is called. Cool, on to looking at that.

That looks too complicated for me to really wrap my head around. But
there is a call to a function in mm-decode.el, so let me look at that.
Hm. Ok, why not just search for application/zip, and see if I'm lucky.

Oooh, now I found a defcustom called mm-inline-media-tests, which has an
entry for application/zip:

    ("application/zip" mm-archive-dissect-and-inline identity)

Maybe I can just add an entry for application/.*gzip? Hm, searching more
for application/zip also reveal mm-inlined-types. M-x occur says that
those are the only two places, so maybe it would work to add
"application/.*gzip" to those.

I think, however, that mm-archive-dissect-and-inline need to be taught
how to handle application/tlsrpt+gzip as well. Hm. If I'm lucky, it
already knows how to do gzip, so I just have to fix the "blabla+" part.

That looks too complicated for me.

Different approach: edebug-defun the function called by pressing RET - I
find that mm-readable-p is what stops the content from being displayed.

So it should be decompressed and _then_ the heuristic for determining
whether to display inline or not should be applied.

Don't know how to do that either. Maybe I will just stick:

  ("application/.*gzip" mm-inline-text identity)

in mm-inline-media-tests, and "application/.*gzip" in mm-inlined-types
and call it a day.

It would be nice, if the filename ends in ".json" to pretty print the
contents before displayed, as well. Not sure how to do that either.

Maybe something like mm-inline-render-with-stdin for piping it through
json_pp? But surely Emacs has a function to pretty print JSON...


[[[ This has been a documentary on how someone tries to make Gnus do
    what you want. Thank you for watching. No animals were harmed during
    production. ]]]


-- 
 "Darkness has a way of shedding light on me                Adam Sjøgren
  Seems the more I'm lost the more I'm feeling free"   asjo@koldfront.dk