GNU bug report logs - #44338
27.1; EWW can't download and view pdf

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 44338 <at> debbugs.gnu.org, nicholasharrison222 <at> gmail.com
Subject: bug#44338: 27.1; EWW can't download and view pdf
Date: Thu, 05 Nov 2020 21:20:01 +0200

> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Cc: Nicholas Harrison <nicholasharrison222 <at> gmail.com>,  44338 <at> debbugs.gnu.org
> Date: Thu, 05 Nov 2020 19:04:55 +0000
> 
> > Great, then the change Basil already made locally will also solve the
> > last part of the problem.
> 
> The change is no longer local, which prompted some off-list comments
> from Stefan that confused me.
> 
> mailcap-view-mime already binds coding-system-for-write to 'binary
> before writing to a file and spawning a subshell, so why does the
> coding-system-for-write matter in its caller eww-display-pdf?

I don't think this part of mailcap-view-mime matters in this case:

  (defun mailcap-view-mime (type)
    "View the data in the current buffer that has MIME type TYPE.
  `mailcap--computed-mime-data' determines the method to use."
    (let ((method (mailcap-mime-info type)))
      (if (stringp method)
	  (let ((file (make-temp-file "emacs-mailcap" nil
				      (cadr (split-string type "/")))))
	    (unwind-protect
		(let ((coding-system-for-write 'binary))
		  (write-region (point-min) (point-max) file nil 'silent)
		  (delete-region (point-min) (point-max))
		  (shell-command (format method file)))
	      (when (file-exists-p file)
		(delete-file file))))
	(funcall method))))

As you see, mailcap-view-mime only binds coding-system-for-write if
mailcap-mime-info returns a string, which should then be a shell
command.  But in our case, mailcap-mime-info returns doc-view-mode, a
symbol of a function, and in that case mailcap-mime-info just calls
the function.

That said, I don't think I understand well enough what exactly
happened in the problematic case, because I didn't succeed in getting
a backtrace which matched the problem description.  So the above is
based on some looking into a crystal ball, and thus might be wrong.

> In other words, can we remove the binding altogether from
> eww-display-pdf and make the *eww pdf* buffer unibyte, as Stefan
> suggested?

If we want to remove the binding from eww-display-pdf, it should go to
doc-view-mode, because only it knows what it needs.  mailcap-view-mime
is right not to do anything when it calls the function, since it
cannot know what that function will or will not do.

Please also note that doc-view-mode expects to be called on a unibyte
buffer with 'no-conversion' as its buffer-file-coding-system, because
we have ("\\.pdf\\'" . no-conversion) in auto-coding-alist.  So an
alternative solution would be for eww to arrange for the buffer to be
unibyte; then no binding of coding-system-for-write will be needed.

> Could something funny happen / be happening during insertion from one
> buffer into the other in eww-display-pdf?

In principle, maybe, but I don't see what could happen in the case in
point, given the circumstances.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.