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

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

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

Right, I got confused between the problem in the OP and my changes for
async shell commands.

I'd also forgotten that doc-view-mode writes non-visiting buffers to a
temporary file.

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

Everyone seems to agree that that's TRT, so I've now done so on master.

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

Me neither, I just thought it might contribute to the snafu on MS
Windows somehow.

Thanks,

-- 
Basil