bug#44338: 27.1; EWW can't download and view pdf

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Nicholas Harrison <nicholasharrison222@gmail.com>,  44338@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.