From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.bugs Subject: bug#44338: 27.1; EWW can't download and view pdf Date: Thu, 05 Nov 2020 21:17:22 +0000 Message-ID: <875z6j1p25.fsf@tcd.ie> References: <878sbmo6i0.fsf@tcd.ie> <83tuu5b1oh.fsf@gnu.org> <837dqzc42r.fsf@gnu.org> <83sg9najmh.fsf@gnu.org> <83h7q3adsh.fsf@gnu.org> <87lfff39rc.fsf@tcd.ie> <83eel7a9we.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32788"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 44338@debbugs.gnu.org, nicholasharrison222@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 05 22:18:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kame3-0008MJ-Aa for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Nov 2020 22:18:11 +0100 Original-Received: from localhost ([::1]:59008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kame1-00010C-Q7 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Nov 2020 16:18:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53178) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kamdu-000104-8H for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2020 16:18:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42760) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kamdt-0004pv-Us for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2020 16:18:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kamdt-0006i4-Pt for bug-gnu-emacs@gnu.org; Thu, 05 Nov 2020 16:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Nov 2020 21:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44338 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 44338-submit@debbugs.gnu.org id=B44338.160461106725771 (code B ref 44338); Thu, 05 Nov 2020 21:18:01 +0000 Original-Received: (at 44338) by debbugs.gnu.org; 5 Nov 2020 21:17:47 +0000 Original-Received: from localhost ([127.0.0.1]:54306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kamdP-0006hK-RT for submit@debbugs.gnu.org; Thu, 05 Nov 2020 16:17:46 -0500 Original-Received: from mail-wr1-f44.google.com ([209.85.221.44]:40640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kamdO-0006h8-4z for 44338@debbugs.gnu.org; Thu, 05 Nov 2020 16:17:30 -0500 Original-Received: by mail-wr1-f44.google.com with SMTP id 33so3383573wrl.7 for <44338@debbugs.gnu.org>; Thu, 05 Nov 2020 13:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=5hOVqqq/F7RGPkM9uqSt6Iz9Bwjg+ofwm3kLpf/FUE8=; b=WHdepJlXDu9ZMYqz+mqjgiwu9V8RiKs5VhnLWD9CD3yGgRn2H++1M3UgO3ESMn8B3y YYk6NSbXrkvYpCjUXpbk8ZtVrsZ4sxPrprEERvuKcQiPdb4DMtYFO+6h9MyP0D29xgQ9 IwXyu8Igo9dHNFG9VQqFke57RkGBxkP3JzBv7JrhIl3/uiy9YNSGQ0wMkKDaJYaQtMaK 38ZwOlqw/uuRieFyCX4z5ArFj5RdcMtUm/NmPinfBd7AnyXU9qmfFZf4pY7AghBFvHue UaT3OauCXzahHtsOjeu5WJcQ+F/UIhLRNEBRglWMYHstv2w6Br7sGAnIj9tQlG8qno2f bAFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=5hOVqqq/F7RGPkM9uqSt6Iz9Bwjg+ofwm3kLpf/FUE8=; b=HUrXlUum2goYdrJyJdxI6ML8m6Zmj+3N8bj9aUbyqTYAEJo7fdcStQutlKM4Icjn5h RIY7fFxmBjBi2p/yzXCjR+Rwl3Chi6fXr4PFc485knRCReRqLWLUpVhoZic9SaPrQleN o8Zl9neabaIuI075q1WkkEskxmmJtUwjf1tmr52DuDaoxkv8ccF/fkM8OB9IwO6VpF3L KSCenxLyynGzQl/zUvq/oFCHyOlCVeRbwvpnucAKGkZUT1m9brNqC+o/d8L0lR/Z1oZY ISlPKgQJ/960+PWlEDKQ3rd/yAcGr54YBKBtlnEaAk7bwK29p8AxzWuM/fgJuwCdh5a+ cIVw== X-Gm-Message-State: AOAM532Z1oITMih8ieZdcWbDRw9aJBnz5MiwUBn3gCwjAA89unh/nR73 8IZXcckB0+raVp1DqPnZXBMNxA== X-Google-Smtp-Source: ABdhPJym+VQN1W20NonVgNEKM6B/JgFW7uWiCV47vA0o6DDqF7pekPNWsN30M2BRF1J7ElcM7qDchA== X-Received: by 2002:a05:6000:108:: with SMTP id o8mr5097062wrx.256.1604611044196; Thu, 05 Nov 2020 13:17:24 -0800 (PST) Original-Received: from localhost ([2a02:8084:20e2:c380:92bd:1bfd:38fc:fae2]) by smtp.gmail.com with ESMTPSA id u16sm4308848wrn.55.2020.11.05.13.17.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Nov 2020 13:17:23 -0800 (PST) In-Reply-To: <83eel7a9we.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Nov 2020 21:20:01 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192756 Archived-At: Eli Zaretskii writes: >> From: "Basil L. Contovounesios" >> Cc: Nicholas Harrison , 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