External viewer output inserted into Article buffer

External viewer output inserted into Article buffer

[Tassilo Horn]

Hi all,

when I receive a mail with some PDF attachment and hit RET on it, evince
will be opened as external viewer.  When I start evince (on the command
line), it'll issue some fontconfig warning:

  Fontconfig warning: "/etc/fonts/conf.d/59-google-droid-sans.conf", line 61: Having multiple values in <test> isn't supported and may not work as expected

Now when I close the evince instance that was opened from within gnus,
that warning is inserted into the Article buffer.

It's just a viewing issue.  When opening the article again, the
fontconfig warnings aren't there anymore.

I use both a recent gnus from git and a recent emacs 24 from bzr trunk.

Bye,
Tassilo

Re: External viewer output inserted into Article buffer

[Michael Heerdegen]

Tassilo Horn <tsdh@gnu.org> writes:

> Hi all,
>
> when I receive a mail with some PDF attachment and hit RET on it, evince
> will be opened as external viewer.  When I start evince (on the command
> line), it'll issue some fontconfig warning:
>
>   Fontconfig warning: "/etc/fonts/conf.d/59-google-droid-sans.conf",
> line 61: Having multiple values in <test> isn't supported and may not
> work as expected
>
> Now when I close the evince instance that was opened from within gnus,
> that warning is inserted into the Article buffer.
>
> It's just a viewing issue.  When opening the article again, the
> fontconfig warnings aren't there anymore.

I see the same problem, but with attached pictures and the feh viewer.  Seems to
be a general problem.

I use emacs-snapshot on Debian.


Regards,

Michael.

Re: External viewer output inserted into Article buffer

[Katsumi Yamaoka]

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

Michael Heerdegen wrote:
> Tassilo Horn <tsdh@gnu.org> writes:

>> Hi all,
>>
>> when I receive a mail with some PDF attachment and hit RET on it, evince
>> will be opened as external viewer.  When I start evince (on the command
>> line), it'll issue some fontconfig warning:
>>
>>   Fontconfig warning: "/etc/fonts/conf.d/59-google-droid-sans.conf",
>> line 61: Having multiple values in <test> isn't supported and may not
>> work as expected
>>
>> Now when I close the evince instance that was opened from within gnus,
>> that warning is inserted into the Article buffer.
>>
>> It's just a viewing issue.  When opening the article again, the
>> fontconfig warnings aren't there anymore.

> I see the same problem, but with attached pictures and the feh viewer.  Seems to
> be a general problem.

This is a feature Lars added:

2012-02-09  Lars Ingebrigtsen  <larsi@gnus.org>
 * mm-decode.el (mm-display-external): Output the text from the command
 in the buffer after the command finished.  This makes text-based
 commands behave better.

If you want those warnings to appear in the article buffer without
waiting for finishing of a command, something like a quick hack
attached below will help.  Otherwise, if you want certain kinds of
text not to appear, I have no idea how to distinguish whether it's
a warning or whether a command is used for text-output.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2103 bytes --]

--- mm-decode.el~	2013-01-30 09:41:37.287257600 +0000
+++ mm-decode.el	2013-02-27 09:20:30.267956900 +0000
@@ -814,6 +814,8 @@
 (declare-function gnus-configure-windows "gnus-win" (setting &optional force))
 (defvar mailcap-mime-extensions)	; mailcap-mime-info autoloads
 
