Peder O. Klingenberg
2014-12-30 11:35:40 UTC
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]
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.
'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]
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.
--
I wish a new life awaited _me_ in some off-world colony.
I wish a new life awaited _me_ in some off-world colony.