Gnus development mailing list
 help / color / mirror / Atom feed
* Trouble viewing PDF attachments (with patches)
@ 2014-12-30 11:35 Peder O. Klingenberg
  2014-12-31  1:20 ` Eric Abrahamsen
  2015-01-26  3:28 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 6+ messages in thread
From: Peder O. Klingenberg @ 2014-12-30 11:35 UTC (permalink / raw)
  To: ding

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

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.

-- 
I wish a new life awaited _me_ in some off-world colony.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-mm-decode.el-Make-non-string-display-methods-work.patch --]
[-- Type: text/x-diff, Size: 1879 bytes --]

From 741286e6b94fbbda876e26689aeb7b42a3e1c2f2 Mon Sep 17 00:00:00 2001
From: "Peder O. Klingenberg" <peder@klingenberg.no>
Date: Tue, 30 Dec 2014 10:00:25 +0100
Subject: [PATCH] mm-decode.el: Make non-string display methods work.

* mm-decode.el (mm-display-part): Make non-string methods work.
Non-string methods are funcalled and work just fine, the test was
bogus.

Signed-off-by: Peder O. Klingenberg <peder@klingenberg.no>
---
 lisp/ChangeLog    |  6 ++++++
 lisp/mm-decode.el | 10 +++++-----
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 786ee1b..2dfe657 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,9 @@
+2014-12-30  Peder O. Klingenberg  <peder@klingenberg.no>
+
+	* mm-decode.el (mm-display-part): Make non-string methods work.
+	Non-string methods are funcalled and work just fine, the test was
+	bogus.
+
 2014-12-20  Katsumi Yamaoka  <yamaoka@jpl.org>
 
 	* registry.el (cl-remf, cl-loop, cl-subseq):
diff --git a/lisp/mm-decode.el b/lisp/mm-decode.el
index f5b4d7c..1b5ca9a 100644
--- a/lisp/mm-decode.el
+++ b/lisp/mm-decode.el
@@ -833,18 +833,18 @@ external if displayed external."
 		'inline)
 	    (setq external
 		  (and method	      ;; If nil, we always use "save".
-		       (stringp method) ;; 'mailcap-save-binary-file
 		       (or (eq mm-enable-external t)
 			   (and (eq mm-enable-external 'ask)
 				(y-or-n-p
 				 (concat
 				  "Display part (" type
-				  ") using external program"
-				  ;; Can non-string method ever happen?
+				  ") "
 				  (if (stringp method)
 				      (concat
-				       " \"" (format method filename) "\"")
-				    "")
+				       "using external program \""
+				       (format method filename) "\"")
+				    (format
+				     "by calling `%s' on the contents)" method))
 				  "? "))))))
 	    (if external
 		(mm-display-external
-- 
1.9.1


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0003-Show-external-lisp-viewers-in-whole-frame.patch --]
[-- Type: text/x-diff, Size: 1603 bytes --]

From ed90426bb18f17f0a06a32c4112d2b59c2bdda1d Mon Sep 17 00:00:00 2001
From: "Peder O. Klingenberg" <peder@klingenberg.no>
Date: Tue, 30 Dec 2014 11:28:12 +0100
Subject: [PATCH] Show "external" lisp viewers in whole frame.

* mm-decode.el (mm-display-external): Show "external" lisp viewers in
whole frame.

Signed-off-by: Peder O. Klingenberg <peder@klingenberg.no>
---
 lisp/ChangeLog    |  2 ++
 lisp/mm-decode.el | 10 +++++++++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 2dfe657..a129284 100644
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -3,6 +3,8 @@
 	* mm-decode.el (mm-display-part): Make non-string methods work.
 	Non-string methods are funcalled and work just fine, the test was
 	bogus.
+	* mm-decode.el (mm-display-external): Show "external" lisp viewers in
+	whole frame.
 
 2014-12-20  Katsumi Yamaoka  <yamaoka@jpl.org>
 
diff --git a/lisp/mm-decode.el b/lisp/mm-decode.el
index 1b5ca9a..fd12813 100644
--- a/lisp/mm-decode.el
+++ b/lisp/mm-decode.el
@@ -885,7 +885,15 @@ external if displayed external."
 				     (mm-handle-media-type handle) t))))
 	      (unwind-protect
 		  (if method
-		      (funcall method)
+		      (progn
+			(when (and (boundp 'gnus-summary-buffer)
+				   (bufferp gnus-summary-buffer)
+				   (buffer-name gnus-summary-buffer))
+			  ;; So that we pop back to the right place, sortof.
+			  (switch-to-buffer gnus-summary-buffer)
+			  (switch-to-buffer mm))
+			(delete-other-windows)
+			(funcall method))
 		    (mm-save-part handle))
 		(when (and (not non-viewer)
 			   method)
-- 
1.9.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Trouble viewing PDF attachments (with patches)
  2014-12-30 11:35 Trouble viewing PDF attachments (with patches) Peder O. Klingenberg
@ 2014-12-31  1:20 ` Eric Abrahamsen
  2014-12-31  9:16   ` Peder O. Klingenberg
  2015-01-26  3:28 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2014-12-31  1:20 UTC (permalink / raw)
  To: ding

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.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Trouble viewing PDF attachments (with patches)
  2014-12-31  1:20 ` Eric Abrahamsen
@ 2014-12-31  9:16   ` Peder O. Klingenberg
  2014-12-31 10:29     ` Eric Abrahamsen
  0 siblings, 1 reply; 6+ messages in thread
From: Peder O. Klingenberg @ 2014-12-31  9:16 UTC (permalink / raw)
  To: ding

On on., des. 31 2014 at 09:20, Eric Abrahamsen wrote:

> 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!

Thanks.  As a workaround, you could always do some surgery to
mailcap-mime-data in your init file, and remove doc-view-mode.

(It would be nice to have a good interface to manipulate that variable,
including some control over which viewer is preferred, but generally it
just works well enough as is, so I don't know if it would be worth the
effort.)

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Trouble viewing PDF attachments (with patches)
  2014-12-31  9:16   ` Peder O. Klingenberg
@ 2014-12-31 10:29     ` Eric Abrahamsen
  2014-12-31 14:04       ` Peder O. Klingenberg
  0 siblings, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2014-12-31 10:29 UTC (permalink / raw)
  To: ding

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

> On on., des. 31 2014 at 09:20, Eric Abrahamsen wrote:
>
>> 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!
>
> Thanks.  As a workaround, you could always do some surgery to
> mailcap-mime-data in your init file, and remove doc-view-mode.

Hmm, I haven't removed that entry, but I do have earlier entries keyed
to "pdf" that point to xdg-open. Still doesn't use it, though...

> (It would be nice to have a good interface to manipulate that variable,
> including some control over which viewer is preferred, but generally it
> just works well enough as is, so I don't know if it would be worth the
> effort.)
>
> ...Peder...




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Trouble viewing PDF attachments (with patches)
  2014-12-31 10:29     ` Eric Abrahamsen
@ 2014-12-31 14:04       ` Peder O. Klingenberg
  0 siblings, 0 replies; 6+ messages in thread
From: Peder O. Klingenberg @ 2014-12-31 14:04 UTC (permalink / raw)
  To: ding

On on., des. 31 2014 at 18:29, Eric Abrahamsen wrote:

> peder@news.klingenberg.no (Peder O. Klingenberg) writes:
>
>> Thanks.  As a workaround, you could always do some surgery to
>> mailcap-mime-data in your init file, and remove doc-view-mode.
>
> Hmm, I haven't removed that entry, but I do have earlier entries keyed
> to "pdf" that point to xdg-open. Still doesn't use it, though...

That's because mailcap.el sorts the candidates using
mailcap-viewer-lessp, which is hardcoded to prefer lisp-implemented
viewers.

Hence my wishlist item for some way to configure the preferencing.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Trouble viewing PDF attachments (with patches)
  2014-12-30 11:35 Trouble viewing PDF attachments (with patches) Peder O. Klingenberg
  2014-12-31  1:20 ` Eric Abrahamsen
@ 2015-01-26  3:28 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2015-01-26  3:28 UTC (permalink / raw)
  To: Peder O. Klingenberg; +Cc: ding

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

> 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?

Nothing obvious occurs to me...

I've applied both patches, but we can perhaps tweak this later if it
seems annoying. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-01-26  3:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-30 11:35 Trouble viewing PDF attachments (with patches) Peder O. Klingenberg
2014-12-31  1:20 ` Eric Abrahamsen
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

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).