Gnus development mailing list
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: Trouble viewing PDF attachments (with patches)
Date: Wed, 31 Dec 2014 09:20:22 +0800	[thread overview]
Message-ID: <87iogszkbt.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <kssifxl69f.fsf@luna.netfonds.no>

peder@news.klingenberg.no (Peder O. Klingenberg) writes:

> Lately, all my attempts to view PDF attachments have ended in
> 'mailcap-save-binary-file instead of popping up xpdf like they used to.
> After spending far to long last night digging through sources, the
> culprit turned out to be Lars' commit f8b31759 from December 6, which
> added the symbol doc-view-mode to mailcap-mime-data as a PDF viewer.[1]

Thanks for digging into this! I've been annoyed by the same problem for
quite a while, though obviously not annoyed enough to actually go
looking for the problem. I hope your solution or something like it is
accepted!

Eric

> This confused mm-display-part, which thought all methods should be
> strings.  Removing that test passes doc-view-mode on to
> mm-display-external, which already has provisions for funcalling
> symbols.  That's what the first attached patch does.
>
> However, the support for lisp-based "external" viewers in
> mm-display-external seems not exactly complete.  When I tried to show
> attachments with only the first patch applied, a doc-view-mode buffer
> replaced my article buffer, but focus remained in the summary buffer,
> and thus the keymaps were not those of DocView.
>
> The second patch below tries to alleviate that, but I'm out of my depth
> and not really happy with it.  What I wanted to do was to let DocView
> (or in general, whatever lisp-based viewer mailcap would return) take
> over the frame, and when I'm done with it, pop back to my gnus windows.
> Ideally, I also think that it should be configurable to pop up a new
> frame, so I can keep reading the article while looking at the PDF.
>
> I settled instead for popping back to just the summary buffer, which
> means another keystroke to reopen the article.  And the way I did that
> seems ugly and hackish to me.  Thoughts?
>
> (emacs copyright assignment is on file, should you choose to apply
> either of these patches)
>
> ...Peder...
>
> Footnotes: 
> [1] I'm not really conviced that was a good idea, but there's no reason
>     it shouldn't work in principle.  If it can be made to work as well
>     as an external viewer, I'm probably in favour, as DocView in my
>     already open emacs is much faster than spawning an external program
>     when running X remotely over the wet string they label broadband.




  reply	other threads:[~2014-12-31  1:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-30 11:35 Peder O. Klingenberg
2014-12-31  1:20 ` Eric Abrahamsen [this message]
2014-12-31  9:16   ` Peder O. Klingenberg
2014-12-31 10:29     ` Eric Abrahamsen
2014-12-31 14:04       ` Peder O. Klingenberg
2015-01-26  3:28 ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iogszkbt.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).