+(defvar write-point)
+
 (defun mm-display-external (handle method)
   "Display HANDLE using METHOD."
   (let ((outbuf (current-buffer)))
@@ -950,9 +952,33 @@
 			    method file (mm-handle-type handle))))
 	      (unwind-protect
 		  (progn
+		    (setq buffer (generate-new-buffer " *mm*"))
+		    (let (wp)
+		      (with-current-buffer outbuf
+			(let ((point (point)))
+			  (forward-line 2)
+			  (setq wp (point))
+			  (goto-char point)))
+		      (with-current-buffer buffer
+			(set (make-local-variable 'write-point) wp)
+			(set (make-local-variable 'after-change-functions)
+			     `((lambda (st nd len)
+				 (when (buffer-live-p ,outbuf)
+				   (let (wp text)
+				     (with-current-buffer ,buffer
+				       (setq wp write-point
+					     text (buffer-substring st nd)
+					     write-point (+ wp (- nd st))))
+				     (with-current-buffer ,outbuf
+				       (let ((buffer-read-only nil)
+					     (point (point)))
+					 (goto-char wp)
+					 (mm-insert-inline
+					  ',handle (with-current-buffer ,buffer
+						     (buffer-substring st nd)))
+					 (goto-char point))))))))))
 		    (start-process "*display*"
-				   (setq buffer
-					 (generate-new-buffer " *mm*"))
+				   buffer
 				   shell-file-name
 				   shell-command-switch command)
 		    (set-process-sentinel
@@ -977,15 +1003,6 @@
 			   (condition-case nil
 			       (delete-directory (file-name-directory file))
 			     (error))
-			   (when (buffer-live-p outbuf)
-			     (with-current-buffer outbuf
-			       (let ((buffer-read-only nil)
-				     (point (point)))
-				 (forward-line 2)
-				 (mm-insert-inline
-				  handle (with-current-buffer buffer
-					   (buffer-string)))
-				 (goto-char point))))
 			   (when (buffer-live-p buffer)
 			     (kill-buffer buffer)))
 			 (message "Displaying %s...done" command)))))

Re: External viewer output inserted into Article buffer

[Tassilo Horn]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>> Now when I close the evince instance that was opened from within
>>> gnus, that warning is inserted into the Article buffer.
>>>
>>> It's just a viewing issue.  When opening the article again, the
>>> fontconfig warnings aren't there anymore.
>
>> I see the same problem, but with attached pictures and the feh
>> viewer.  Seems to be a general problem.
>
> This is a feature Lars added:
>
> 2012-02-09  Lars Ingebrigtsen  <larsi@gnus.org>
>  * mm-decode.el (mm-display-external): Output the text from the command
>  in the buffer after the command finished.  This makes text-based
>  commands behave better.

Ah, ok.  So if I'd use "pdftotext %f -" as application for the
application/pdf mime type, the clicking on the attachment would insert
its plain-text contents into the buffer.  Indeed, that's a cool feature.

> If you want those warnings to appear in the article buffer without
> waiting for finishing of a command, something like a quick hack
> attached below will help.

No, no.  I was just amazed that there's anything inserted into the
article buffer, no matter at what point in time.

> Otherwise, if you want certain kinds of text not to appear, I have no
> idea how to distinguish whether it's a warning or whether a command is
> used for text-output.

Can't we simply assume that meaningful text-output arrives at stdout and
warnings appear at stderr?

At least

  $ pdftotext foo.pdf - 2> /dev/null

shows the pdf contents, whereas

  $ evinge foo.pdf 2> /dev/null

outputs nothing, i.e., its warnings are redirected to /dev/null.

Maybe there should be an option if one wants to ignore standard error
output, though.

Oh, and maybe the output inserted into the article buffer should be
somewhat outstanding, e.g., fontify it with some special face.  If it
had been fontified with something different than 'default, I'd
immediately seen that it is a feature and not a bug. :-)

Bye,
Tassilo

Re: External viewer output inserted into Article buffer

[Lars Magne Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> Can't we simply assume that meaningful text-output arrives at stdout and
> warnings appear at stderr?
>
> At least
>
>   $ pdftotext foo.pdf - 2> /dev/null
>
> shows the pdf contents, whereas
>
>   $ evinge foo.pdf 2> /dev/null
>
> outputs nothing, i.e., its warnings are redirected to /dev/null.
>
> Maybe there should be an option if one wants to ignore standard error
> output, though.

I don't know whether that's warranted.  I think the user wants all the
output from the command, in general.  Some commands are chattier than
they should be, but that's not the norm.

> Oh, and maybe the output inserted into the article buffer should be
> somewhat outstanding, e.g., fontify it with some special face.  If it
> had been fontified with something different than 'default, I'd
> immediately seen that it is a feature and not a bug. :-)

Good idea.  I've now done that in Ma Gnus.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php