unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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