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.
next prev parent 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).