From: Eli Zaretskii <eliz@gnu.org>
To: "Basil L. Contovounesios" <contovob@tcd.ie>
Cc: 44338@debbugs.gnu.org, nicholasharrison222@gmail.com
Subject: bug#44338: 27.1; EWW can't download and view pdf
Date: Thu, 05 Nov 2020 21:20:01 +0200 [thread overview]
Message-ID: <83eel7a9we.fsf@gnu.org> (raw)
In-Reply-To: <87lfff39rc.fsf@tcd.ie> (contovob@tcd.ie)
> 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.
next prev parent reply other threads:[~2020-11-05 19:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 22:20 bug#44338: 27.1; EWW can't download and view pdf Nicholas Harrison
2020-10-31 13:43 ` Basil L. Contovounesios
2020-10-31 16:35 ` Jean Louis
2020-10-31 17:14 ` Nicholas Harrison
2020-10-31 23:16 ` Nicholas Harrison
2020-11-01 14:56 ` Basil L. Contovounesios
2020-11-03 23:24 ` Basil L. Contovounesios
2020-11-05 15:13 ` Lars Ingebrigtsen
2020-11-05 17:37 ` Basil L. Contovounesios
2020-11-01 14:20 ` Lars Ingebrigtsen
2020-11-01 14:59 ` Basil L. Contovounesios
2020-11-02 14:59 ` Lars Ingebrigtsen
2020-11-02 16:50 ` Basil L. Contovounesios
2020-11-03 14:49 ` Lars Ingebrigtsen
2020-11-03 21:28 ` Basil L. Contovounesios
2020-11-05 15:12 ` Lars Ingebrigtsen
2020-11-05 17:36 ` Basil L. Contovounesios
2020-11-05 20:40 ` Basil L. Contovounesios
2020-11-03 23:52 ` Nicholas Harrison
2020-11-04 0:23 ` Basil L. Contovounesios
2020-11-04 1:01 ` Nicholas Harrison
2020-11-04 15:10 ` Eli Zaretskii
2020-11-04 0:25 ` Basil L. Contovounesios
2020-11-04 15:07 ` Eli Zaretskii
2020-11-04 20:01 ` Basil L. Contovounesios
2020-11-04 23:43 ` Nicholas Harrison
2020-11-05 13:42 ` Eli Zaretskii
2020-11-05 13:42 ` Eli Zaretskii
2020-11-05 15:18 ` Nicholas Harrison
2020-11-05 15:49 ` Eli Zaretskii
2020-11-05 17:52 ` Nicholas Harrison
2020-11-05 17:55 ` Eli Zaretskii
2020-11-05 19:04 ` Basil L. Contovounesios
2020-11-05 19:20 ` Eli Zaretskii [this message]
2020-11-05 21:17 ` Basil L. Contovounesios
2020-11-06 5:29 ` Eli Zaretskii
2020-11-05 20:40 ` Lars Ingebrigtsen
2020-11-05 21:25 ` Basil L. Contovounesios
2020-11-06 2:12 ` Nicholas Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83eel7a9we.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=44338@debbugs.gnu.org \
--cc=contovob@tcd.ie \
--cc=nicholasharrison222@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).