When I revisit a PDF file that DocView has cached (also when starting
with -Q, with the cache /tmp/docview1000), trying to scroll past the
bottom or top of the page fails with the error
"doc-view-scroll-up-or-next-page: Wrong type argument:
number-or-marker-p, nil" or "doc-view-scroll-down-or-previous-page:
Wrong type argument: number-or-marker-p, nil" and in either case also
with "Error during redisplay: (eval (number-to-string
(doc-view-current-page))) signaled (wrong-type-argument numberp nil)".
In addition, the page number indication in the mode line looks odd:
e.g. for a one page document it shows "P/1", for a five page document it
shows "P/5" (only the first page is displayed).
This problem vanishes if I type `C-c C-c' to view the PDF source and
then type it again to redisplay the image: now scrolling works and the
mode line displays "P1/1" or "P1/5". If I kill the buffer and revisit
the cached file, the problem reoccurs. Instead of `C-c C-c', typing `W'
or `H' also redisplays the image, and now scrolling works but the size
is unaltered; repeating `W' or `H' correctly displays the changed size.
Finally, if I delete the cache and then revisit the file, there is no
problem (but there is as soon as I revisit a cached file).
The problem does not seem to happen with large PDF that have many pages;
maybe these are not cached. It also does not happen with PS files, but
those are initially visited in ps-mode and I have to type `C-c C-c' to
view the image, so this may circumvent the problem I see with PDF files
(I currently cannot view ODF or DOCX files with DocView).
I think this problem started some time between trunk revisions 110689
and 110748 (it happened with my build from the latter but not with my
build from the former revision); I haven't had time to bisect. It also
happens with the emacs-24 branch, revno 110854; it does not happen with
the openSUSE build of 24.2 from 2012-10-10.
In GNU Emacs 24.3.50.1 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
of 2012-11-12 on rosalinde
Bzr revision: 110874 monn...@iro.umontreal.ca-20121112204343-9y1tr86dl71iztk7
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description: openSUSE 12.2 (x86_64)
Recent messages:
Error during redisplay: (eval (number-to-string (doc-view-current-page))) signaled (wrong-type-argument numberp nil) [7 times]
DocView: using cached files!
Type C-c C-c to toggle between editing or viewing the document.
Error during redisplay: (eval (number-to-string (doc-view-current-page))) signaled (wrong-type-argument numberp nil)
Quit
Opening nntp server on news.gmane.org...
gnutls.c: [1] Note that the security level of the Diffie-Hellman key exchange has been lowered to 256 bits and this may allow decryption of the session data
Stephen Berman <stephen.ber...@gmx.net> writes:
> When I revisit a PDF file that DocView has cached (also when starting
> with -Q, with the cache /tmp/docview1000), trying to scroll past the
> bottom or top of the page fails with the error
> "doc-view-scroll-up-or-next-page: Wrong type argument:
> number-or-marker-p, nil" or "doc-view-scroll-down-or-previous-page:
> Wrong type argument: number-or-marker-p, nil" and in either case also
> with "Error during redisplay: (eval (number-to-string
> (doc-view-current-page))) signaled (wrong-type-argument numberp nil)".
> In addition, the page number indication in the mode line looks odd:
> e.g. for a one page document it shows "P/1", for a five page document
> it shows "P/5" (only the first page is displayed).
I can confirm the issue. The problem is that (doc-view-current-page)
and returns nil, although that's setf-ed in `doc-view-initiate-display'.
But I think at this time, the window going to hold the images isn't
there already.
As a workaround, do `M-g M-g 1 RET'. I'll look into this issue later
today.
the following patch fixes the issue for me, but I'm not sure if it's the
right thing to do. Stefan, could you please check?
Basically, the difference between finding a not yet converted doc and a
doc that's already cached is that in the former case
`doc-view-goto-page' runs with the selected window displaying the doc's
buffer. AFAIKS, that's a must for the image-mode winprops stuff to
work, so in the latter case, the patch defers running
`doc-view-goto-page' a bit into the future when the window showing the
doc buffer is hopefully there.
--8<---------------cut here---------------start------------->8---
=== modified file 'lisp/doc-view.el'
--- lisp/doc-view.el 2012-09-28 10:05:46 +0000
+++ lisp/doc-view.el 2012-11-13 20:25:53 +0000
@@ -419,57 +419,63 @@
(defun doc-view-goto-page (page)
"View the page given by PAGE."
(interactive "nPage: ")
- (let ((len (doc-view-last-page-number))
- (hscroll (window-hscroll)))
- (if (< page 1)
- (setq page 1)
- (when (and (> page len)
- ;; As long as the converter is running, we don't know
- ;; how many pages will be available.
- (null doc-view-current-converter-processes))
- (setq page len)))
- (setf (doc-view-current-page) page
- (doc-view-current-info)
- (concat
- (propertize
- (format "Page %d of %d." page len) 'face 'bold)
- ;; Tell user if converting isn't finished yet
- (if doc-view-current-converter-processes
- " (still converting...)\n"
- "\n")
- ;; Display context infos if this page matches the last search
- (when (and doc-view-current-search-matches
- (assq page doc-view-current-search-matches))
- (concat (propertize "Search matches:\n" 'face 'bold)
- (let ((contexts ""))
- (dolist (m (cdr (assq page
- doc-view-current-search-matches)))
- (setq contexts (concat contexts " - \"" m "\"\n")))
- contexts)))))
- ;; Update the buffer
- ;; We used to find the file name from doc-view-current-files but
- ;; that's not right if the pages are not generated sequentially
- ;; or if the page isn't in doc-view-current-files yet.
- (let ((file (expand-file-name (format "page-%d.png" page)
- (doc-view-current-cache-dir))))
- (doc-view-insert-image file :pointer 'arrow)
- (set-window-hscroll (selected-window) hscroll)
- (when (and (not (file-exists-p file))
- doc-view-current-converter-processes)
- ;; The PNG file hasn't been generated yet.
- (doc-view-pdf->png-1 doc-view-buffer-file-name file page
- (let ((win (selected-window)))
- (lambda ()
- (and (eq (current-buffer) (window-buffer win))
- ;; If we changed page in the mean
- ;; time, don't mess things up.
- (eq (doc-view-current-page win) page)
- ;; Make sure we don't infloop.
- (file-readable-p file)
- (with-selected-window win
- (doc-view-goto-page page))))))))
- (overlay-put (doc-view-current-overlay)
- 'help-echo (doc-view-current-info))))
+ (if (null (get-buffer-window))
+ ;; The document buffer isn't displayed in any window yet. This
+ ;; happens when using cached PNG files. The buffer will be
+ ;; displayed after `doc-view-mode' has returned, so try again a
+ ;; bit later.
+ (run-with-timer 0.1 nil #'doc-view-goto-page page)
+ (let ((len (doc-view-last-page-number))
+ (hscroll (window-hscroll)))
+ (if (< page 1)
+ (setq page 1)
+ (when (and (> page len)
+ ;; As long as the converter is running, we don't know
+ ;; how many pages will be available.
+ (null doc-view-current-converter-processes))
+ (setq page len)))
+ (setf (doc-view-current-page) page
+ (doc-view-current-info)
+ (concat
+ (propertize
+ (format "Page %d of %d." page len) 'face 'bold)
+ ;; Tell user if converting isn't finished yet
+ (if doc-view-current-converter-processes
+ " (still converting...)\n"
+ "\n")
+ ;; Display context infos if this page matches the last search
+ (when (and doc-view-current-search-matches
+ (assq page doc-view-current-search-matches))
+ (concat (propertize "Search matches:\n" 'face 'bold)
+ (let ((contexts ""))
+ (dolist (m (cdr (assq page
+ doc-view-current-search-matches)))
+ (setq contexts (concat contexts " - \"" m "\"\n")))
+ contexts)))))
+ ;; Update the buffer
+ ;; We used to find the file name from doc-view-current-files but
+ ;; that's not right if the pages are not generated sequentially
+ ;; or if the page isn't in doc-view-current-files yet.
+ (let ((file (expand-file-name (format "page-%d.png" page)
+ (doc-view-current-cache-dir))))
+ (doc-view-insert-image file :pointer 'arrow)
+ (set-window-hscroll (selected-window) hscroll)
+ (when (and (not (file-exists-p file))
+ doc-view-current-converter-processes)
+ ;; The PNG file hasn't been generated yet.
+ (doc-view-pdf->png-1 doc-view-buffer-file-name file page
+ (let ((win (selected-window)))
+ (lambda ()
+ (and (eq (current-buffer) (window-buffer win))
+ ;; If we changed page in the mean
+ ;; time, don't mess things up.
+ (eq (doc-view-current-page win) page)
+ ;; Make sure we don't infloop.
+ (file-readable-p file)
+ (with-selected-window win
+ (doc-view-goto-page page))))))))
+ (overlay-put (doc-view-current-overlay)
+ 'help-echo (doc-view-current-info)))))
On Tue, 13 Nov 2012 21:28:44 +0100 Tassilo Horn <t...@gnu.org> wrote:
> Hi Stephen & Stefan,
> the following patch fixes the issue for me, but I'm not sure if it's the
> right thing to do. Stefan, could you please check?
> Basically, the difference between finding a not yet converted doc and a
> doc that's already cached is that in the former case
> `doc-view-goto-page' runs with the selected window displaying the doc's
> buffer. AFAIKS, that's a must for the image-mode winprops stuff to
> work, so in the latter case, the patch defers running
> `doc-view-goto-page' a bit into the future when the window showing the
> doc buffer is hopefully there.
The patch fixes the problem for me, too; thanks. However, the delay of
0.1 seconds results in the unconverted file being noticeable before the
image is displayed. I tried it with a 0.01 second delay and this makes
the image appear practically instantly to me, i.e., I didn't see the
unconverted source, and the paging still worked. I don't know if this
short a delay is always guaranteed to succeed.
Stephen Berman <stephen.ber...@gmx.net> writes:
>> the following patch fixes the issue for me, but I'm not sure if it's
>> the right thing to do. Stefan, could you please check?
>> Basically, the difference between finding a not yet converted doc and
>> a doc that's already cached is that in the former case
>> `doc-view-goto-page' runs with the selected window displaying the
>> doc's buffer. AFAIKS, that's a must for the image-mode winprops
>> stuff to work, so in the latter case, the patch defers running
>> `doc-view-goto-page' a bit into the future when the window showing
>> the doc buffer is hopefully there.
> The patch fixes the problem for me, too; thanks. However, the delay
> of 0.1 seconds results in the unconverted file being noticeable before
> the image is displayed.
Yes, but that's no big deal IMHO. You'll see the raw source for a short
time also when the doc isn't cached already.
> I tried it with a 0.01 second delay and this makes the image appear
> practically instantly to me, i.e., I didn't see the unconverted
> source, and the paging still worked. I don't know if this short a
> delay is always guaranteed to succeed.
It'll also work, but chances increase that the page-setting is deferred
another fraction again. I tried to set the value so that it's not
inconvenient but at the same time shouldn't need to delay again on
slower systems.
>>> the following patch fixes the issue for me, but I'm not sure if it's
>>> the right thing to do. Stefan, could you please check?
>>> Basically, the difference between finding a not yet converted doc and
>>> a doc that's already cached is that in the former case
>>> `doc-view-goto-page' runs with the selected window displaying the
>>> doc's buffer. AFAIKS, that's a must for the image-mode winprops
>>> stuff to work, so in the latter case, the patch defers running
>>> `doc-view-goto-page' a bit into the future when the window showing
>>> the doc buffer is hopefully there.
>> The patch fixes the problem for me, too; thanks. However, the delay
>> of 0.1 seconds results in the unconverted file being noticeable before
>> the image is displayed.
> Yes, but that's no big deal IMHO. You'll see the raw source for a short
> time also when the doc isn't cached already.
>> I tried it with a 0.01 second delay and this makes the image appear
>> practically instantly to me, i.e., I didn't see the unconverted
>> source, and the paging still worked. I don't know if this short a
>> delay is always guaranteed to succeed.
> It'll also work, but chances increase that the page-setting is deferred
> another fraction again. I tried to set the value so that it's not
> inconvenient but at the same time shouldn't need to delay again on
> slower systems.
Stephen Berman <stephen.ber...@gmx.net> writes:
>> It'll also work, but chances increase that the page-setting is
>> deferred another fraction again. I tried to set the value so that
>> it's not inconvenient but at the same time shouldn't need to delay
>> again on slower systems.
> How about making it customizable?
Surely that could be done. But I have no idea about a good description
not involving technical details that users shouldn't have to care about.
So maybe using a shorter delay is ok. After all, using doc-view is
computational intensive anyhow (at least the conversion with gs and
friends)...
Anyway, before going any further, I'd like to wait for Stefan telling us
if that's the right approach altogether.
> the following patch fixes the issue for me, but I'm not sure if it's the
> right thing to do. Stefan, could you please check?
[ BTW, using a "diff -b" is very helpful for such patches which
reindent a lot of code. ]
> Basically, the difference between finding a not yet converted doc and a
> doc that's already cached is that in the former case
> `doc-view-goto-page' runs with the selected window displaying the doc's
> buffer. AFAIKS, that's a must for the image-mode winprops stuff to
> work, so in the latter case, the patch defers running
Actually, no, the winprops stuff should also work when the buffer is not
displayed anywhere.
But I can't seem to reproduce the OP's problem.
I tried just "emacs -Q ~/tmp/foo.pdf; emacs -Q ~/tmp/foo.pdf" and it
worked fine.
I have the strange impression that the problem was actually not in
doc-view.el or image-mode.el (neither of which was modified between 110689
and 110748). I instead suspect it was a temporary bug in gv.el.
It's been fixed since, but the fix will only become effective after
recompiling the victim.
IOW, can you recompile image-mode.el and doc-view.el (or do a full
bootstrap) and then tell us whether you still see the problem (and if
so, try to provide a more detailed recipe)?
Stefan Monnier <monn...@iro.umontreal.ca> writes:
>> the following patch fixes the issue for me, but I'm not sure if it's the
>> right thing to do. Stefan, could you please check?
> [ BTW, using a "diff -b" is very helpful for such patches which
> reindent a lot of code. ]
Right, I'll do the next time.
>> Basically, the difference between finding a not yet converted doc and
>> a doc that's already cached is that in the former case
>> `doc-view-goto-page' runs with the selected window displaying the
>> doc's buffer. AFAIKS, that's a must for the image-mode winprops
>> stuff to work, so in the latter case, the patch defers running
> Actually, no, the winprops stuff should also work when the buffer is
> not displayed anywhere.
> But I can't seem to reproduce the OP's problem.
> I tried just "emacs -Q ~/tmp/foo.pdf; emacs -Q ~/tmp/foo.pdf" and it
> worked fine.
Not here running "e...@gnu.org-20121114172255-6mbtm95gmreikpt1", that is
revno 110896. I have the same symptoms as Stephen, that is, "P/17" in
mode-line and `doc-view-next-page' and friends error.
There are some newer commits since then, but none in
lisp/emacs-lisp/gv.el.
> I have the strange impression that the problem was actually not in
> doc-view.el or image-mode.el (neither of which was modified between
> 110689 and 110748). I instead suspect it was a temporary bug in
> gv.el. It's been fixed since, but the fix will only become effective
> after recompiling the victim.
I run Gentoo GNU/Linux, so everytime I reinstall the emacs-vcs package,
it'll do a complete vanialla install bootstrapping and recompiling
everything.
I'll update to revno 110904 to see if it works and report back.
Tassilo Horn <t...@gnu.org> writes:
>> Actually, no, the winprops stuff should also work when the buffer is
>> not displayed anywhere.
>> But I can't seem to reproduce the OP's problem. I tried just "emacs
>> -Q ~/tmp/foo.pdf; emacs -Q ~/tmp/foo.pdf" and it worked fine.
> Not here running "e...@gnu.org-20121114172255-6mbtm95gmreikpt1", that
> is revno 110896. I have the same symptoms as Stephen, that is, "P/17"
> in mode-line and `doc-view-next-page' and friends error.
> [...]
> I'll update to revno 110904 to see if it works and report back.
