From: Stephen Berman <stephen.berman@gmx.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 34138@debbugs.gnu.org, Andreas Politz <politza@fh-trier.de>,
Andreas Politz <politza@hochschule-trier.de>
Subject: bug#34138: 27.0.50; Delayed display of PDF file images
Date: Sun, 20 Jan 2019 12:18:36 +0100 [thread overview]
Message-ID: <87h8e3h90z.fsf@gmx.net> (raw)
In-Reply-To: <5C443CB1.3050208@gmx.at> (martin rudalics's message of "Sun, 20 Jan 2019 10:17:37 +0100")
On Sun, 20 Jan 2019 10:17:37 +0100 martin rudalics <rudalics@gmx.at> wrote:
>> Since a recent commit, I'm seeing a delay in the display of PDF files as
>> images (both with -Q and with my initializations). I see this in both
>> doc-view-mode and pdf-view-mode (from the pdf-tools package, available
>> from MELPA). In doc-view-mode, on visiting a PDF file, it at first
>> appears as raw PDF, as when visiting it in fundamental-mode, and only
>> after a few seconds does the image appear.
>
> I cannot see how 'doc-view-mode' could be possibly affected by the
> changes you identified below. It doesn't run any of the affected
> hooks. Have you tried running 'doc-view-mode' without loading
> 'pdf-view-mode'?
Yes, as I noted, I also see this with -Q.
>> The same happens in
>> pdf-view-mode but there the delay is much longer -- with some files it
>> takes close to a minute on my machine before the image is displayed,
>> unless I provide keyboard input, which makes the image appear
>> immediately.
>
> These might be related although going through the sources of
> ‘pdf-view-mode’ I cannot see any problem. 'pdf-util-window-attach'
> uses a workaround for deleting a window after running
> 'window-configuration-change-hook' and there I see a different source
> of trouble:
>
> 'display-buffer-split-below-and-attach' calls 'window--display-buffer'
> with a fifth argument and that has been changed in another commit.
> Please remove the display-buffer-mark-dedicated argument in that call
> and see whether the problem persists. CC-ing Andreas to make an
> appropriate change in pdf-util.el.
AFAICS display-buffer-split-below-and-attach is only used in the
defcustom pdf-annot-edit-contents-display-buffer-action, which specified
the "Display action when showing the edit buffer", so it's irrelevent
for just displaying the PDF file. Anyway, I modified and instrumented
the function, but it wasn't called on visiting the file.
>> In addition, in pdf-view-mode this appears in *Message*:
>> Error during redisplay: (eval (pdf-misc-size-indication)) signaled
>> (error "Invalid image specification: nil").
>
> This should come from the 'image-display-size' call in
> 'pdf-view-image-size'. Could you get a backtrace for it?
There is no Lisp backtrace, just the "error during redisplay" message.
That eval expression is a modeline construct, so I guess this needs to
be debugged at the C level. I could try to do that but probably need
guidance. (Ah, I just saw Andreas's post that he could reproduce the
issue, so hopefully he can debug it.)
Steve Berman
next prev parent reply other threads:[~2019-01-20 11:18 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-19 21:13 bug#34138: 27.0.50; Delayed display of PDF file images Stephen Berman
2019-01-20 9:17 ` martin rudalics
2019-01-20 11:04 ` Andreas Politz
2019-01-20 14:19 ` martin rudalics
2019-01-20 11:18 ` Stephen Berman [this message]
2019-01-20 14:20 ` martin rudalics
2019-01-20 14:55 ` Stephen Berman
2019-01-20 15:32 ` Eli Zaretskii
2019-01-20 15:51 ` Stephen Berman
2019-01-20 16:08 ` Eli Zaretskii
2019-01-20 16:31 ` Stephen Berman
2019-01-20 16:50 ` Eli Zaretskii
2019-01-20 17:14 ` Stephen Berman
2019-01-20 17:42 ` Eli Zaretskii
2019-01-20 20:45 ` Stephen Berman
2019-01-21 15:58 ` Eli Zaretskii
2019-01-21 16:13 ` Stephen Berman
2019-01-21 16:36 ` Eli Zaretskii
2019-01-21 18:17 ` Stephen Berman
2019-01-21 18:42 ` Eli Zaretskii
2019-01-21 19:14 ` Andreas Politz
2019-01-21 19:47 ` Eli Zaretskii
2019-01-21 22:27 ` Stephen Berman
2019-01-22 16:25 ` Eli Zaretskii
2019-01-22 22:00 ` Stephen Berman
2019-01-23 14:31 ` Stephen Berman
2019-01-23 16:26 ` Eli Zaretskii
2019-01-23 17:22 ` Stephen Berman
2019-01-23 16:13 ` Eli Zaretskii
2019-01-23 17:21 ` Stephen Berman
2019-01-23 22:20 ` Stephen Berman
2019-01-23 18:27 ` martin rudalics
2019-01-23 18:39 ` Eli Zaretskii
2019-01-24 9:08 ` martin rudalics
2019-01-24 14:26 ` Eli Zaretskii
2019-01-24 19:41 ` Andreas Politz
2019-01-25 9:44 ` martin rudalics
2019-01-26 9:19 ` martin rudalics
2019-01-26 10:52 ` Eli Zaretskii
2019-01-26 15:07 ` martin rudalics
2019-01-26 15:33 ` Stephen Berman
2019-02-02 9:28 ` martin rudalics
2019-02-02 9:38 ` Andreas Politz
2019-02-19 8:47 ` martin rudalics
2019-02-02 12:59 ` Stephen Berman
2019-02-19 8:40 ` martin rudalics
2019-03-30 2:56 ` Noam Postavsky
2019-04-23 9:22 ` martin rudalics
2019-02-02 9:33 ` Andreas Politz
2019-02-02 9:37 ` martin rudalics
2019-01-21 20:33 ` Stephen Berman
2019-01-21 20:35 ` Eli Zaretskii
2019-01-21 20:43 ` Stephen Berman
2019-01-21 21:28 ` Andreas Politz
2019-01-21 18:47 ` martin rudalics
2019-01-21 19:19 ` Andreas Politz
2019-01-21 20:33 ` Stephen Berman
2019-01-20 17:55 ` martin rudalics
2019-01-20 20:45 ` Stephen Berman
2019-01-21 7:52 ` martin rudalics
2019-01-21 15:20 ` Stephen Berman
2019-01-21 6:11 ` Tassilo Horn
2019-01-21 7:52 ` martin rudalics
2019-01-21 15:20 ` Stephen Berman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h8e3h90z.fsf@gmx.net \
--to=stephen.berman@gmx.net \
--cc=34138@debbugs.gnu.org \
--cc=politza@fh-trier.de \
--cc=politza@hochschule-trier.de \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this 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.