* bug#44338: 27.1; EWW can't download and view pdf
@ 2020-10-30 22:20 Nicholas Harrison
2020-10-31 13:43 ` Basil L. Contovounesios
0 siblings, 1 reply; 39+ messages in thread
From: Nicholas Harrison @ 2020-10-30 22:20 UTC (permalink / raw)
To: 44338
[-- Attachment #1: Type: text/plain, Size: 4768 bytes --]
Using the EWW browser, I can navigate around to webpages, but navigating
to a pdf fails. It appears to download an unreadable pdf. Downloading
and viewing the pdf manually in emacs (pdf-view-mode) works fine.
I've tried these solutions to no avail:
- Adding "application/pdf; emacsclient %s" to a ~/.mailcap file. This
makes the process hang indefinitely.
- Running the following elisp code:
`(add-to-list 'mailcap-user-mime-data
'((type . "application/pdf")
(viewer . pdf-view-mode)))`
This doesn't seem to have an effect.
--System Info--
In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
of 2020-08-21 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19041
System Description: Microsoft Windows 10 Home (v10.0.2004.19041.572)
Recent messages:
[yas] Prepared just-in-time loading of snippets successfully.
For information about GNU Emacs and the GNU system, type C-h C-a.
Contacting host: www.restek.com:443
error in process filter: mailcap-view-mime: Symbol’s function definition is
void: nil
error in process filter: Symbol’s function definition is void: nil
Making completion list... [2 times]
Configured using:
'configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
Major mode: Fundamental
Minor modes in effect:
pyvenv-mode: t
shell-dirtrack-mode: t
global-linum-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message dired dired-loaddefs rfc822 mml
mml-sec epa derived epg epg-config mm-decode mm-bodies mm-encode
mailabbrev gmm-utils mailheader sendmail gnutls network-stream url-http
mail-parse rfc2231 url-gw nsm rmc url-cache url-auth eww mm-url gnus
nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
mail-utils mm-util mail-prsvr url-queue url url-proxy url-privacy
url-expand url-methods url-history mailcap shr text-property-search
url-cookie url-domsuf url-util puny svg xml dom cl-extra yasnippet
highlight-indentation flymake-proc flymake warnings thingatpt
company-capf company pcase help-fns radix-tree help-mode elpy advice
edmacro kmacro elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt esh-proc
esh-io esh-arg esh-module esh-groups esh-util elpy-shell elpy-profile
elpy-django s elpy-refactor python tramp-sh tramp tramp-loaddefs
trampver tramp-integration tramp-compat shell pcomplete parse-time
iso8601 time-date format-spec ido grep compile comint ansi-color files-x
etags fileloop generator xref project ring cus-edit cus-start cus-load
wid-edit linum material-theme finder-inf package easymenu browse-url
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
lcms2 multi-tty make-network-process emacs)
Memory information:
((conses 16 286983 9790)
(symbols 48 22710 1)
(strings 32 96281 3012)
(string-bytes 1 2696643)
(vectors 16 30701)
(vector-slots 8 394315 14882)
(floats 8 139 245)
(intervals 56 410 0)
(buffers 1000 15))
[-- Attachment #2: Type: text/html, Size: 5170 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
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
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-10-31 13:43 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: 44338
Nicholas Harrison <nicholasharrison222@gmail.com> writes:
> Using the EWW browser, I can navigate around to webpages, but navigating
> to a pdf fails. It appears to download an unreadable pdf. Downloading
> and viewing the pdf manually in emacs (pdf-view-mode) works fine.
>
> I've tried these solutions to no avail:
> - Adding "application/pdf; emacsclient %s" to a ~/.mailcap file. This
> makes the process hang indefinitely.
> - Running the following elisp code:
> `(add-to-list 'mailcap-user-mime-data
> '((type . "application/pdf")
> (viewer . pdf-view-mode)))`
> This doesn't seem to have an effect.
Seems to have been fixed on master:
1. emacs -Q
2. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
3. C-s extra pdf RET RET
This opens the "Specialized Emacs Features" manual in a *eww pdf* buffer
in doc-view-mode.
With PDF Tools and the mailcap-user-mime-data setting above installed,
it opens in pdf-view-mode instead.
I'm surprised the setting for mailcap-user-mime-data is needed though,
since pdf-view-mode appears before doc-view-mode in both
mailcap-mime-data and my version of auto-mode-alist.
Lars?
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 13:43 ` Basil L. Contovounesios
@ 2020-10-31 16:35 ` Jean Louis
2020-10-31 17:14 ` Nicholas Harrison
2020-11-03 23:24 ` Basil L. Contovounesios
2020-11-01 14:20 ` Lars Ingebrigtsen
2020-11-03 23:52 ` Nicholas Harrison
2 siblings, 2 replies; 39+ messages in thread
From: Jean Louis @ 2020-10-31 16:35 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison
* Basil L. Contovounesios <contovob@tcd.ie> [2020-10-31 16:45]:
> Nicholas Harrison <nicholasharrison222@gmail.com> writes:
>
> > Using the EWW browser, I can navigate around to webpages, but navigating
> > to a pdf fails. It appears to download an unreadable pdf. Downloading
> > and viewing the pdf manually in emacs (pdf-view-mode) works fine.
> >
> > I've tried these solutions to no avail:
> > - Adding "application/pdf; emacsclient %s" to a ~/.mailcap file. This
> > makes the process hang indefinitely.
> > - Running the following elisp code:
> > `(add-to-list 'mailcap-user-mime-data
> > '((type . "application/pdf")
> > (viewer . pdf-view-mode)))`
> > This doesn't seem to have an effect.
>
> Seems to have been fixed on master:
>
> 1. emacs -Q
> 2. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
> 3. C-s extra pdf RET RET
When external editor is used, buffer for eww pdf remains there in
background *eww pdf* and neither l or q key bindings work, it would be
expected to go back to the previous page from that buffer.
--
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 16:35 ` Jean Louis
@ 2020-10-31 17:14 ` Nicholas Harrison
2020-10-31 23:16 ` Nicholas Harrison
2020-11-03 23:24 ` Basil L. Contovounesios
1 sibling, 1 reply; 39+ messages in thread
From: Nicholas Harrison @ 2020-10-31 17:14 UTC (permalink / raw)
To: Jean Louis; +Cc: Basil L. Contovounesios, 44338
[-- Attachment #1.1: Type: text/plain, Size: 1601 bytes --]
This is what I get after following those steps:
[image: image.png]
These errors still show in the Messages:
error in process filter: mailcap-view-mime: Symbol’s function definition is
void: nil
error in process filter: Symbol’s function definition is void: nil
Nicholas
On Sat, Oct 31, 2020 at 10:35 AM Jean Louis <bugs@gnu.support> wrote:
> * Basil L. Contovounesios <contovob@tcd.ie> [2020-10-31 16:45]:
> > Nicholas Harrison <nicholasharrison222@gmail.com> writes:
> >
> > > Using the EWW browser, I can navigate around to webpages, but
> navigating
> > > to a pdf fails. It appears to download an unreadable pdf. Downloading
> > > and viewing the pdf manually in emacs (pdf-view-mode) works fine.
> > >
> > > I've tried these solutions to no avail:
> > > - Adding "application/pdf; emacsclient %s" to a ~/.mailcap file. This
> > > makes the process hang indefinitely.
> > > - Running the following elisp code:
> > > `(add-to-list 'mailcap-user-mime-data
> > > '((type . "application/pdf")
> > > (viewer . pdf-view-mode)))`
> > > This doesn't seem to have an effect.
> >
> > Seems to have been fixed on master:
> >
> > 1. emacs -Q
> > 2. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
> > 3. C-s extra pdf RET RET
>
> When external editor is used, buffer for eww pdf remains there in
> background *eww pdf* and neither l or q key bindings work, it would be
> expected to go back to the previous page from that buffer.
>
>
> --
> Thanks,
> Jean Louis
> ⎔ λ 🄯 𝍄 𝌡 𝌚
>
[-- Attachment #1.2: Type: text/html, Size: 2420 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 75450 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 17:14 ` Nicholas Harrison
@ 2020-10-31 23:16 ` Nicholas Harrison
2020-11-01 14:56 ` Basil L. Contovounesios
0 siblings, 1 reply; 39+ messages in thread
From: Nicholas Harrison @ 2020-10-31 23:16 UTC (permalink / raw)
To: Jean Louis; +Cc: Basil L. Contovounesios, 44338
[-- Attachment #1.1: Type: text/plain, Size: 1842 bytes --]
If it was fixed on master, can you tell me which commit fixed it?
Thanks,
Nicholas
On Sat, Oct 31, 2020 at 11:14 AM Nicholas Harrison <
nicholasharrison222@gmail.com> wrote:
> This is what I get after following those steps:
> [image: image.png]
>
> These errors still show in the Messages:
> error in process filter: mailcap-view-mime: Symbol’s function definition
> is void: nil
> error in process filter: Symbol’s function definition is void: nil
>
> Nicholas
>
> On Sat, Oct 31, 2020 at 10:35 AM Jean Louis <bugs@gnu.support> wrote:
>
>> * Basil L. Contovounesios <contovob@tcd.ie> [2020-10-31 16:45]:
>> > Nicholas Harrison <nicholasharrison222@gmail.com> writes:
>> >
>> > > Using the EWW browser, I can navigate around to webpages, but
>> navigating
>> > > to a pdf fails. It appears to download an unreadable pdf. Downloading
>> > > and viewing the pdf manually in emacs (pdf-view-mode) works fine.
>> > >
>> > > I've tried these solutions to no avail:
>> > > - Adding "application/pdf; emacsclient %s" to a ~/.mailcap file. This
>> > > makes the process hang indefinitely.
>> > > - Running the following elisp code:
>> > > `(add-to-list 'mailcap-user-mime-data
>> > > '((type . "application/pdf")
>> > > (viewer . pdf-view-mode)))`
>> > > This doesn't seem to have an effect.
>> >
>> > Seems to have been fixed on master:
>> >
>> > 1. emacs -Q
>> > 2. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
>> > 3. C-s extra pdf RET RET
>>
>> When external editor is used, buffer for eww pdf remains there in
>> background *eww pdf* and neither l or q key bindings work, it would be
>> expected to go back to the previous page from that buffer.
>>
>>
>> --
>> Thanks,
>> Jean Louis
>> ⎔ λ 🄯 𝍄 𝌡 𝌚
>>
>
[-- Attachment #1.2: Type: text/html, Size: 2919 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 75450 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 13:43 ` Basil L. Contovounesios
2020-10-31 16:35 ` Jean Louis
@ 2020-11-01 14:20 ` Lars Ingebrigtsen
2020-11-01 14:59 ` Basil L. Contovounesios
2020-11-03 23:52 ` Nicholas Harrison
2 siblings, 1 reply; 39+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-01 14:20 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> I'm surprised the setting for mailcap-user-mime-data is needed though,
> since pdf-view-mode appears before doc-view-mode in both
> mailcap-mime-data and my version of auto-mode-alist.
>
> Lars?
Hm... I'm not getting any difference whether the add-to-list has been
done or not? But I don't have pdf-view-mode installed here, I think.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 23:16 ` Nicholas Harrison
@ 2020-11-01 14:56 ` Basil L. Contovounesios
0 siblings, 0 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-01 14:56 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: 44338
Nicholas Harrison <nicholasharrison222@gmail.com> writes:
> If it was fixed on master, can you tell me which commit fixed it?
I don't know, but the following are some potential candidates.
Try to fix mailcap parsing again to respect Emacs defaults
eab636c7eb 2020-08-02 09:04:31 +0200
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=eab636c7eb25c4e1cbfeb0fc48cc1274e1c55222
Fix viewing PDFs from eww with external viewers
a34a80a878 2020-09-11 14:06:07 +0200
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a34a80a878f37832cc5e59f2c26ea1779eca5cf8
Tweak previous mailcap patch (for external viewers)
bde93182bf 2020-09-11 15:37:00 +0200
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bde93182bf07251f66d571d9667a6c21b6af1930
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-01 14:20 ` Lars Ingebrigtsen
@ 2020-11-01 14:59 ` Basil L. Contovounesios
2020-11-02 14:59 ` Lars Ingebrigtsen
0 siblings, 1 reply; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-01 14:59 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
Lars Ingebrigtsen <larsi@gnus.org> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> I'm surprised the setting for mailcap-user-mime-data is needed though,
>> since pdf-view-mode appears before doc-view-mode in both
>> mailcap-mime-data and my version of auto-mode-alist.
>>
>> Lars?
>
> Hm... I'm not getting any difference whether the add-to-list has been
> done or not? But I don't have pdf-view-mode installed here, I think.
Right, I'm only talking about the case when pdf-view-mode (from the
pdf-tools package on MELPA) is installed.
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-01 14:59 ` Basil L. Contovounesios
@ 2020-11-02 14:59 ` Lars Ingebrigtsen
2020-11-02 16:50 ` Basil L. Contovounesios
0 siblings, 1 reply; 39+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-02 14:59 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Right, I'm only talking about the case when pdf-view-mode (from the
> pdf-tools package on MELPA) is installed.
Just to check -- you didn't install pdf-view-mode between the first and
second test, by any chance? Then that would explain why it started
working with the seemingly superfluous add-to-list...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-02 14:59 ` Lars Ingebrigtsen
@ 2020-11-02 16:50 ` Basil L. Contovounesios
2020-11-03 14:49 ` Lars Ingebrigtsen
0 siblings, 1 reply; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-02 16:50 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
Lars Ingebrigtsen <larsi@gnus.org> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Right, I'm only talking about the case when pdf-view-mode (from the
>> pdf-tools package on MELPA) is installed.
>
> Just to check -- you didn't install pdf-view-mode between the first and
> second test, by any chance? Then that would explain why it started
> working with the seemingly superfluous add-to-list...
Here's what I'm doing, with the pdf-tools package already installed
under package-user-dir:
0. emacs -Q
1. M-x package-initialize RET
2. M-x pdf-tools-install RET
(this autoloads pdf-view-mode, registers it on auto-mode-alist, etc.)
3. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
4. C-s extra pdf RET RET
This uses doc-view-mode, whereas C-x C-f path/to/pdf RET uses
pdf-view-mode.
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-02 16:50 ` Basil L. Contovounesios
@ 2020-11-03 14:49 ` Lars Ingebrigtsen
2020-11-03 21:28 ` Basil L. Contovounesios
0 siblings, 1 reply; 39+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-03 14:49 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Here's what I'm doing, with the pdf-tools package already installed
> under package-user-dir:
>
> 0. emacs -Q
> 1. M-x package-initialize RET
> 2. M-x pdf-tools-install RET
> (this autoloads pdf-view-mode, registers it on auto-mode-alist, etc.)
> 3. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
> 4. C-s extra pdf RET RET
>
> This uses doc-view-mode, whereas C-x C-f path/to/pdf RET uses
> pdf-view-mode.
Thanks for the recipe; I'm seeing this bug, too.
(pp mailcap--computed-mime-data (current-buffer))
=>
("pdf"
(viewer . doc-view-mode)
(type . "application/pdf")
(test . window-system))
("pdf"
(viewer . pdf-view-mode)
(type . "application/pdf")
(test . window-system))
So doc-view-mode is ahead of pdf-view-mode in the computed structure...
Ah; mailcap-mime-data entries are handled in opposite order -- the final
matching entry is the one that wins, not the first one? Looks like it.
I've now noted this in the doc string, and I've also moved pdf-view-mode
later, because it makes sense to prefer that if it's installed (since
doc-view-mode is build in.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-03 14:49 ` Lars Ingebrigtsen
@ 2020-11-03 21:28 ` Basil L. Contovounesios
2020-11-05 15:12 ` Lars Ingebrigtsen
0 siblings, 1 reply; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-03 21:28 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
Lars Ingebrigtsen <larsi@gnus.org> writes:
> (pp mailcap--computed-mime-data (current-buffer))
> =>
>
> ("pdf"
> (viewer . doc-view-mode)
> (type . "application/pdf")
> (test . window-system))
> ("pdf"
> (viewer . pdf-view-mode)
> (type . "application/pdf")
> (test . window-system))
>
> So doc-view-mode is ahead of pdf-view-mode in the computed structure...
>
> Ah; mailcap-mime-data entries are handled in opposite order -- the final
> matching entry is the one that wins, not the first one? Looks like it.
Yes, mailcap--computed-mime-data is in reverse order w.r.t. both major
and minor mime types.
> I've now noted this in the doc string, and I've also moved pdf-view-mode
> later, because it makes sense to prefer that if it's installed (since
> doc-view-mode is build in.
Alternatively, mailcap--computed-mime-data could be kept in canonical
order, e.g. in mailcap-add-mailcap-entry?
[BTW, I don't see the function mailcap-add used anywhere.]
[And neither do I see your changes on Savannah. ;]
Thanks,
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 16:35 ` Jean Louis
2020-10-31 17:14 ` Nicholas Harrison
@ 2020-11-03 23:24 ` Basil L. Contovounesios
2020-11-05 15:13 ` Lars Ingebrigtsen
1 sibling, 1 reply; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-03 23:24 UTC (permalink / raw)
To: Jean Louis, Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
[-- Attachment #1: Type: text/plain, Size: 475 bytes --]
Jean Louis <bugs@gnu.support> writes:
> When external editor is used, buffer for eww pdf remains there in
> background *eww pdf* and neither l or q key bindings work, it would be
> expected to go back to the previous page from that buffer.
Indeed, popping to an empty *eww pdf* buffer when using an external
viewer is suboptimal. Even less optimal is that external viewers are
called synchronously, so Emacs cannot be used simultaneously.
How's the attached?
--
Basil
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-eww-support-for-externally-viewed-PDFs.patch --]
[-- Type: text/x-diff, Size: 4572 bytes --]
From 4595e0f159fffc93fc5be750478e52db4885d373 Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Tue, 3 Nov 2020 22:54:34 +0000
Subject: [PATCH] Improve eww support for externally viewed PDFs
The *eww pdf* buffer is only needed when viewing PDFs within Emacs,
e.g., with doc-view-mode. External PDF viewers are called with a
temporary file, so the buffer is not needed in that case. What's
more, mailcap-view-mime erased the buffer and left it in
fundamental-mode until now, so the user was left staring at a
useless, empty buffer. To make things even worse, external viewers
were invoked synchronously until now, so the user could not browse
the PDF file and use Emacs simultaneously.
* lisp/net/mailcap.el (mailcap--async-shell): New function.
(mailcap-view-mime): Use it to invoke external viewers
asynchronously. Mention erasure of current buffer in that case in
docstring. Add a period between the temporary file name and its
extension.
* lisp/net/eww.el (eww-display-pdf): Pop to *eww pdf* buffer only if
it is used for displaying a document; otherwise kill it (bug#44338).
Simplify buffer-substring+insert as insert-buffer-substring.
---
lisp/net/eww.el | 21 +++++++++++++--------
lisp/net/mailcap.el | 30 ++++++++++++++++++++----------
2 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index ebc75e0e8a..e9763ef6df 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -811,14 +811,19 @@ eww-display-image
(declare-function mailcap-view-mime "mailcap" (type))
(defun eww-display-pdf ()
- (let ((data (buffer-substring (point) (point-max))))
- (pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
- (let ((coding-system-for-write 'raw-text)
- (inhibit-read-only t))
- (erase-buffer)
- (insert data)
- (mailcap-view-mime "application/pdf")))
- (goto-char (point-min)))
+ (let ((buf (current-buffer))
+ (pos (point)))
+ (with-current-buffer (get-buffer-create "*eww pdf*")
+ (let ((coding-system-for-write 'raw-text)
+ (inhibit-read-only t))
+ (erase-buffer)
+ (insert-buffer-substring buf pos)
+ (mailcap-view-mime "application/pdf"))
+ (if (zerop (buffer-size))
+ ;; Buffer contents passed to shell command via temporary file.
+ (kill-buffer)
+ (goto-char (point-min))
+ (pop-to-buffer-same-window (current-buffer))))))
(defun eww-setup-buffer ()
(when (or (plist-get eww-data :url)
diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
index 94cd9e2156..ad715c4b0e 100644
--- a/lisp/net/mailcap.el
+++ b/lisp/net/mailcap.el
@@ -1128,20 +1128,30 @@ mailcap-file-default-commands
res)))
(nreverse res)))))
+(defun mailcap--async-shell (command file)
+ "Asynchronously call MIME viewer shell COMMAND.
+Replace %s in COMMAND with FILE, as per `mailcap-mime-data'.
+Delete FILE once COMMAND exits."
+ (let ((buf (get-buffer-create " *mailcap shell*")))
+ (async-shell-command (format command file) buf)
+ (add-function :after (process-sentinel (get-buffer-process buf))
+ (lambda (proc _msg)
+ (when (memq (process-status proc) '(exit signal))
+ (delete-file file))))))
+
(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."
+The variable `mailcap--computed-mime-data' determines the method
+to use. If the method is a shell command string, erase the
+current buffer after passing its contents to the shell command."
(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))))
+ (let* ((ext (concat "." (cadr (split-string type "/"))))
+ (file (make-temp-file "emacs-mailcap" nil ext))
+ (coding-system-for-write 'binary))
+ (write-region nil nil file nil 'silent)
+ (delete-region (point-min) (point-max))
+ (mailcap--async-shell method file))
(funcall method))))
(provide 'mailcap)
--
2.28.0
^ permalink raw reply related [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-10-31 13:43 ` Basil L. Contovounesios
2020-10-31 16:35 ` Jean Louis
2020-11-01 14:20 ` Lars Ingebrigtsen
@ 2020-11-03 23:52 ` Nicholas Harrison
2020-11-04 0:23 ` Basil L. Contovounesios
` (2 more replies)
2 siblings, 3 replies; 39+ messages in thread
From: Nicholas Harrison @ 2020-11-03 23:52 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338
[-- Attachment #1.1: Type: text/plain, Size: 2705 bytes --]
I'll make a couple more comments on the original problem I explained. It
looks like you may have identified additional improvements in the process.
I believe the first problem for me is that both mailcap-mime-data
and mailcap-user-mime-data are nil. This causes the `error in process
filter: mailcap-view-mime: Symbol’s function definition is void: nil` and
makes the pdf download and appear in Fundamental mode. This occurs whether
I will be using doc-view-mode or pdf-view-mode. I'll use DocView for the
rest of this example.
1. emacs -Q
2. M-x eww
3. https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf
This results in the error message and the following:
[image: image.png]
This can be (partially) corrected by running the following code before the
steps 2 and 3:
(add-to-list 'mailcap-user-mime-data
'((type . "application/pdf")
(viewer . doc-view-mode)))
This chooses a view mode for the pdf but that brings the second problem.
This selects the default encoding of raw-text and the conversion fails:
[image: image.png]
Instead I choose doc-view-mode manually for the eww pdf buffer:
[image: image.png]
Then selecting binary for the encoding finally gets a viewable pdf:
[image: image.png]
I hope this is in some way helpful.
Nicholas
On Sat, Oct 31, 2020 at 7:43 AM Basil L. Contovounesios <contovob@tcd.ie>
wrote:
> Nicholas Harrison <nicholasharrison222@gmail.com> writes:
>
> > Using the EWW browser, I can navigate around to webpages, but navigating
> > to a pdf fails. It appears to download an unreadable pdf. Downloading
> > and viewing the pdf manually in emacs (pdf-view-mode) works fine.
> >
> > I've tried these solutions to no avail:
> > - Adding "application/pdf; emacsclient %s" to a ~/.mailcap file. This
> > makes the process hang indefinitely.
> > - Running the following elisp code:
> > `(add-to-list 'mailcap-user-mime-data
> > '((type . "application/pdf")
> > (viewer . pdf-view-mode)))`
> > This doesn't seem to have an effect.
>
> Seems to have been fixed on master:
>
> 1. emacs -Q
> 2. M-x eww RET https://www.gnu.org/software/emacs/manual/emacs.html RET
> 3. C-s extra pdf RET RET
>
> This opens the "Specialized Emacs Features" manual in a *eww pdf* buffer
> in doc-view-mode.
>
> With PDF Tools and the mailcap-user-mime-data setting above installed,
> it opens in pdf-view-mode instead.
>
> I'm surprised the setting for mailcap-user-mime-data is needed though,
> since pdf-view-mode appears before doc-view-mode in both
> mailcap-mime-data and my version of auto-mode-alist.
>
> Lars?
>
> --
> Basil
>
[-- Attachment #1.2: Type: text/html, Size: 3921 bytes --]
[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 73558 bytes --]
[-- Attachment #3: image.png --]
[-- Type: image/png, Size: 93307 bytes --]
[-- Attachment #4: image.png --]
[-- Type: image/png, Size: 37758 bytes --]
[-- Attachment #5: image.png --]
[-- Type: image/png, Size: 38711 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
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
2 siblings, 2 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-04 0:23 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: 44338
Nicholas Harrison <nicholasharrison222@gmail.com> writes:
> I'll make a couple more comments on the original problem I
> explained. It looks like you may have identified additional
> improvements in the process.
>
> I believe the first problem for me is that both mailcap-mime-data and
> mailcap-user-mime-data are nil. This causes the `error in process
> filter: mailcap-view-mime: Symbol’s function definition is void: nil`
> and makes the pdf download and appear in Fundamental mode. This occurs
> whether I will be using doc-view-mode or pdf-view-mode. I'll use
> DocView for the rest of this example.
>
> 1. emacs -Q
> 2. M-x eww
> 3. https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf
>
> This results in the error message and the following:
> image.png
>
> This can be (partially) corrected by running the following code before the steps 2 and 3:
> (add-to-list 'mailcap-user-mime-data
> '((type . "application/pdf")
> (viewer . doc-view-mode)))
>
> This chooses a view mode for the pdf but that brings the second
> problem. This selects the default encoding of raw-text and the
> conversion fails:
>
> Instead I choose doc-view-mode manually for the eww pdf buffer:
>
> Then selecting binary for the encoding finally gets a viewable pdf:
>
> I hope this is in some way helpful.
Thanks. I cannot reproduce these on what will be Emacs 27.2 or Emacs
28.1 on GNU/Linux. Perhaps they have been fixed already, or are
specific to MS Windows. If someone on MS Windows could check whether
they still occur on master and emacs-27, that would be helpful.
--
Basil
In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
of 2020-11-03 built on thunk
Repository revision: f9d6e463d310db0e1931f26609d938531c56f9c3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid
Configured using:
'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
--prefix=/home/blc/.local --with-x-toolkit=lucid
--with-file-notification=yes --with-x'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT
LIBOTF ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD JSON PDUMPER LCMS2
Important settings:
value of $LANG: en_IE.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 51798 5028)
(symbols 48 6742 1)
(strings 32 18899 1840)
(string-bytes 1 612322)
(vectors 16 12192)
(vector-slots 8 168066 8842)
(floats 8 23 45)
(intervals 56 221 0)
(buffers 992 10))
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-03 23:52 ` Nicholas Harrison
2020-11-04 0:23 ` Basil L. Contovounesios
@ 2020-11-04 0:25 ` Basil L. Contovounesios
2020-11-04 15:07 ` Eli Zaretskii
2 siblings, 0 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-04 0:25 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: 44338
Nicholas Harrison <nicholasharrison222@gmail.com> writes:
> I believe the first problem for me is that both mailcap-mime-data and
> mailcap-user-mime-data are nil.
I forgot to say that the former is probably due to
https://debbugs.gnu.org/40247.
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-04 0:23 ` Basil L. Contovounesios
@ 2020-11-04 1:01 ` Nicholas Harrison
2020-11-04 15:10 ` Eli Zaretskii
1 sibling, 0 replies; 39+ messages in thread
From: Nicholas Harrison @ 2020-11-04 1:01 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338
[-- Attachment #1: Type: text/plain, Size: 5316 bytes --]
In WSL on 27.1 the mailcap-mime-data problem remains, but past that the
conversion when doc-view-mode is enabled works with both binary and the
default raw-text.
On Tue, Nov 3, 2020 at 5:23 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:
> Nicholas Harrison <nicholasharrison222@gmail.com> writes:
>
> > I'll make a couple more comments on the original problem I
> > explained. It looks like you may have identified additional
> > improvements in the process.
> >
> > I believe the first problem for me is that both mailcap-mime-data and
> > mailcap-user-mime-data are nil. This causes the `error in process
> > filter: mailcap-view-mime: Symbol’s function definition is void: nil`
> > and makes the pdf download and appear in Fundamental mode. This occurs
> > whether I will be using doc-view-mode or pdf-view-mode. I'll use
> > DocView for the rest of this example.
> >
> > 1. emacs -Q
> > 2. M-x eww
> > 3. https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf
> >
> > This results in the error message and the following:
> > image.png
> >
> > This can be (partially) corrected by running the following code before
> the steps 2 and 3:
> > (add-to-list 'mailcap-user-mime-data
> > '((type . "application/pdf")
> > (viewer . doc-view-mode)))
> >
> > This chooses a view mode for the pdf but that brings the second
> > problem. This selects the default encoding of raw-text and the
> > conversion fails:
> >
> > Instead I choose doc-view-mode manually for the eww pdf buffer:
> >
> > Then selecting binary for the encoding finally gets a viewable pdf:
> >
> > I hope this is in some way helpful.
>
> Thanks. I cannot reproduce these on what will be Emacs 27.2 or Emacs
> 28.1 on GNU/Linux. Perhaps they have been fixed already, or are
> specific to MS Windows. If someone on MS Windows could check whether
> they still occur on master and emacs-27, that would be helpful.
>
> --
> Basil
>
> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
> version 1.16.0, Xaw3d scroll bars)
> of 2020-11-03 built on thunk
> Repository revision: f9d6e463d310db0e1931f26609d938531c56f9c3
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
> System Description: Debian GNU/Linux bullseye/sid
>
> Configured using:
> 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
> --prefix=/home/blc/.local --with-x-toolkit=lucid
> --with-file-notification=yes --with-x'
>
> Configured features:
> XAW3D XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB
> NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT
> LIBOTF ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
> LIBSYSTEMD JSON PDUMPER LCMS2
>
> Important settings:
> value of $LANG: en_IE.UTF-8
> value of $XMODIFIERS: @im=ibus
> locale-coding-system: utf-8-unix
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
> tooltip-mode: t
> global-eldoc-mode: t
> eldoc-mode: t
> electric-indent-mode: t
> mouse-wheel-mode: t
> tool-bar-mode: t
> menu-bar-mode: t
> file-name-shadow-mode: t
> global-font-lock-mode: t
> font-lock-mode: t
> blink-cursor-mode: t
> auto-composition-mode: t
> auto-encryption-mode: t
> auto-compression-mode: t
> line-number-mode: t
> transient-mark-mode: t
>
> Load-path shadows:
> None found.
>
> Features:
> (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
> rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
> rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
> eieio-loaddefs password-cache json map text-property-search time-date
> subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
> mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
> cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
> tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
> mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
> regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
> lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
> timer select scroll-bar mouse jit-lock font-lock syntax facemenu
> font-core term/tty-colors frame minibuffer cl-generic cham georgian
> utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
> japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
> ethiopic indian cyrillic chinese composite charscript charprop
> case-table epa-hook jka-cmpr-hook help simple abbrev obarray
> cl-preloaded nadvice button loaddefs faces cus-face macroexp files
> window text-properties overlay sha1 md5 base64 format env code-pages
> mule custom widget hashtable-print-readable backquote threads dbusbind
> inotify lcms2 dynamic-setting system-font-setting font-render-setting
> cairo x-toolkit x multi-tty make-network-process emacs)
>
> Memory information:
> ((conses 16 51798 5028)
> (symbols 48 6742 1)
> (strings 32 18899 1840)
> (string-bytes 1 612322)
> (vectors 16 12192)
> (vector-slots 8 168066 8842)
> (floats 8 23 45)
> (intervals 56 221 0)
> (buffers 992 10))
>
[-- Attachment #2: Type: text/html, Size: 6219 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-03 23:52 ` Nicholas Harrison
2020-11-04 0:23 ` Basil L. Contovounesios
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
2 siblings, 2 replies; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-04 15:07 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: contovob, 44338
> From: Nicholas Harrison <nicholasharrison222@gmail.com>
> Date: Tue, 3 Nov 2020 16:52:40 -0700
> Cc: 44338@debbugs.gnu.org
>
> This can be (partially) corrected by running the following code before the steps 2 and 3:
> (add-to-list 'mailcap-user-mime-data
> '((type . "application/pdf")
> (viewer . doc-view-mode)))
>
> This chooses a view mode for the pdf but that brings the second problem. This selects the default encoding
> of raw-text and the conversion fails:
You say it selects raw-text, but the screenshot you sent clearly shows
that Emacs was trying to use iso-latin-1-dos. In which case the
failure is easily understandable, but I don't immediately see where
did that value come from (it's most probably the default value of
buffer-file-coding-system for you, but since eww-display-pdf binds
coding-system-for-write, the question is why that value isn't being
used). Could you perhaps produce a backtrace from that situation?
For example, like this:
M-: (debug-on-entry 'select-safe-coding-system) RET
and then repeat the recipe.
In any case, this isn't right:
(defun eww-display-pdf ()
(let ((data (buffer-substring (point) (point-max))))
(pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
(let ((coding-system-for-write 'raw-text) <<<<<<<<<<<<<<<<<<<<<<
(inhibit-read-only t))
(erase-buffer)
(insert data)
(mailcap-view-mime "application/pdf")))
(goto-char (point-min)))
We should use 'raw-text-unix here, since the buffer contents is a
stream of raw bytes.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-04 0:23 ` Basil L. Contovounesios
2020-11-04 1:01 ` Nicholas Harrison
@ 2020-11-04 15:10 ` Eli Zaretskii
1 sibling, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-04 15:10 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, nicholasharrison222
> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Wed, 04 Nov 2020 00:23:39 +0000
> Cc: 44338@debbugs.gnu.org
>
> Thanks. I cannot reproduce these on what will be Emacs 27.2 or Emacs
> 28.1 on GNU/Linux. Perhaps they have been fixed already, or are
> specific to MS Windows. If someone on MS Windows could check whether
> they still occur on master and emacs-27, that would be helpful.
I asked for a backtrace to see where do we try using Latin-1 to encode
this buffer. Given that information, I think it will be quite easy to
find a solution.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-04 15:07 ` Eli Zaretskii
@ 2020-11-04 20:01 ` Basil L. Contovounesios
2020-11-04 23:43 ` Nicholas Harrison
1 sibling, 0 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-04 20:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44338, Nicholas Harrison
Eli Zaretskii <eliz@gnu.org> writes:
> In any case, this isn't right:
>
> (defun eww-display-pdf ()
> (let ((data (buffer-substring (point) (point-max))))
> (pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
> (let ((coding-system-for-write 'raw-text) <<<<<<<<<<<<<<<<<<<<<<
> (inhibit-read-only t))
> (erase-buffer)
> (insert data)
> (mailcap-view-mime "application/pdf")))
> (goto-char (point-min)))
>
> We should use 'raw-text-unix here, since the buffer contents is a
> stream of raw bytes.
Thanks, I've made the change in my patch, and will push in a few days if
I don't hear otherwise.
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
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
1 sibling, 2 replies; 39+ messages in thread
From: Nicholas Harrison @ 2020-11-04 23:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Basil L. Contovounesios, 44338
[-- Attachment #1: Type: text/plain, Size: 5826 bytes --]
Not sure if this is much help, but here is the backtrace given when I do
the following steps:
1. emacs -Q
2. M-: (debug-on-entry 'select-safe-coding-system) RET
3. M-x eww RET https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf
RET
(no backtrace here)
4. M-x doc-view-mode RET
Debugger entered--entering a function:
* select-safe-coding-system(1 381654 iso-latin-1-dos nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
write-region(nil nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!")
doc-view-mode()
funcall-interactively(doc-view-mode)
call-interactively(doc-view-mode record nil)
command-execute(doc-view-mode record)
execute-extended-command(nil "doc-view-mode" "doc-view-mo")
funcall-interactively(execute-extended-command nil "doc-view-mode"
"doc-view-mo")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
5. ESC ESC ESC
6. RET (it asks to choose an encoding, chose default raw-text)
Debugger entered--returning value: raw-text
select-safe-coding-system(1 381654 iso-latin-1-dos nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww...")
write-region(nil nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww...")
doc-view-mode()
funcall-interactively(doc-view-mode)
call-interactively(doc-view-mode record nil)
command-execute(doc-view-mode record)
execute-extended-command(nil "doc-view-mode" "doc-view-mo")
funcall-interactively(execute-extended-command nil "doc-view-mode"
"doc-view-mo")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Debugger entered--entering a function:
* select-safe-coding-system(1 383892 no-conversion nil)
md5(#<buffer *temp*>)
doc-view--current-cache-dir()
doc-view-already-converted-p()
doc-view-initiate-display()
doc-view-mode()
funcall-interactively(doc-view-mode)
call-interactively(doc-view-mode record nil)
command-execute(doc-view-mode record)
execute-extended-command(nil "doc-view-mode" "doc-view-mo")
funcall-interactively(execute-extended-command nil "doc-view-mode"
"doc-view-mo")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Debugger entered--returning value: no-conversion
select-safe-coding-system(1 383892 no-conversion nil)
md5(#<buffer *temp*>)
doc-view--current-cache-dir()
doc-view-already-converted-p()
doc-view-initiate-display()
doc-view-mode()
funcall-interactively(doc-view-mode)
call-interactively(doc-view-mode record nil)
command-execute(doc-view-mode record)
execute-extended-command(nil "doc-view-mode" "doc-view-mo")
funcall-interactively(execute-extended-command nil "doc-view-mode"
"doc-view-mo")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
Debugger entered--entering a function:
* select-safe-coding-system("100" nil prefer-utf-8 nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
write-region("100" nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution...." nil silently)
#f(compiled-function () #<bytecode 0x42abe9>)()
doc-view-sentinel(#<process pdf/ps->png> "finished\n")
Debugger entered--returning value: prefer-utf-8-dos
select-safe-coding-system("100" nil prefer-utf-8 nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww...")
write-region("100" nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww..." nil silently)
#f(compiled-function () #<bytecode 0x42abe9>)()
doc-view-sentinel(#<process pdf/ps->png> "finished\n")
Debugger entered--returning value: prefer-utf-8-dos
select-safe-coding-system("100" nil prefer-utf-8 nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww...")
write-region("100" nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww..." nil silently)
#f(compiled-function () #<bytecode 0x42abe9>)()
doc-view-sentinel(#<process pdf/ps->png> "finished\n")
Let me know if I was supposed to do something differently.
Nicholas
On Wed, Nov 4, 2020 at 8:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Nicholas Harrison <nicholasharrison222@gmail.com>
> > Date: Tue, 3 Nov 2020 16:52:40 -0700
> > Cc: 44338@debbugs.gnu.org
> >
> > This can be (partially) corrected by running the following code before
> the steps 2 and 3:
> > (add-to-list 'mailcap-user-mime-data
> > '((type . "application/pdf")
> > (viewer . doc-view-mode)))
> >
> > This chooses a view mode for the pdf but that brings the second problem.
> This selects the default encoding
> > of raw-text and the conversion fails:
>
> You say it selects raw-text, but the screenshot you sent clearly shows
> that Emacs was trying to use iso-latin-1-dos. In which case the
> failure is easily understandable, but I don't immediately see where
> did that value come from (it's most probably the default value of
> buffer-file-coding-system for you, but since eww-display-pdf binds
> coding-system-for-write, the question is why that value isn't being
> used). Could you perhaps produce a backtrace from that situation?
> For example, like this:
>
> M-: (debug-on-entry 'select-safe-coding-system) RET
>
> and then repeat the recipe.
>
> In any case, this isn't right:
>
> (defun eww-display-pdf ()
> (let ((data (buffer-substring (point) (point-max))))
> (pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
> (let ((coding-system-for-write 'raw-text) <<<<<<<<<<<<<<<<<<<<<<
> (inhibit-read-only t))
> (erase-buffer)
> (insert data)
> (mailcap-view-mime "application/pdf")))
> (goto-char (point-min)))
>
> We should use 'raw-text-unix here, since the buffer contents is a
> stream of raw bytes.
>
[-- Attachment #2: Type: text/html, Size: 7661 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-04 23:43 ` Nicholas Harrison
@ 2020-11-05 13:42 ` Eli Zaretskii
2020-11-05 13:42 ` Eli Zaretskii
1 sibling, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-05 13:42 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: contovob, 44338
> From: Nicholas Harrison <nicholasharrison222@gmail.com>
> Date: Wed, 4 Nov 2020 16:43:13 -0700
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 44338@debbugs.gnu.org
>
> Not sure if this is much help, but here is the backtrace given when I do the following steps:
>
> 1. emacs -Q
> 2. M-: (debug-on-entry 'select-safe-coding-system) RET
> 3. M-x eww RET https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf RET
> (no backtrace here)
> 4. M-x doc-view-mode RET
>
> Debugger entered--entering a function:
> * select-safe-coding-system(1 381654 iso-latin-1-dos nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
> write-region(nil nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
> doc-view-mode()
> funcall-interactively(doc-view-mode)
> call-interactively(doc-view-mode record nil)
> command-execute(doc-view-mode record)
> execute-extended-command(nil "doc-view-mode" "doc-view-mo")
> funcall-interactively(execute-extended-command nil "doc-view-mode" "doc-view-mo")
> call-interactively(execute-extended-command nil nil)
> command-execute(execute-extended-command)
Thanks. This tells part of the story, but not all of it. What I
wanted to see was the backtrace when doc-view-mode is invoked by EWW.
AFAIU, that requires you to augment mailcap-user-mime-data as this:
(add-to-list 'mailcap-user-mime-data
'((type . "application/pdf")
(viewer . doc-view-mode)))
before performing the reproduction steps.
To give you more background: when you invoke doc-view-mode manually in
a buffer produced by "M-x eww", the buffer's buffer-file-coding-system
is the platform default, in your case iso-latin-1-dos. That is what
doc-view-mode uses to write the PDF bytestream to a temporary file,
and that fails because iso-latin-1-dos cannot encode the raw bytes in
the binary content. But eww-display-pdf binds coding-system-for-write
to 'raw-text, and then doc-view-mode ought to use that to write to the
temporary file, and yet in your screenshot I still see it tried to use
iso-latin-1-dos, which I cannot explain. So I'd like to see the
backtrace when you invoke doc-view-mode via EWW, after augmenting
mailcap-user-mime-data, to try to understand why it uses the wrong
encoding.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
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
1 sibling, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-05 13:42 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: contovob, 44338
> From: Nicholas Harrison <nicholasharrison222@gmail.com>
> Date: Wed, 4 Nov 2020 16:43:13 -0700
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 44338@debbugs.gnu.org
>
> Not sure if this is much help, but here is the backtrace given when I do the following steps:
>
> 1. emacs -Q
> 2. M-: (debug-on-entry 'select-safe-coding-system) RET
> 3. M-x eww RET https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf RET
> (no backtrace here)
> 4. M-x doc-view-mode RET
>
> Debugger entered--entering a function:
> * select-safe-coding-system(1 381654 iso-latin-1-dos nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
> write-region(nil nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
> doc-view-mode()
> funcall-interactively(doc-view-mode)
> call-interactively(doc-view-mode record nil)
> command-execute(doc-view-mode record)
> execute-extended-command(nil "doc-view-mode" "doc-view-mo")
> funcall-interactively(execute-extended-command nil "doc-view-mode" "doc-view-mo")
> call-interactively(execute-extended-command nil nil)
> command-execute(execute-extended-command)
Thanks. This tells part of the story, but not all of it. What I
wanted to see was the backtrace when doc-view-mode is invoked by EWW.
AFAIU, that requires you to augment mailcap-user-mime-data as this:
(add-to-list 'mailcap-user-mime-data
'((type . "application/pdf")
(viewer . doc-view-mode)))
before performing the reproduction steps.
To give you more background: when you invoke doc-view-mode manually in
a buffer produced by "M-x eww", the buffer's buffer-file-coding-system
is the platform default, in your case iso-latin-1-dos. That is what
doc-view-mode uses to write the PDF bytestream to a temporary file,
and that fails because iso-latin-1-dos cannot encode the raw bytes in
the binary content. But eww-display-pdf binds coding-system-for-write
to 'raw-text, and then doc-view-mode ought to use that to write to the
temporary file, and yet in your screenshot I still see it tried to use
iso-latin-1-dos, which I cannot explain. So I'd like to see the
backtrace when you invoke doc-view-mode via EWW, after augmenting
mailcap-user-mime-data, to try to understand why it uses the wrong
encoding.
Can you please produce the backtrace under those modified conditions?
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
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
0 siblings, 2 replies; 39+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-05 15:12 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> Alternatively, mailcap--computed-mime-data could be kept in canonical
> order, e.g. in mailcap-add-mailcap-entry?
I guess that would make sense, but this code has been re-fixed so
much that I'd rather ... leave it alone for a while. :-)
> [BTW, I don't see the function mailcap-add used anywhere.]
It's for usage by users, I think?
> [And neither do I see your changes on Savannah. ;]
Forgot to push; done now.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-03 23:24 ` Basil L. Contovounesios
@ 2020-11-05 15:13 ` Lars Ingebrigtsen
2020-11-05 17:37 ` Basil L. Contovounesios
0 siblings, 1 reply; 39+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-05 15:13 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison, Jean Louis
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> How's the attached?
Haven't tried it, but it sounds like a good change to me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 13:42 ` Eli Zaretskii
@ 2020-11-05 15:18 ` Nicholas Harrison
2020-11-05 15:49 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Nicholas Harrison @ 2020-11-05 15:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44338
[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]
After running the code you gave and using eww to open a pdf, this is what I
get:
Debugger entered--entering a function:
* select-safe-coding-system("100" nil prefer-utf-8 nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
write-region("100" nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
#f(compiled-function () #<bytecode 0x1ff19f1>)()
doc-view-sentinel(#<process pdf/ps->png> "finished\n")
Debugger entered--returning value: prefer-utf-8-dos
select-safe-coding-system("100" nil prefer-utf-8 nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
write-region("100" nil
"c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
#f(compiled-function () #<bytecode 0x1ff19f1>)()
doc-view-sentinel(#<process pdf/ps->png> "finished\n")
The buffer it ends up with says:
Cannot display this page!
Maybe because of a conversion failure!
On Thu, Nov 5, 2020 at 6:42 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Nicholas Harrison <nicholasharrison222@gmail.com>
> > Date: Wed, 4 Nov 2020 16:43:13 -0700
> > Cc: "Basil L. Contovounesios" <contovob@tcd.ie>, 44338@debbugs.gnu.org
> >
> > Not sure if this is much help, but here is the backtrace given when I do
> the following steps:
> >
> > 1. emacs -Q
> > 2. M-: (debug-on-entry 'select-safe-coding-system) RET
> > 3. M-x eww RET
> https://www.gnu.org/software/emacs/manual/pdf/emacs-xtra.pdf RET
> > (no backtrace here)
> > 4. M-x doc-view-mode RET
> >
> > Debugger entered--entering a function:
> > * select-safe-coding-system(1 381654 iso-latin-1-dos nil
> > "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
> > write-region(nil nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww pdf!")
> > doc-view-mode()
> > funcall-interactively(doc-view-mode)
> > call-interactively(doc-view-mode record nil)
> > command-execute(doc-view-mode record)
> > execute-extended-command(nil "doc-view-mode" "doc-view-mo")
> > funcall-interactively(execute-extended-command nil "doc-view-mode"
> "doc-view-mo")
> > call-interactively(execute-extended-command nil nil)
> > command-execute(execute-extended-command)
>
> Thanks. This tells part of the story, but not all of it. What I
> wanted to see was the backtrace when doc-view-mode is invoked by EWW.
> AFAIU, that requires you to augment mailcap-user-mime-data as this:
>
> (add-to-list 'mailcap-user-mime-data
> '((type . "application/pdf")
> (viewer . doc-view-mode)))
>
> before performing the reproduction steps.
>
> To give you more background: when you invoke doc-view-mode manually in
> a buffer produced by "M-x eww", the buffer's buffer-file-coding-system
> is the platform default, in your case iso-latin-1-dos. That is what
> doc-view-mode uses to write the PDF bytestream to a temporary file,
> and that fails because iso-latin-1-dos cannot encode the raw bytes in
> the binary content. But eww-display-pdf binds coding-system-for-write
> to 'raw-text, and then doc-view-mode ought to use that to write to the
> temporary file, and yet in your screenshot I still see it tried to use
> iso-latin-1-dos, which I cannot explain. So I'd like to see the
> backtrace when you invoke doc-view-mode via EWW, after augmenting
> mailcap-user-mime-data, to try to understand why it uses the wrong
> encoding.
>
> Can you please produce the backtrace under those modified conditions?
>
[-- Attachment #2: Type: text/html, Size: 4814 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 15:18 ` Nicholas Harrison
@ 2020-11-05 15:49 ` Eli Zaretskii
2020-11-05 17:52 ` Nicholas Harrison
0 siblings, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-05 15:49 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: 44338
> From: Nicholas Harrison <nicholasharrison222@gmail.com>
> Date: Thu, 5 Nov 2020 08:18:19 -0700
> Cc: 44338@debbugs.gnu.org
>
> After running the code you gave and using eww to open a pdf, this is what I get:
>
> Debugger entered--entering a function:
> * select-safe-coding-system("100" nil prefer-utf-8 nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
> write-region("100" nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
> #f(compiled-function () #<bytecode 0x1ff19f1>)()
> doc-view-sentinel(#<process pdf/ps->png> "finished\n")
>
> Debugger entered--returning value: prefer-utf-8-dos
> select-safe-coding-system("100" nil prefer-utf-8 nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
> write-region("100" nil "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
> #f(compiled-function () #<bytecode 0x1ff19f1>)()
> doc-view-sentinel(#<process pdf/ps->png> "finished\n")
Hmm, that's not the problem you reported originally, and it doesn't
look like Emacs asked you to select an encoding here, did it?
> The buffer it ends up with says:
> Cannot display this page!
> Maybe because of a conversion failure!
So I guess I'm confused now and don't know what is the problem, sorry.
A stub in the dark: if you replace raw-text with raw-text-unix here:
(defun eww-display-pdf ()
(let ((data (buffer-substring (point) (point-max))))
(pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
(let ((coding-system-for-write 'raw-text) <<<<<<<<<<<<<<<<<<<
(inhibit-read-only t))
(erase-buffer)
(insert data)
(mailcap-view-mime "application/pdf")))
(goto-char (point-min)))
does the problem go away?
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 15:12 ` Lars Ingebrigtsen
@ 2020-11-05 17:36 ` Basil L. Contovounesios
2020-11-05 20:40 ` Basil L. Contovounesios
1 sibling, 0 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-05 17:36 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
Lars Ingebrigtsen <larsi@gnus.org> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Alternatively, mailcap--computed-mime-data could be kept in canonical
>> order, e.g. in mailcap-add-mailcap-entry?
>
> I guess that would make sense, but this code has been re-fixed so
> much that I'd rather ... leave it alone for a while. :-)
I understand. :)
>> [BTW, I don't see the function mailcap-add used anywhere.]
>
> It's for usage by users, I think?
Right.
>> [And neither do I see your changes on Savannah. ;]
>
> Forgot to push; done now.
Thanks.
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 15:13 ` Lars Ingebrigtsen
@ 2020-11-05 17:37 ` Basil L. Contovounesios
0 siblings, 0 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-05 17:37 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison, Jean Louis
Lars Ingebrigtsen <larsi@gnus.org> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> How's the attached?
>
> Haven't tried it, but it sounds like a good change to me.
Thanks, pushed to ease testing. ;)
Improve eww support for externally viewed PDFs
bfd3124202 2020-11-05 17:34:23 +0000
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bfd31242025cde90c8252db92dc54d0be4115c91
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 15:49 ` Eli Zaretskii
@ 2020-11-05 17:52 ` Nicholas Harrison
2020-11-05 17:55 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Nicholas Harrison @ 2020-11-05 17:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44338
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
No, it didn't ask me for an encoding.
Good stab in the dark. I ran your new function code and the
mailcap-user-mime-data code again (after loading eww). No debugger
triggered. It converted and showed the pdf correctly.
On Thu, Nov 5, 2020 at 8:50 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Nicholas Harrison <nicholasharrison222@gmail.com>
> > Date: Thu, 5 Nov 2020 08:18:19 -0700
> > Cc: 44338@debbugs.gnu.org
> >
> > After running the code you gave and using eww to open a pdf, this is
> what I get:
> >
> > Debugger entered--entering a function:
> > * select-safe-coding-system("100" nil prefer-utf-8 nil
> > "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> > pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
> > write-region("100" nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> > pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
> > #f(compiled-function () #<bytecode 0x1ff19f1>)()
> > doc-view-sentinel(#<process pdf/ps->png> "finished\n")
> >
> > Debugger entered--returning value: prefer-utf-8-dos
> > select-safe-coding-system("100" nil prefer-utf-8 nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> > pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el")
> > write-region("100" nil
> "c:/Users/nicho/AppData/Local/Temp/docview1001/!eww
> > pdf!-2072e1249b26ee28e656f1a01f0cb4a9/resolution.el" nil silently)
> > #f(compiled-function () #<bytecode 0x1ff19f1>)()
> > doc-view-sentinel(#<process pdf/ps->png> "finished\n")
>
> Hmm, that's not the problem you reported originally, and it doesn't
> look like Emacs asked you to select an encoding here, did it?
>
> > The buffer it ends up with says:
> > Cannot display this page!
> > Maybe because of a conversion failure!
>
> So I guess I'm confused now and don't know what is the problem, sorry.
>
> A stub in the dark: if you replace raw-text with raw-text-unix here:
>
> (defun eww-display-pdf ()
> (let ((data (buffer-substring (point) (point-max))))
> (pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
> (let ((coding-system-for-write 'raw-text) <<<<<<<<<<<<<<<<<<<
> (inhibit-read-only t))
> (erase-buffer)
> (insert data)
> (mailcap-view-mime "application/pdf")))
> (goto-char (point-min)))
>
> does the problem go away?
>
[-- Attachment #2: Type: text/html, Size: 3256 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 17:52 ` Nicholas Harrison
@ 2020-11-05 17:55 ` Eli Zaretskii
2020-11-05 19:04 ` Basil L. Contovounesios
0 siblings, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-05 17:55 UTC (permalink / raw)
To: Nicholas Harrison; +Cc: 44338
> From: Nicholas Harrison <nicholasharrison222@gmail.com>
> Date: Thu, 5 Nov 2020 10:52:10 -0700
> Cc: 44338@debbugs.gnu.org
>
> No, it didn't ask me for an encoding.
>
> Good stab in the dark. I ran your new function code and the mailcap-user-mime-data code again (after
> loading eww). No debugger triggered. It converted and showed the pdf correctly.
Great, then the change Basil already made locally will also solve the
last part of the problem.
Thanks.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 17:55 ` Eli Zaretskii
@ 2020-11-05 19:04 ` Basil L. Contovounesios
2020-11-05 19:20 ` Eli Zaretskii
2020-11-05 20:40 ` Lars Ingebrigtsen
0 siblings, 2 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-05 19:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44338, Nicholas Harrison
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Nicholas Harrison <nicholasharrison222@gmail.com>
>> Date: Thu, 5 Nov 2020 10:52:10 -0700
>> Cc: 44338@debbugs.gnu.org
>>
>> No, it didn't ask me for an encoding.
>>
>> Good stab in the dark. I ran your new function code and the mailcap-user-mime-data code again (after
>> loading eww). No debugger triggered. It converted and showed the pdf correctly.
>
> 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?
In other words, can we remove the binding altogether from
eww-display-pdf and make the *eww pdf* buffer unibyte, as Stefan
suggested?
Could something funny happen / be happening during insertion from one
buffer into the other in eww-display-pdf?
Thanks,
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 19:04 ` Basil L. Contovounesios
@ 2020-11-05 19:20 ` Eli Zaretskii
2020-11-05 21:17 ` Basil L. Contovounesios
2020-11-05 20:40 ` Lars Ingebrigtsen
1 sibling, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-05 19:20 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, nicholasharrison222
> 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.
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 15:12 ` Lars Ingebrigtsen
2020-11-05 17:36 ` Basil L. Contovounesios
@ 2020-11-05 20:40 ` Basil L. Contovounesios
1 sibling, 0 replies; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-05 20:40 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
Lars Ingebrigtsen <larsi@gnus.org> writes:
>> [BTW, I don't see the function mailcap-add used anywhere.]
>
> It's for usage by users, I think?
When I do:
0. emacs -Q
1. (progn
(require 'mailcap)
(mailcap-add "application/pdf" "mupdf %s")
mailcap-user-mime-data)
2. C-j
This results in:
(("application"
("pdf"
(viewer . "mupdf %s")
(test . t)
(type . "application/pdf"))))
But mailcap-user-mime-data is documented as being a list of
((viewer . VIEWER)
(type . MIME-TYPE)
(test . TEST))
Isn't this a bug? The documentation of mailcap-add doesn't exactly
welcome the user either...
Thanks,
--
Basil
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 19:04 ` Basil L. Contovounesios
2020-11-05 19:20 ` Eli Zaretskii
@ 2020-11-05 20:40 ` Lars Ingebrigtsen
2020-11-05 21:25 ` Basil L. Contovounesios
1 sibling, 1 reply; 39+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-05 20:40 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Nicholas Harrison
"Basil L. Contovounesios" <contovob@tcd.ie> writes:
> In other words, can we remove the binding altogether from
> eww-display-pdf and make the *eww pdf* buffer unibyte, as Stefan
> suggested?
Yes, this is the correct fix.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 19:20 ` Eli Zaretskii
@ 2020-11-05 21:17 ` Basil L. Contovounesios
2020-11-06 5:29 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-05 21:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44338, nicholasharrison222
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
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 20:40 ` Lars Ingebrigtsen
@ 2020-11-05 21:25 ` Basil L. Contovounesios
2020-11-06 2:12 ` Nicholas Harrison
0 siblings, 1 reply; 39+ messages in thread
From: Basil L. Contovounesios @ 2020-11-05 21:25 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 44338, Nicholas Harrison
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
tags 44338 fixed
close 44338 28.1
quit
Lars Ingebrigtsen <larsi@gnus.org> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> In other words, can we remove the binding altogether from
>> eww-display-pdf and make the *eww pdf* buffer unibyte, as Stefan
>> suggested?
>
> Yes, this is the correct fix.
Thanks, done.
Fix coding system in eww-display-pdf
4610241a9b 2020-11-05 21:06:39 +0000
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4610241a9b3fbddd1f0973bf49f7008ed09ab955
I'm therefore marking this bug as fixed in 28.1.
Nicholas, here's the cumulative change to the function eww-display-pdf,
in case you want to patch/advise yours on Emacs 27.1:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: eww.diff --]
[-- Type: text/x-diff, Size: 1157 bytes --]
diff --git a/lisp/net/eww.el b/lisp/net/eww.el
index d6f850ca3b..43405fbd9c 100644
--- a/lisp/net/eww.el
+++ b/lisp/net/eww.el
@@ -667,14 +811,19 @@ eww-display-image
(declare-function mailcap-view-mime "mailcap" (type))
(defun eww-display-pdf ()
- (let ((data (buffer-substring (point) (point-max))))
- (pop-to-buffer-same-window (get-buffer-create "*eww pdf*"))
- (let ((coding-system-for-write 'raw-text)
- (inhibit-read-only t))
- (erase-buffer)
- (insert data)
- (mailcap-view-mime "application/pdf")))
- (goto-char (point-min)))
+ (let ((buf (current-buffer))
+ (pos (point)))
+ (with-current-buffer (get-buffer-create "*eww pdf*")
+ (let ((inhibit-read-only t))
+ (erase-buffer)
+ (set-buffer-multibyte nil)
+ (insert-buffer-substring buf pos)
+ (mailcap-view-mime "application/pdf"))
+ (if (zerop (buffer-size))
+ ;; Buffer contents passed to shell command via temporary file.
+ (kill-buffer)
+ (goto-char (point-min))
+ (pop-to-buffer-same-window (current-buffer))))))
(defun eww-setup-buffer ()
(when (or (plist-get eww-data :url)
[-- Attachment #3: Type: text/plain, Size: 11 bytes --]
--
Basil
^ permalink raw reply related [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 21:25 ` Basil L. Contovounesios
@ 2020-11-06 2:12 ` Nicholas Harrison
0 siblings, 0 replies; 39+ messages in thread
From: Nicholas Harrison @ 2020-11-06 2:12 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, Lars Ingebrigtsen
[-- Attachment #1: Type: text/plain, Size: 842 bytes --]
Awesome, thanks!
On Thu, Nov 5, 2020 at 2:25 PM Basil L. Contovounesios <contovob@tcd.ie>
wrote:
> tags 44338 fixed
> close 44338 28.1
> quit
>
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > "Basil L. Contovounesios" <contovob@tcd.ie> writes:
> >
> >> In other words, can we remove the binding altogether from
> >> eww-display-pdf and make the *eww pdf* buffer unibyte, as Stefan
> >> suggested?
> >
> > Yes, this is the correct fix.
>
> Thanks, done.
>
> Fix coding system in eww-display-pdf
> 4610241a9b 2020-11-05 21:06:39 +0000
>
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4610241a9b3fbddd1f0973bf49f7008ed09ab955
>
> I'm therefore marking this bug as fixed in 28.1.
>
> Nicholas, here's the cumulative change to the function eww-display-pdf,
> in case you want to patch/advise yours on Emacs 27.1:
>
>
> --
> Basil
>
[-- Attachment #2: Type: text/html, Size: 1520 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* bug#44338: 27.1; EWW can't download and view pdf
2020-11-05 21:17 ` Basil L. Contovounesios
@ 2020-11-06 5:29 ` Eli Zaretskii
0 siblings, 0 replies; 39+ messages in thread
From: Eli Zaretskii @ 2020-11-06 5:29 UTC (permalink / raw)
To: Basil L. Contovounesios; +Cc: 44338, nicholasharrison222
> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: nicholasharrison222@gmail.com, 44338@debbugs.gnu.org
> Date: Thu, 05 Nov 2020 21:17:22 +0000
>
> >> 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.
The only Windows-related snafu here could be (1) the EOL issue due to
using raw-text instead of raw-text-unix; and (2) the fact that on
Windows systems the default encoding is not UTF-8.
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2020-11-06 5:29 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.