GNU bug report logs -
#34138
27.0.50; Delayed display of PDF file images
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Sat, 19 Jan 2019 21:14:02 UTC
Severity: normal
Merged with 34202
Found in version 27.0.50
Fixed in version 27.1
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34138 in the body.
You can then email your comments to 34138 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 19 Jan 2019 21:14:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stephen Berman <stephen.berman <at> gmx.net>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 19 Jan 2019 21:14:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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. 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. In addition, in pdf-view-mode this appears in *Message*:
Error during redisplay: (eval (pdf-misc-size-indication)) signaled
(error "Invalid image specification: nil"). In doc-view-mode there is
no such error message. Git bisect pinpoints this commit:
e567ac1495..: Martin Rudalics 2019-01-11 Run window change functions
during redisplay
In GNU Emacs 27.0.50 (build 26, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-01-19 built on rosalinde
Repository revision: b821a70cb9467186afb55734a0e5cb4601909916
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: 8.3
Configured using:
'configure 'CFLAGS=-Og -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS CANNOT_DUMP LCMS2 GMP
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 09:18:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> 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'?
> 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.
> 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?
> In doc-view-mode there is
> no such error message. Git bisect pinpoints this commit:
>
> e567ac1495..: Martin Rudalics 2019-01-11 Run window change functions
> during redisplay
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 11:05:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 34138 <at> debbugs.gnu.org (full text, mbox):
I can reproduce this: Opening a PDF in the latest Emacs version requires
an extra redisplay for the image to appear, e.g. by entering the
minibuffer.
martin rudalics <rudalics <at> gmx.at> writes:
> 'display-buffer-split-below-and-attach' calls 'window--display-buffer'
> with a fifth argument and that has been changed in another commit.
I really wish this function would be part of the public API. Or else,
what is the best way to implement a function like
display-buffer-mark-dedicated ?
>> 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?
Right, the function pdf-misc-size-indication assumes the existence of a
displayed image in the selected window.
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 11:19:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Sun, 20 Jan 2019 10:17:37 +0100 martin rudalics <rudalics <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 14:21:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> I can reproduce this: Opening a PDF in the latest Emacs version requires
> an extra redisplay for the image to appear, e.g. by entering the
> minibuffer.
Do you have any idea what might be causing it? Excluding
'display-buffer-split-below-and-attach' it should be related to
'image-mode-new-window-functions'.
>> 'display-buffer-split-below-and-attach' calls 'window--display-buffer'
>> with a fifth argument and that has been changed in another commit.
>
> I really wish this function would be part of the public API. Or else,
> what is the best way to implement a function like
> display-buffer-mark-dedicated ?
It will be public soon. Moreove, application will not have to bother
with ‘display-buffer-mark-dedicated’ any more.
>>> 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?
>
> Right, the function pdf-misc-size-indication assumes the existence of a
> displayed image in the selected window.
What happened here? Did the image not get displayed or did the
selected window change or get another buffer?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 14:21:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 34138 <at> debbugs.gnu.org (full text, mbox):
>> Have you tried running 'doc-view-mode' without loading
>> 'pdf-view-mode'?
>
> Yes, as I noted, I also see this with -Q.
It seems that 'doc-view-new-window-function' fails in some way. This
time I have to CC Tassilo. Maybe he has a clue.
> 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.
Thanks.
>>> 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.)
Could you try to insert a backtrace into some buffer instead of the
error call in 'image-display-size'?
Sorry, I don't view images, pdfs or the like with Emacs. I can try
learning to do that but it would take some time.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 14:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 20 Jan 2019 15:20:39 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>>> Have you tried running 'doc-view-mode' without loading
>>> 'pdf-view-mode'?
>>
>> Yes, as I noted, I also see this with -Q.
>
> It seems that 'doc-view-new-window-function' fails in some way. This
> time I have to CC Tassilo. Maybe he has a clue.
I stepped through that function with Edebug but that failed to reproduce
the problem, instead, as expected, the "Welcome to DocView!" message
was briefly shown in the buffer and then then image.
>> 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.
>
> Thanks.
>
>>>> 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.)
>
> Could you try to insert a backtrace into some buffer instead of the
> error call in 'image-display-size'?
Thanks for the suggestion; I've attached the output.
Steve Berman
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 15:34:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Sun, 20 Jan 2019 15:55:01 +0100
> Cc: 34138 <at> debbugs.gnu.org, Andreas Politz <politza <at> hochschule-trier.de>,
> Tassilo Horn <tsdh <at> gnu.org>
>
> > It seems that 'doc-view-new-window-function' fails in some way. This
> > time I have to CC Tassilo. Maybe he has a clue.
>
> I stepped through that function with Edebug but that failed to reproduce
> the problem, instead, as expected, the "Welcome to DocView!" message
> was briefly shown in the buffer and then then image.
I think that's expected, since you said that pressing a key ends the
delay immediately. And stepping with Edebug requires that you type
keys.
If you configure blink-cursor-mode to never stop blinking, does the
problem go away, per chance?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 15:52:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Sun, 20 Jan 2019 17:32:47 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Sun, 20 Jan 2019 15:55:01 +0100
>> Cc: 34138 <at> debbugs.gnu.org, Andreas Politz <politza <at> hochschule-trier.de>,
>> Tassilo Horn <tsdh <at> gnu.org>
>>
>> > It seems that 'doc-view-new-window-function' fails in some way. This
>> > time I have to CC Tassilo. Maybe he has a clue.
>>
>> I stepped through that function with Edebug but that failed to reproduce
>> the problem, instead, as expected, the "Welcome to DocView!" message
>> was briefly shown in the buffer and then then image.
>
> I think that's expected, since you said that pressing a key ends the
> delay immediately. And stepping with Edebug requires that you type
> keys.
That makes sense. (Actually, I had mentioned keyboard input with
reference to pdf-view-mode, where the delay is quite long; with
doc-view-mode the delay is only a few seconds, so I hadn't try using the
keyboard, but now I did and it did in fact then immediately switch to
the "Welcome to DocView!" display briefly before displaying the image,
so keyboard input appears to have an effect with doc-view-mode as well.)
> If you configure blink-cursor-mode to never stop blinking, does the
> problem go away, per chance?
No, that made no difference either with doc-view-mode or with
pdf-view-mode.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 16:09:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de, tsdh <at> gnu.org
> Date: Sun, 20 Jan 2019 16:51:41 +0100
>
> That makes sense. (Actually, I had mentioned keyboard input with
> reference to pdf-view-mode, where the delay is quite long; with
> doc-view-mode the delay is only a few seconds, so I hadn't try using the
> keyboard, but now I did and it did in fact then immediately switch to
> the "Welcome to DocView!" display briefly before displaying the image,
> so keyboard input appears to have an effect with doc-view-mode as well.)
>
> > If you configure blink-cursor-mode to never stop blinking, does the
> > problem go away, per chance?
>
> No, that made no difference either with doc-view-mode or with
> pdf-view-mode.
Hmm... can you attach the debugger to Emacs during that delay, and
show both C backtrace and Lisp backtrace?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 16:32:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 20 Jan 2019 18:08:05 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de,
>> tsdh <at> gnu.org
>> Date: Sun, 20 Jan 2019 16:51:41 +0100
>>
>> That makes sense. (Actually, I had mentioned keyboard input with
>> reference to pdf-view-mode, where the delay is quite long; with
>> doc-view-mode the delay is only a few seconds, so I hadn't try using the
>> keyboard, but now I did and it did in fact then immediately switch to
>> the "Welcome to DocView!" display briefly before displaying the image,
>> so keyboard input appears to have an effect with doc-view-mode as well.)
>>
>> > If you configure blink-cursor-mode to never stop blinking, does the
>> > problem go away, per chance?
>>
>> No, that made no difference either with doc-view-mode or with
>> pdf-view-mode.
>
> Hmm... can you attach the debugger to Emacs during that delay, and
> show both C backtrace and Lisp backtrace?
I'm not sure what "attach the debugger to Emacs during that delay"
means, but what I did is to start emacs under gdb with my
initializations, then I opened a PDF file in pdf-view-mode, it showed
the raw PDF, at which point I typed C-z in gdb, then bt, then
xbacktrace, which showed nothing, then c, upon which the PDF image was
immediately shown, then I called bt again, but it looks like the same
backtrace, and xbacktrace again returned nothing. I've attached the
complete transcript. If you wanted me to do something else, please give
me step by step instructions.
Steve
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 16:51:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de, tsdh <at> gnu.org
> Date: Sun, 20 Jan 2019 17:31:13 +0100
>
> > Hmm... can you attach the debugger to Emacs during that delay, and
> > show both C backtrace and Lisp backtrace?
>
> I'm not sure what "attach the debugger to Emacs during that delay"
> means
It means, during the time of the delay, type from the shell prompt:
$ gdb -p PID
where PID is the numeric process-id of the Emacs process; you should
find that in advance, e.g. by running "ps". Once GDB starts and shows
its prompt, "(gdb)", type:
(gdb) thread apply all bt
This should show the C-level backtrace. Then:
(gdb) source /path/to/emacs/src/.gdbinit
(gdb) xbacktrace
The last command should show the Lisp-level backtrace.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 17:15:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 20 Jan 2019 18:50:00 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de,
>> tsdh <at> gnu.org
>> Date: Sun, 20 Jan 2019 17:31:13 +0100
>>
>> > Hmm... can you attach the debugger to Emacs during that delay, and
>> > show both C backtrace and Lisp backtrace?
>>
>> I'm not sure what "attach the debugger to Emacs during that delay"
>> means
>
> It means, during the time of the delay, type from the shell prompt:
>
> $ gdb -p PID
>
> where PID is the numeric process-id of the Emacs process; you should
> find that in advance, e.g. by running "ps". Once GDB starts and shows
> its prompt, "(gdb)", type:
>
> (gdb) thread apply all bt
>
> This should show the C-level backtrace. Then:
>
> (gdb) source /path/to/emacs/src/.gdbinit
> (gdb) xbacktrace
>
> The last command should show the Lisp-level backtrace.
Ah, thanks. I started gdb from the path of the emacs executable and the
Lisp backtrace was shown after typing "thread apply all bt";
subsequently typing xbacktrace showed no output. Transcript attached.
FWIW, while the backtrace was being shown in the shell, the raw PDF
changed to the image display in Emacs.
Steve Berman
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 17:44:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de, tsdh <at> gnu.org
> Date: Sun, 20 Jan 2019 18:14:13 +0100
>
> > It means, during the time of the delay, type from the shell prompt:
> >
> > $ gdb -p PID
> >
> > where PID is the numeric process-id of the Emacs process; you should
> > find that in advance, e.g. by running "ps". Once GDB starts and shows
> > its prompt, "(gdb)", type:
> >
> > (gdb) thread apply all bt
> >
> > This should show the C-level backtrace. Then:
> >
> > (gdb) source /path/to/emacs/src/.gdbinit
> > (gdb) xbacktrace
> >
> > The last command should show the Lisp-level backtrace.
>
> Ah, thanks. I started gdb from the path of the emacs executable and the
> Lisp backtrace was shown after typing "thread apply all bt";
Please start GDB from a directory other that the Emacs src directory,
I'd like to see the C backtrace that way.
> FWIW, while the backtrace was being shown in the shell, the raw PDF
> changed to the image display in Emacs.
I don't understand how could Emacs be running while GDB was showing
the backtrace. It shouldn't happen, because the executable to which
GDB is attached is supposed to be stopped in its tracks. What does
this show, after you attach GDB and GDB shows its prompt?
(gdb) show non-stop
It should say that non-stop mode is OFF.
> Lisp Backtrace:
> "image-size" (0x70824720)
> 0x354bf60 PVEC_COMPILED
> "gethash" (0x70820b38)
> "pdf-cache--data-get" (0x70820d40)
> "pdf-cache-number-of-pages" (0x70820f10)
> ---Type <return> to continue, or q <return> to quit---
> "terminal-live-p" (0x70820ea8)
> "framep-on-display" (0x708210b8)
> "overlayp" (0x70824718)
> 0x92591e8 PVEC_COMPILED
> "overlayp" (0x70824a48)
> 0x92591e8 PVEC_COMPILED
> "redisplay--update-region-highlight" (0x70824fd0)
> "run-hook-with-args" (0x70824fc8)
> "ignore" (0x70825310)
> "apply" (0x70825308)
> 0x9420638 PVEC_COMPILED
> "redisplay_internal (C function)" (0x0)
This Lisp backtrace contradicts the C backtrace of the main thread:
> Thread 1 (Thread 0x7f9109a29bc0 (LWP 5077)):
> #0 0x00007f910c590291 in __pselect (nfds=16, readfds=0x7ffc70826670, writefds=0x7ffc708265f0, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>)
> at ../sysdeps/unix/sysv/linux/pselect.c:69
> #1 0x00000000005bca5d in really_call_select (arg=arg <at> entry=0x7ffc70826130)
> at /mnt/data/steve/git/emacs-master/src/thread.c:580
> #2 0x0000000000542d88 in flush_stack_call_func (func=func <at> entry=0x5bca12 <really_call_select>, arg=arg <at> entry=0x7ffc70826130)
> at /mnt/data/steve/git/emacs-master/src/alloc.c:5229
> #3 0x00000000005bd24f in thread_select (func=<optimized out>, max_fds=max_fds <at> entry=16, rfds=rfds <at> entry=0x7ffc70826670, wfds=<optimized out>, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffc708268c0, sigmask=0x0)
> at /mnt/data/steve/git/emacs-master/src/thread.c:610
> #4 0x00000000005d7c64 in xg_select (fds_lim=16, rfds=rfds <at> entry=0x7ffc70826960,---Type <return> to continue, or q <return> to quit---
> wfds=0x7ffc708268e0, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffc708268c0, sigmask=sigmask <at> entry=0x0)
> at /mnt/data/steve/git/emacs-master/src/xgselect.c:117
> #5 0x000000000059daf3 in wait_reading_process_output (time_limit=time_limit <at> entry=97, nsecs=nsecs <at> entry=0, read_kbd=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=XIL(0), wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0) at /mnt/data/steve/git/emacs-master/src/process.c:5405
> #6 0x0000000000424e63 in sit_for (timeout=timeout <at> entry=make_number(97), reading=reading <at> entry=true, display_option=display_option <at> entry=1)
> at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
> #7 0x00000000004f769e in read_char (commandflag=1, map=map <at> entry=XIL(0x35f3093), prev_event=XIL(0), used_mouse_menu=used_mouse_menu <at> entry=0x7ffc70826d4b, end_time=end_time <at> entry=0x0) at /mnt/data/steve/git/emacs-master/src/lisp.h:751
> #8 0x00000000004f81ec in read_key_sequence (keybuf=keybuf <at> entry=0x7ffc70826e10, prompt=prompt <at> entry=XIL(0), dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false)
> at /mnt/data/steve/git/emacs-master/src/lisp.h:1386
> #9 0x00000000004f9730 in command_loop_1 ()
> at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
The C backtrace says we are idling, waiting for some input inside
pselect, while the Lisp backtrace says we are in the image-size
function, which was somehow invoked from pre-redisplay-function. I'm
confused...
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 17:56:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 34138 <at> debbugs.gnu.org (full text, mbox):
This
> backtrace()
> (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace))
> (cond ((and image slice) (if pixels (cons (nth 3 slice) (nth 4 slice)) (cons (/ (float (nth 3 slice)) (frame-char-width frame)) (/ (float (nth 4 slice)) (frame-char-height frame))))) (image (image-size image pixels frame)) (t (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace))))
> (let ((image (assoc 'image spec)) (slice (assoc 'slice spec))) (cond ((and image slice) (if pixels (cons (nth 3 slice) (nth 4 slice)) (cons (/ (float (nth 3 slice)) (frame-char-width frame)) (/ (float (nth 4 slice)) (frame-char-height frame))))) (image (image-size image pixels frame)) (t (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace)))))
> (cond ((eq (car spec) 'xwidget) (let ((xwi (xwidget-info (xwidget-at (point-min))))) (cons (aref xwi 2) (aref xwi 3)))) ((eq (car spec) 'image) (image-size spec pixels frame)) (t (let ((image (assoc 'image spec)) (slice (assoc 'slice spec))) (cond ((and image slice) (if pixels (cons (nth 3 slice) (nth 4 slice)) (cons (/ (float (nth 3 slice)) (frame-char-width frame)) (/ (float (nth 4 slice)) (frame-char-height frame))))) (image (image-size image pixels frame)) (t (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace)))))))
> image-display-size(nil t)
> pdf-view-image-size(t)
> pdf-misc-size-indication()
> eval((pdf-misc-size-indication))
> redisplay_internal\ \(C\ function\)()
> backtrace()
> (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace))
> (cond ((and image slice) (if pixels (cons (nth 3 slice) (nth 4 slice)) (cons (/ (float (nth 3 slice)) (frame-char-width frame)) (/ (float (nth 4 slice)) (frame-char-height frame))))) (image (image-size image pixels frame)) (t (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace))))
> (let ((image (assoc 'image spec)) (slice (assoc 'slice spec))) (cond ((and image slice) (if pixels (cons (nth 3 slice) (nth 4 slice)) (cons (/ (float (nth 3 slice)) (frame-char-width frame)) (/ (float (nth 4 slice)) (frame-char-height frame))))) (image (image-size image pixels frame)) (t (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace)))))
> (cond ((eq (car spec) 'xwidget) (let ((xwi (xwidget-info (xwidget-at (point-min))))) (cons (aref xwi 2) (aref xwi 3)))) ((eq (car spec) 'image) (image-size spec pixels frame)) (t (let ((image (assoc 'image spec)) (slice (assoc 'slice spec))) (cond ((and image slice) (if pixels (cons (nth 3 slice) (nth 4 slice)) (cons (/ (float (nth 3 slice)) (frame-char-width frame)) (/ (float (nth 4 slice)) (frame-char-height frame))))) (image (image-size image pixels frame)) (t (let ((standard-output (get-buffer-create "*PDF test*"))) (backtrace)))))))
> image-display-size(nil t)
> pdf-view-image-size(t)
> pdf-misc-size-indication()
> eval((pdf-misc-size-indication))
> posn-at-point(1 #<window 68 on fhs-2.3.pdf>)
> window-in-direction(below #<window 68 on fhs-2.3.pdf>)
reveals that the mode line is evaluated twice in your scenario - once
to get a window in a direction (where we call 'posn-at-point' to tell
where on your frame point currently is) and once from redisplay. I
don't know yet why 'image-get-display-property' apparently fails but
it looks like a good idea to me to wrap the 'image-display-size' call
in 'pdf-view-image-size' in 'ignore-errors' - evaluating a mode line
string should never throw an error (in paticular when it's only needed
to guess the height of the mode line).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 20:46:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, 20 Jan 2019 19:42:58 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de,
>> tsdh <at> gnu.org
>> Date: Sun, 20 Jan 2019 18:14:13 +0100
>>
>> > It means, during the time of the delay, type from the shell prompt:
>> >
>> > $ gdb -p PID
>> >
>> > where PID is the numeric process-id of the Emacs process; you should
>> > find that in advance, e.g. by running "ps". Once GDB starts and shows
>> > its prompt, "(gdb)", type:
>> >
>> > (gdb) thread apply all bt
>> >
>> > This should show the C-level backtrace. Then:
>> >
>> > (gdb) source /path/to/emacs/src/.gdbinit
>> > (gdb) xbacktrace
>> >
>> > The last command should show the Lisp-level backtrace.
>>
>> Ah, thanks. I started gdb from the path of the emacs executable and the
>> Lisp backtrace was shown after typing "thread apply all bt";
>
> Please start GDB from a directory other that the Emacs src directory,
> I'd like to see the C backtrace that way.
Ok, transcript attached. But now there's no Lisp backtrace (more on
this below).
>> FWIW, while the backtrace was being shown in the shell, the raw PDF
>> changed to the image display in Emacs.
>
> I don't understand how could Emacs be running while GDB was showing
> the backtrace. It shouldn't happen, because the executable to which
> GDB is attached is supposed to be stopped in its tracks. What does
> this show, after you attach GDB and GDB shows its prompt?
>
> (gdb) show non-stop
>
> It should say that non-stop mode is OFF.
It did say this. And this time the Emacs display did not change until
after continuing from gdb, then the PDF image was immediately displayed.
>> Lisp Backtrace:
>> "image-size" (0x70824720)
>> 0x354bf60 PVEC_COMPILED
>> "gethash" (0x70820b38)
>> "pdf-cache--data-get" (0x70820d40)
>> "pdf-cache-number-of-pages" (0x70820f10)
>> ---Type <return> to continue, or q <return> to quit---
>> "terminal-live-p" (0x70820ea8)
>> "framep-on-display" (0x708210b8)
>> "overlayp" (0x70824718)
>> 0x92591e8 PVEC_COMPILED
>> "overlayp" (0x70824a48)
>> 0x92591e8 PVEC_COMPILED
>> "redisplay--update-region-highlight" (0x70824fd0)
>> "run-hook-with-args" (0x70824fc8)
>> "ignore" (0x70825310)
>> "apply" (0x70825308)
>> 0x9420638 PVEC_COMPILED
>> "redisplay_internal (C function)" (0x0)
>
> This Lisp backtrace contradicts the C backtrace of the main thread:
>
>> Thread 1 (Thread 0x7f9109a29bc0 (LWP 5077)):
>> #0 0x00007f910c590291 in __pselect (nfds=16, readfds=0x7ffc70826670, writefds=0x7ffc708265f0, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>)
>> at ../sysdeps/unix/sysv/linux/pselect.c:69
>> #1 0x00000000005bca5d in really_call_select (arg=arg <at> entry=0x7ffc70826130)
>> at /mnt/data/steve/git/emacs-master/src/thread.c:580
>> #2 0x0000000000542d88 in flush_stack_call_func (func=func <at> entry=0x5bca12 <really_call_select>, arg=arg <at> entry=0x7ffc70826130)
>> at /mnt/data/steve/git/emacs-master/src/alloc.c:5229
>> #3 0x00000000005bd24f in thread_select (func=<optimized out>, max_fds=max_fds <at> entry=16, rfds=rfds <at> entry=0x7ffc70826670, wfds=<optimized out>, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffc708268c0, sigmask=0x0)
>> at /mnt/data/steve/git/emacs-master/src/thread.c:610
>> #4 0x00000000005d7c64 in xg_select (fds_lim=16, rfds=rfds <at> entry=0x7ffc70826960,---Type <return> to continue, or q <return> to quit---
>> wfds=0x7ffc708268e0, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffc708268c0, sigmask=sigmask <at> entry=0x0)
>> at /mnt/data/steve/git/emacs-master/src/xgselect.c:117
>> #5 0x000000000059daf3 in wait_reading_process_output (time_limit=time_limit <at> entry=97, nsecs=nsecs <at> entry=0, read_kbd=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=XIL(0), wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0) at /mnt/data/steve/git/emacs-master/src/process.c:5405
>> #6 0x0000000000424e63 in sit_for (timeout=timeout <at> entry=make_number(97), reading=reading <at> entry=true, display_option=display_option <at> entry=1)
>> at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
>> #7 0x00000000004f769e in read_char (commandflag=1, map=map <at> entry=XIL(0x35f3093), prev_event=XIL(0), used_mouse_menu=used_mouse_menu <at> entry=0x7ffc70826d4b, end_time=end_time <at> entry=0x0) at /mnt/data/steve/git/emacs-master/src/lisp.h:751
>> #8 0x00000000004f81ec in read_key_sequence (keybuf=keybuf <at> entry=0x7ffc70826e10, prompt=prompt <at> entry=XIL(0), dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false)
>> at /mnt/data/steve/git/emacs-master/src/lisp.h:1386
>> #9 0x00000000004f9730 in command_loop_1 ()
>> at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
>
> The C backtrace says we are idling, waiting for some input inside
> pselect, while the Lisp backtrace says we are in the image-size
> function, which was somehow invoked from pre-redisplay-function. I'm
> confused...
As mentioned and as the transcript shows, there was no Lisp backtrace
this time. I then tried again, starting emacs from the shell in the
emacs/src path, and the gdb session was the same as above: non-stop off,
no Lisp backtrace, and emacs display changed only after continuing from
gdb. Then I repeated exactly what I did for my previous post: started
Emacs from the window manager menu (openbox), started gdb from the emacs
executable path in the shell, and again, non-stop was off and again
there was no Lisp backtrace, but this time, the buffer display did
change to the PDF image while the backtrace was being shown. Maybe
there's a race condition involved in the delay. I guess that doesn't
diminish your confusion...
Steve Berman
[Message part 2 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sun, 20 Jan 2019 20:46:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Sun, 20 Jan 2019 18:55:16 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
> This
>
>> backtrace()
[...]
>
> reveals that the mode line is evaluated twice in your scenario - once
> to get a window in a direction (where we call 'posn-at-point' to tell
> where on your frame point currently is) and once from redisplay. I
> don't know yet why 'image-get-display-property' apparently fails but
> it looks like a good idea to me to wrap the 'image-display-size' call
> in 'pdf-view-image-size' in 'ignore-errors' - evaluating a mode line
> string should never throw an error (in paticular when it's only needed
> to guess the height of the mode line).
I tried that but it made no difference to the delay. I the instrumented
pdf-view-image-size with the changes and visited a PDF file, but Edebug
did not kick in, so it seems that pdf-view-image-size is not called when
initially visiting a PDF file.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 06:12:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 34138 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> Have you tried running 'doc-view-mode' without loading
>>> 'pdf-view-mode'?
>>
>> Yes, as I noted, I also see this with -Q.
>
> It seems that 'doc-view-new-window-function' fails in some way. This
> time I have to CC Tassilo. Maybe he has a clue.
No, sorry, not really. I've tried reproducing Stephen's issue both with
-Q (using doc-view) and with my configuration (which also uses
pdf-view-mode). But for me the greeting text and then the image of the
first page for doc-view or the image of the first page for pdf-view-mode
are displayed without any delay.
I'm running the current master, 5961e4fa42.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 07:53:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> I tried that but it made no difference to the delay. I the instrumented
> pdf-view-image-size with the changes and visited a PDF file, but Edebug
> did not kick in, so it seems that pdf-view-image-size is not called when
> initially visiting a PDF file.
I didn't expect Edebug to kick in. The 'ignore-errors' should serve
to avoid complications from the fact that redisplay has to process a
broken mode line string. Anyway, please make sure that
'display-buffer-split-below-and-attach' in pdf-util.el does call
‘window--display-buffer’ without the final
display-buffer-mark-dedicated argument so we can make sure that this
bug doesn't interfere with further investigations.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 07:53:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 34138 <at> debbugs.gnu.org (full text, mbox):
>> It seems that 'doc-view-new-window-function' fails in some way. This
>> time I have to CC Tassilo. Maybe he has a clue.
>
> No, sorry, not really. I've tried reproducing Stephen's issue both with
> -Q (using doc-view) and with my configuration (which also uses
> pdf-view-mode). But for me the greeting text and then the image of the
> first page for doc-view or the image of the first page for pdf-view-mode
> are displayed without any delay.
>
> I'm running the current master, 5961e4fa42.
Strange because Andreas said that he can reproduce it as well. I'm
afraid we have to wait for further people to kick in to get a common
pattern of why this can fail. To me this looks like a race condition
where with the old window configuration change convention the image
producing system was reliably incapable of providing the image at the
time the hook was run while with the new convention the image may have
been already produced at the time the hook is run.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 15:21:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 08:52:19 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>> I tried that but it made no difference to the delay. I the instrumented
>> pdf-view-image-size with the changes and visited a PDF file, but Edebug
>> did not kick in, so it seems that pdf-view-image-size is not called when
>> initially visiting a PDF file.
>
> I didn't expect Edebug to kick in. The 'ignore-errors' should serve
> to avoid complications from the fact that redisplay has to process a
> broken mode line string.
Ok.
> Anyway, please make sure that
> 'display-buffer-split-below-and-attach' in pdf-util.el does call
> ‘window--display-buffer’ without the final
> display-buffer-mark-dedicated argument so we can make sure that this
> bug doesn't interfere with further investigations.
I've done that with my local installation.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 15:21:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 08:52:28 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>>> It seems that 'doc-view-new-window-function' fails in some way. This
>>> time I have to CC Tassilo. Maybe he has a clue.
>>
>> No, sorry, not really. I've tried reproducing Stephen's issue both with
>> -Q (using doc-view) and with my configuration (which also uses
>> pdf-view-mode). But for me the greeting text and then the image of the
>> first page for doc-view or the image of the first page for pdf-view-mode
>> are displayed without any delay.
>>
>> I'm running the current master, 5961e4fa42.
>
> Strange because Andreas said that he can reproduce it as well. I'm
> afraid we have to wait for further people to kick in to get a common
> pattern of why this can fail. To me this looks like a race condition
> where with the old window configuration change convention the image
> producing system was reliably incapable of providing the image at the
> time the hook was run while with the new convention the image may have
> been already produced at the time the hook is run.
It does seem like a race condition. I also had this suspicion after
getting surprising and seemingly conflicting gdb backtraces that Eli
asked for.
Perhaps further evidence in this direction comes from two new
observations I have made: there is no delay when visiting a PDF file via
bookmark-jump or when opening a PDF attachment in Gnus. I tried
stepping through the respective functions called in these cases
(pdf-view-bookmark-jump-handler and mm-display-external) but didn't see
why the behavior differs, which again suggests it's in redisplay.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 16:00:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de, tsdh <at> gnu.org
> Date: Sun, 20 Jan 2019 21:45:06 +0100
>
> > Please start GDB from a directory other that the Emacs src directory,
> > I'd like to see the C backtrace that way.
>
> Ok, transcript attached. But now there's no Lisp backtrace (more on
> this below).
>
> Thread 1 (Thread 0x7fda7bf18bc0 (LWP 5399)):
> #0 0x00007fda7ea7f291 in __pselect (nfds=16, readfds=0x7ffd68a79c30, writefds=0x7ffd68a79bb0, exceptfds=0x0, timeout=<optimized out>, sigmask=<optimized out>)
> at ../sysdeps/unix/sysv/linux/pselect.c:69
> #1 0x00000000005bca5d in really_call_select (arg=arg <at> entry=0x7ffd68a796f0)
> at /mnt/data/steve/git/emacs-master/src/thread.c:580
> #2 0x0000000000542d88 in flush_stack_call_func (func=func <at> entry=0x5bca12 <really_call_select>, arg=arg <at> entry=0x7ffd68a796f0)
> at /mnt/data/steve/git/emacs-master/src/alloc.c:5229
> #3 0x00000000005bd24f in thread_select (func=<optimized out>, max_fds=max_fds <at> entry=16, rfds=rfds <at> entry=0x7ffd68a79c30, wfds=<optimized out>, efds=efds <at> entry=0---Type <return> to continue, or q <return> to quit---
> x0, timeout=timeout <at> entry=0x7ffd68a79e80, sigmask=0x0)
> at /mnt/data/steve/git/emacs-master/src/thread.c:610
> #4 0x00000000005d7c64 in xg_select (fds_lim=16, rfds=rfds <at> entry=0x7ffd68a79f20, wfds=0x7ffd68a79ea0, efds=efds <at> entry=0x0, timeout=timeout <at> entry=0x7ffd68a79e80, sigmask=sigmask <at> entry=0x0)
> at /mnt/data/steve/git/emacs-master/src/xgselect.c:117
> #5 0x000000000059daf3 in wait_reading_process_output (time_limit=time_limit <at> entry=172, nsecs=nsecs <at> entry=0, read_kbd=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=0x0, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0) at /mnt/data/steve/git/emacs-master/src/process.c:5405
> #6 0x0000000000424e63 in sit_for (timeout=timeout <at> entry=0x2b2, reading=reading <at> entry=true, display_option=display_option <at> entry=1)
> at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
> #7 0x00000000004f769e in read_char (commandflag=1, map=map <at> entry=0x3563eb3, prev_event=0x0, used_mouse_menu=used_mouse_menu <at> entry=0x7ffd68a7a30b, end_time=end_time <at> entry=0x0) at /mnt/data/steve/git/emacs-master/src/lisp.h:751
> #8 0x00000000004f81ec in read_key_sequence (keybuf=keybuf <at> entry=0x7ffd68a7a3d0, prompt=prompt <at> entry=0x0, dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false)
> at /mnt/data/steve/git/emacs-master/src/lisp.h:1386
> #9 0x00000000004f9730 in command_loop_1 ()
> at /mnt/data/steve/git/emacs-master/src/lisp.h:1056
Still weird: this says that Emacs simply waits for any input to
arrive, a.k.a. "is idle".
You've mentioned before that one of the two scenarios where you see
this problem produces a much longer delay -- could you repeat the same
procedure during that long delay, and show the backtrace from that
session? Maybe we will see something more interesting there.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 16:14:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 17:58:48 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de,
>> tsdh <at> gnu.org
>> Date: Sun, 20 Jan 2019 21:45:06 +0100
>>
>> > Please start GDB from a directory other that the Emacs src directory,
>> > I'd like to see the C backtrace that way.
>>
>> Ok, transcript attached. But now there's no Lisp backtrace (more on
>> this below).
[...]
>
> Still weird: this says that Emacs simply waits for any input to
> arrive, a.k.a. "is idle".
>
> You've mentioned before that one of the two scenarios where you see
> this problem produces a much longer delay -- could you repeat the same
> procedure during that long delay, and show the backtrace from that
> session? Maybe we will see something more interesting there.
This (and all the other backtraces I posted or mentioned) was from the
scenario where I see the long delay, i.e. using pdf-view-mode; with
doc-view-mode, the delay is so short (a couple of seconds) that it may
be difficult to switch from the Emacs GUI to the shell and invoke gdb
before the image is displayed.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 16:37:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de, tsdh <at> gnu.org
> Date: Mon, 21 Jan 2019 17:13:05 +0100
>
> > Still weird: this says that Emacs simply waits for any input to
> > arrive, a.k.a. "is idle".
> >
> > You've mentioned before that one of the two scenarios where you see
> > this problem produces a much longer delay -- could you repeat the same
> > procedure during that long delay, and show the backtrace from that
> > session? Maybe we will see something more interesting there.
>
> This (and all the other backtraces I posted or mentioned) was from the
> scenario where I see the long delay, i.e. using pdf-view-mode
So does it mean that during this time Emacs waits for the external
process (is it Ghostscript? ImageMagick?) to complete? That's all I
see in the backtrace.
Can you establish (e.g., by adding 'message' lines to the Lisp source)
where in the pdf-view-mode's sources this delay starts? IOW, what is
the last thing pdf-view-mode does before the delay begins?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 18:19:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 18:36:37 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de,
>> tsdh <at> gnu.org
>> Date: Mon, 21 Jan 2019 17:13:05 +0100
>>
>> > Still weird: this says that Emacs simply waits for any input to
>> > arrive, a.k.a. "is idle".
>> >
>> > You've mentioned before that one of the two scenarios where you see
>> > this problem produces a much longer delay -- could you repeat the same
>> > procedure during that long delay, and show the backtrace from that
>> > session? Maybe we will see something more interesting there.
>>
>> This (and all the other backtraces I posted or mentioned) was from the
>> scenario where I see the long delay, i.e. using pdf-view-mode
>
> So does it mean that during this time Emacs waits for the external
> process (is it Ghostscript? ImageMagick?) to complete? That's all I
> see in the backtrace.
Not Ghostscript but the PDF rendering library Poppler; I think
ImageMagick can be used for some functionality, but it's not required.
But Andreas Politza can surely answer this best and provide more details.
> Can you establish (e.g., by adding 'message' lines to the Lisp source)
> where in the pdf-view-mode's sources this delay starts? IOW, what is
> the last thing pdf-view-mode does before the delay begins?
I don't know where it makes sense to output messages. I did step
through pdf-view-mode and the last function it calls,
pdf-view-goto-page, but when that function returns it's just the raw PDF
that's displayed. I then instrumented all pdf-view defuns and while
stepping though, the PDF image appeared on calling
pdf-view-maybe-redisplay-resized-windows, which is added to
window-configuration-change-hook in pdf-view-mode. So it appears that
the delay starts between pdf-view-goto-page returning and
pdf-view-maybe-redisplay-resized-windows being called, but when stepping
through the long call chain, I did not see the transition (no raw PDF
was displayed, just the rendered image at the end).
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 18:44:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, politza <at> hochschule-trier.de, tsdh <at> gnu.org
> Date: Mon, 21 Jan 2019 19:17:53 +0100
>
> > Can you establish (e.g., by adding 'message' lines to the Lisp source)
> > where in the pdf-view-mode's sources this delay starts? IOW, what is
> > the last thing pdf-view-mode does before the delay begins?
>
> I don't know where it makes sense to output messages. I did step
> through pdf-view-mode and the last function it calls,
> pdf-view-goto-page, but when that function returns it's just the raw PDF
> that's displayed. I then instrumented all pdf-view defuns and while
> stepping though, the PDF image appeared on calling
> pdf-view-maybe-redisplay-resized-windows, which is added to
> window-configuration-change-hook in pdf-view-mode. So it appears that
> the delay starts between pdf-view-goto-page returning and
> pdf-view-maybe-redisplay-resized-windows being called, but when stepping
> through the long call chain, I did not see the transition (no raw PDF
> was displayed, just the rendered image at the end).
So you are saying that the image is displayed by a function that is on
window-configuration-change-hook? If so, what change in the window
configuration is supposed to trigger the hook in your scenario? (I
think I'm missing something, because I don't see how it would make
sense to display PDF documents from that particular hook.)
In any case, is it certain that once
pdf-view-maybe-redisplay-resized-windows starts running, the image is
displayed immediately without delays?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 18:49:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> pdf-view-maybe-redisplay-resized-windows, which is added to
> window-configuration-change-hook in pdf-view-mode.
What happens when you remove
(> (minibuffer-depth) 0)
from the first conjunction in
'pdf-view-maybe-redisplay-resized-windows'?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 19:15:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 34138 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> In any case, is it certain that once
> pdf-view-maybe-redisplay-resized-windows starts running, the image is
> displayed immediately without delays?
I don't think that pdf-view-maybe-redisplay-resized-windows is related
to this problem. It does basically nothing on the first call, except
store the window's size, i.e. no redisplay.
pdf-tools, like doc-view, uses image-mode to manage the displayed image
of the current pdf page. I.e. it adds a function to the hook
image-mode-new-window-functions.
image-mode uses window-configuration-change-hook to check whether a new
window for the buffer it was activated for was created. In this case it
runs the hook image-mode-new-window-functions. This is the hook
pdf-tools attaches itself to in order to create an overlay with a window
property and the image of the current page.
Usually, i.e. in Emacs 26.1, this is sufficient for the image to be
visible immediately (or at least immediately after the function has
returned and Emacs is idle). Conversely, in the current master branch,
the image is not visible until, as it seems, the next redraw cycle.
Note, that I don't see a delay. Rather nothing seems to happen until I
trigger a redisplay, for example via M-x.
I also traced the mentioned function (pdf-view-new-window-function) and
verified that there is no different in both Emacs versions regarding the
number of times they are called and the nature of their arguments. The
trace, opening a PDF document in a single windowed frame via dired,
looks like this
======================================================================
1 -> (pdf-view-new-window-function (t))
1 <- pdf-view-new-window-function: #<overlay in no buffer>
======================================================================
1 -> (pdf-view-new-window-function (#<window 3 on The_Joy_of_Clojure.pdf> (page . 1) (overlay . #<overlay in no buffer>)))
1 <- pdf-view-new-window-function: #<overlay from 1 to 9221925 in The_Joy_of_Clojure.pdf>
The first call happens when pdf-view-mode initiates image-mode. The car
of argument is usually a window. Unless the buffer is not displayed, in
which case t is used. The cdr is a property list.
The second call creates the relevant overlay with the image property.
Note that I modified the function to return the used overlay, usually it
returns nil.
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 19:20:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 34138 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> pdf-view-maybe-redisplay-resized-windows, which is added to
>> window-configuration-change-hook in pdf-view-mode.
>
> What happens when you remove
>
> (> (minibuffer-depth) 0)
>
> from the first conjunction in
> 'pdf-view-maybe-redisplay-resized-windows'?
I commented the addition of this function the
window-configuration-change-hook out. It does not change the behavior
(image displayed in 26.1, no image in HEAD).
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 19:48:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Politz <politza <at> hochschule-trier.de>
> Cc: Stephen Berman <stephen.berman <at> gmx.net>, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
> Date: Mon, 21 Jan 2019 20:14:07 +0100
>
> image-mode uses window-configuration-change-hook to check whether a new
> window for the buffer it was activated for was created. In this case it
> runs the hook image-mode-new-window-functions. This is the hook
> pdf-tools attaches itself to in order to create an overlay with a window
> property and the image of the current page.
>
> Usually, i.e. in Emacs 26.1, this is sufficient for the image to be
> visible immediately (or at least immediately after the function has
> returned and Emacs is idle). Conversely, in the current master branch,
> the image is not visible until, as it seems, the next redraw cycle.
>
> Note, that I don't see a delay. Rather nothing seems to happen until I
> trigger a redisplay, for example via M-x.
So it's indeed a redisplay problem. Can you build both Emacs 26 and
Emacs 27 with --enable-checking, then disable blink-cursor-mode and
global-eldoc-mode, then invoke "M-x trace-redisplay", and show the
trace displayed on stderr in both versions when you visit a PDF file?
Please invoke trace-redisplay _before_ you visit the PDF file. I'm
especially interested in what happens in Emacs 27 after you visit the
PDF file, but _before_ you type "M-x" that causes the image to be
displayed. IOW, what trace do you see after visiting the PDF file
during that time that "nothing seems to happen", as compared to what
happens in Emacs 26.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 20:34:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 20:14:07 +0100 Andreas Politz <politza <at> hochschule-trier.de> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> In any case, is it certain that once
>> pdf-view-maybe-redisplay-resized-windows starts running, the image is
>> displayed immediately without delays?
>
> I don't think that pdf-view-maybe-redisplay-resized-windows is related
> to this problem. It does basically nothing on the first call, except
> store the window's size, i.e. no redisplay.
Yes. What I wrote was perhaps unclear, I meant that the image is
displayed on entering pdf-view-maybe-redisplay-resized-windows but
before any of its code is run. Just before the image appeared, the
execution was in pdf-view-redisplay, the last line of which is
(force-mode-line-update). Then the image appears and execution enters
pdf-view-maybe-redisplay-resized-windows.
[...]
> Note, that I don't see a delay. Rather nothing seems to happen until I
> trigger a redisplay, for example via M-x.
How long do you wait? On my machine, which is slow, it seems to take at
least 30-45 seconds or even longer, depending on the size of the file,
but eventually the image does appear without keyboard input.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 20:34:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 20:19:02 +0100 Andreas Politz <politza <at> hochschule-trier.de> wrote:
> martin rudalics <rudalics <at> gmx.at> writes:
>
>>> pdf-view-maybe-redisplay-resized-windows, which is added to
>>> window-configuration-change-hook in pdf-view-mode.
>>
>> What happens when you remove
>>
>> (> (minibuffer-depth) 0)
>>
>> from the first conjunction in
>> 'pdf-view-maybe-redisplay-resized-windows'?
>
> I commented the addition of this function the
> window-configuration-change-hook out. It does not change the behavior
> (image displayed in 26.1, no image in HEAD).
FTR I confirm pdf-view-maybe-redisplay-resized-windows plays no role; as
I clarified in another followup, the image appears before any code in
this function is executed.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 20:37:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
> Date: Mon, 21 Jan 2019 21:33:25 +0100
>
> > Note, that I don't see a delay. Rather nothing seems to happen until I
> > trigger a redisplay, for example via M-x.
>
> How long do you wait? On my machine, which is slow, it seems to take at
> least 30-45 seconds or even longer, depending on the size of the file,
> but eventually the image does appear without keyboard input.
That could be due to an unrelated event that happens only on your
system. Like some X event or D-Bus or whatever.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 20:44:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Mon, 21 Jan 2019 22:35:54 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org,
>> tsdh <at> gnu.org
>> Date: Mon, 21 Jan 2019 21:33:25 +0100
>>
>> > Note, that I don't see a delay. Rather nothing seems to happen until I
>> > trigger a redisplay, for example via M-x.
>>
>> How long do you wait? On my machine, which is slow, it seems to take at
>> least 30-45 seconds or even longer, depending on the size of the file,
>> but eventually the image does appear without keyboard input.
>
> That could be due to an unrelated event that happens only on your
> system. Like some X event or D-Bus or whatever.
Ah, interesting. Is there any way for me to verify that?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 21:30:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 34138 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman <stephen.berman <at> gmx.net> writes:
> On Mon, 21 Jan 2019 22:35:54 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> That could be due to an unrelated event that happens only on your
>> system. Like some X event or D-Bus or whatever.
>
> Ah, interesting. Is there any way for me to verify that?
Emacs is clearly idle when this happens, so it must be some event.
Anyway, I waited 5 min and nothing happens.
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Mon, 21 Jan 2019 22:29:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, 21 Jan 2019 21:47:21 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Andreas Politz <politza <at> hochschule-trier.de>
>> Cc: Stephen Berman <stephen.berman <at> gmx.net>, rudalics <at> gmx.at,
>> 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
>> Date: Mon, 21 Jan 2019 20:14:07 +0100
>>
>> image-mode uses window-configuration-change-hook to check whether a new
>> window for the buffer it was activated for was created. In this case it
>> runs the hook image-mode-new-window-functions. This is the hook
>> pdf-tools attaches itself to in order to create an overlay with a window
>> property and the image of the current page.
>>
>> Usually, i.e. in Emacs 26.1, this is sufficient for the image to be
>> visible immediately (or at least immediately after the function has
>> returned and Emacs is idle). Conversely, in the current master branch,
>> the image is not visible until, as it seems, the next redraw cycle.
>>
>> Note, that I don't see a delay. Rather nothing seems to happen until I
>> trigger a redisplay, for example via M-x.
>
> So it's indeed a redisplay problem. Can you build both Emacs 26 and
> Emacs 27 with --enable-checking, then disable blink-cursor-mode and
> global-eldoc-mode, then invoke "M-x trace-redisplay", and show the
> trace displayed on stderr in both versions when you visit a PDF file?
> Please invoke trace-redisplay _before_ you visit the PDF file. I'm
> especially interested in what happens in Emacs 27 after you visit the
> PDF file, but _before_ you type "M-x" that causes the image to be
> displayed. IOW, what trace do you see after visiting the PDF file
> during that time that "nothing seems to happen", as compared to what
> happens in Emacs 26.
I did this and have attached the traces. Both show the PDF files (I
used different ones in each Emacs) being opened early in the trace: in
emacs-26 the image was immediately displayed and the trace continued and
then paused and I killed emacs; in emacs-master the first trace lines
showing the PDF file correspond to the raw PDF being displayed,
following by the same kind of trace lines as in emacs-26, but then two
lines with the PDF file again, which is when the image display appeared,
after which the trace paused and I killed emacs. As in all my other
test runs, here again the image appeared without any keyboard input, but
interestingly and surprisingly, this time it took less than 10 seconds,
as compared to 30-60 seconds in most of the other runs (which were
without tracing).
Steve Berman
[Message part 2 (text/plain, attachment)]
[Message part 3 (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Tue, 22 Jan 2019 18:38:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Andreas Politz <politza <at> hochschule-trier.de>, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
> Date: Mon, 21 Jan 2019 23:27:58 +0100
>
> I did this and have attached the traces. Both show the PDF files (I
> used different ones in each Emacs) being opened early in the trace: in
> emacs-26 the image was immediately displayed and the trace continued and
> then paused and I killed emacs; in emacs-master the first trace lines
> showing the PDF file correspond to the raw PDF being displayed,
> following by the same kind of trace lines as in emacs-26, but then two
> lines with the PDF file again, which is when the image display appeared,
> after which the trace paused and I killed emacs. As in all my other
> test runs, here again the image appeared without any keyboard input, but
> interestingly and surprisingly, this time it took less than 10 seconds,
> as compared to 30-60 seconds in most of the other runs (which were
> without tracing).
Thanks.
I have a theory, but I need evidence to convince myself that my theory
is sound. I need to see where in the series of traces produced by
trace-redisplay we call run_window_configuration_change_hook, in both
versions of Emacs.
So could you please add the following 2 lines:
fprintf (stderr, "run_window_configuration_change_hook: %p\n", f);
fflush (stderr);
into the very beginning of run_window_configuration_change_hook (it is
in src/window.c), compile both versions of Emacs, and run the same
scenario again. Then please show the traces, where the above message
should be visible somewhere among the other trace messages.
P.S. Any reason why one trace shows R-lang.pdf, whereas the other
R-data.pdf?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Tue, 22 Jan 2019 22:01:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 22 Jan 2019 18:25:23 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Andreas Politz <politza <at> hochschule-trier.de>, rudalics <at> gmx.at,
>> 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
>> Date: Mon, 21 Jan 2019 23:27:58 +0100
>>
>> I did this and have attached the traces. Both show the PDF files (I
>> used different ones in each Emacs) being opened early in the trace: in
>> emacs-26 the image was immediately displayed and the trace continued and
>> then paused and I killed emacs; in emacs-master the first trace lines
>> showing the PDF file correspond to the raw PDF being displayed,
>> following by the same kind of trace lines as in emacs-26, but then two
>> lines with the PDF file again, which is when the image display appeared,
>> after which the trace paused and I killed emacs. As in all my other
>> test runs, here again the image appeared without any keyboard input, but
>> interestingly and surprisingly, this time it took less than 10 seconds,
>> as compared to 30-60 seconds in most of the other runs (which were
>> without tracing).
>
> Thanks.
>
> I have a theory, but I need evidence to convince myself that my theory
> is sound. I need to see where in the series of traces produced by
> trace-redisplay we call run_window_configuration_change_hook, in both
> versions of Emacs.
>
> So could you please add the following 2 lines:
>
> fprintf (stderr, "run_window_configuration_change_hook: %p\n", f);
> fflush (stderr);
>
> into the very beginning of run_window_configuration_change_hook (it is
> in src/window.c), compile both versions of Emacs, and run the same
> scenario again. Then please show the traces, where the above message
> should be visible somewhere among the other trace messages.
Attached. It's striking that in the emacs-26 trace
run_window_configuration_change_hook is called just once, before the PDF
(image) is displayed, while in the emacs-master trace it's called once
before the (raw) PDF is displayed and again immediately after that, but
not again when the display changes to the image. Does that accord with
your theory?
> P.S. Any reason why one trace shows R-lang.pdf, whereas the other
> R-data.pdf?
I made the emacs-26 trace first, and wanted to exclude the possibility
that there could be some trace of the PDF in the machine memory that
could affect the emacs-master trace (no idea if that is possible). This
time I made the emacs-master trace first and used the same file for the
emacs-26 trace. This time with emacs-master about 25 seconds elapsed
between the raw PDF appearing in the buffer and the image appearing
(again without keyboard intervention). Immediately after that, the
trace stopped for a number of seconds (I didn't time it but I guess
5-10), then it printed:
redisplay_preserve_echo_area (8)
redisplay_internal 0
and then I killed the buffer. As the emacs-26 trace shows, after the
PDF image appeared (which it did without the raw PDF being displayed),
the trace rapidly produced another 50 lines of output (included in the
attachment) before pausing, after which I killed emacs.
Steve Berman
[trace-emacs-26 (application/octet-stream, attachment)]
[trace-emacs-master (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 14:33:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 22 Jan 2019 22:54:16 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Tue, 22 Jan 2019 18:25:23 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> I have a theory, but I need evidence to convince myself that my theory
>> is sound. I need to see where in the series of traces produced by
>> trace-redisplay we call run_window_configuration_change_hook, in both
>> versions of Emacs.
>>
>> So could you please add the following 2 lines:
>>
>> fprintf (stderr, "run_window_configuration_change_hook: %p\n", f);
>> fflush (stderr);
>>
>> into the very beginning of run_window_configuration_change_hook (it is
>> in src/window.c), compile both versions of Emacs, and run the same
>> scenario again. Then please show the traces, where the above message
>> should be visible somewhere among the other trace messages.
>
> Attached. It's striking that in the emacs-26 trace
> run_window_configuration_change_hook is called just once, before the PDF
> (image) is displayed, while in the emacs-master trace it's called once
> before the (raw) PDF is displayed and again immediately after that, but
> not again when the display changes to the image. Does that accord with
> your theory?
I found that the following patch to pdf-view-goto-page eliminates the
display of raw PDF and the delay of the image display:
*** /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el.orig 2019-01-21 15:56:08.033335212 +0100
--- /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el 2019-01-23 14:54:52.381373638 +0100
***************
*** 624,629 ****
--- 624,630 ----
(pdf-view-deactivate-region)
(force-mode-line-update)
(run-hooks 'pdf-view-after-change-page-hook))))
+ (switch-to-buffer (current-buffer))
nil)
(defun pdf-view-next-page (&optional n)
I assume this is only a workaround. I've also attached the redisplay
trace using this patch; it looks almost the same as the trace without
this patch except for lacking the repetition of the PDF buffer display
(which is where the change to the image display occurs without the
patch).
Steve Berman
[trace-emacs-master-2 (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 16:14:01 GMT)
Full text and
rfc822 format available.
Message #125 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: politza <at> hochschule-trier.de, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
> Date: Tue, 22 Jan 2019 23:00:01 +0100
>
> > So could you please add the following 2 lines:
> >
> > fprintf (stderr, "run_window_configuration_change_hook: %p\n", f);
> > fflush (stderr);
> >
> > into the very beginning of run_window_configuration_change_hook (it is
> > in src/window.c), compile both versions of Emacs, and run the same
> > scenario again. Then please show the traces, where the above message
> > should be visible somewhere among the other trace messages.
>
> Attached. It's striking that in the emacs-26 trace
> run_window_configuration_change_hook is called just once, before the PDF
> (image) is displayed, while in the emacs-master trace it's called once
> before the (raw) PDF is displayed and again immediately after that, but
> not again when the display changes to the image. Does that accord with
> your theory?
Yes, sort of. (The first invocation of
run_window_configuration_change_hook is AFAIU not relevant to the
issue at hand, it's about a different buffer, called "manual". Only
the second call is relevant.)
Here's my theory: in Emacs 26, run_window_configuration_change_hook is
called from various functions in window.c, which are called from Lisp,
i.e. by definition _before_ redisplay. The recent changes installed
by Martin replace all those calls in window.c by simply setting a
flag, which is then tested in run_window_change_functions, which now
calls run_window_configuration_change_hook. The crucial aspect of
this change is that run_window_change_functions is called at the very
end of a redisplay cycle, after redisplay_internal already finished
examining all the windows, and after the call to update_frame which
delivers the necessary changes to the glass.
Now, image-mode works by changing an overlay. Changes in overlays are
examined by the display engine, and windows displaying buffers where
overlays have been changed have the corresponding portions redrawn.
Windows that don't have any overlay changes and whose buffer text
didn't change are skipped by redisplay, on the assumption that nothing
has changed in them that requires displaying some of its part anew.
And since run_window_configuration_change_hook is called only _after_
the display engine already examined the windows, it cannot trigger
redisplay of the window where we show the image of the PDF document.
Thus, the image is shown only upon next more or less thorough
redisplay, which redraws the window in question.
Therefore, a question to Martin: why was the call to
run_window_change_functions put at the very end of redisplay_internal?
Is this intentional, and if so, what were the reasons for that?
If there are good reasons for keeping the call where it is now (e.g.,
moving it to beginning of the redisplay cycle will harm some
legitimate use cases), we will have to come with some complementary
measures to avoid breaking image-mode and its ilk.
> This time with emacs-master about 25 seconds elapsed
> between the raw PDF appearing in the buffer and the image appearing
> (again without keyboard intervention). Immediately after that, the
> trace stopped for a number of seconds (I didn't time it but I guess
> 5-10), then it printed:
> redisplay_preserve_echo_area (8)
> redisplay_internal 0
These two traces are not in the trace you posted, right? Because the
Emacs 27 trace ends with this:
> redisplay_preserve_echo_area (9)
> redisplay_internal 0
> 0x2a01550 (R-admin.pdf): same window start
> 0x2a01550 (R-admin.pdf): 1
which I believe is the first redisplay cycle which shows the image.
Right?
> and then I killed the buffer. As the emacs-26 trace shows, after the
> PDF image appeared (which it did without the raw PDF being displayed),
> the trace rapidly produced another 50 lines of output (included in the
> attachment) before pausing, after which I killed emacs.
Most of the traces come from the code that invokes timers, so I think
you have timers running which eventually trigger redisplay, something
that doesn't happen on Andreas's machine. That might explain why you
see the image after a short delay, while Andreas needs to manually
trigger redisplay for that.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 16:27:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: politza <at> hochschule-trier.de, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
> Date: Wed, 23 Jan 2019 15:31:54 +0100
>
> I found that the following patch to pdf-view-goto-page eliminates the
> display of raw PDF and the delay of the image display:
>
> *** /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el.orig 2019-01-21 15:56:08.033335212 +0100
> --- /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el 2019-01-23 14:54:52.381373638 +0100
> ***************
> *** 624,629 ****
> --- 624,630 ----
> (pdf-view-deactivate-region)
> (force-mode-line-update)
> (run-hooks 'pdf-view-after-change-page-hook))))
> + (switch-to-buffer (current-buffer))
> nil)
>
> (defun pdf-view-next-page (&optional n)
>
> I assume this is only a workaround.
It's a workaround, yes. I believe it works because switching a buffer
causes a more thorough redisplay of the window showing that buffer,
and so the fact that overlay changes in it are not noticed no longer
gets in our way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 17:22:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Wed, 23 Jan 2019 18:13:41 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: politza <at> hochschule-trier.de, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org,
>> tsdh <at> gnu.org
>> Date: Tue, 22 Jan 2019 23:00:01 +0100
>>
>> > So could you please add the following 2 lines:
>> >
>> > fprintf (stderr, "run_window_configuration_change_hook: %p\n", f);
>> > fflush (stderr);
>> >
>> > into the very beginning of run_window_configuration_change_hook (it is
>> > in src/window.c), compile both versions of Emacs, and run the same
>> > scenario again. Then please show the traces, where the above message
>> > should be visible somewhere among the other trace messages.
>>
>> Attached. It's striking that in the emacs-26 trace
>> run_window_configuration_change_hook is called just once, before the PDF
>> (image) is displayed, while in the emacs-master trace it's called once
>> before the (raw) PDF is displayed and again immediately after that, but
>> not again when the display changes to the image. Does that accord with
>> your theory?
>
> Yes, sort of. (The first invocation of
> run_window_configuration_change_hook is AFAIU not relevant to the
> issue at hand, it's about a different buffer, called "manual". Only
> the second call is relevant.
"manual" is the Dired buffer of the directory containing the PDF file.
> )
>
> Here's my theory: [...]
Thanks, this sounds plausible.
>> This time with emacs-master about 25 seconds elapsed
>> between the raw PDF appearing in the buffer and the image appearing
>> (again without keyboard intervention). Immediately after that, the
>> trace stopped for a number of seconds (I didn't time it but I guess
>> 5-10), then it printed:
>> redisplay_preserve_echo_area (8)
>> redisplay_internal 0
>
> These two traces are not in the trace you posted, right? Because the
> Emacs 27 trace ends with this:
>
>> redisplay_preserve_echo_area (9)
>> redisplay_internal 0
>> 0x2a01550 (R-admin.pdf): same window start
>> 0x2a01550 (R-admin.pdf): 1
>
> which I believe is the first redisplay cycle which shows the image.
> Right?
Yes. The trace I posted ends at that point, but as I wrote above, after
5-10 seconds of no further traces, the above two lines appeared, and
then I killed the buffer. I mentioned that in case it might be
relevant. Sorry for the confusion.
>> and then I killed the buffer. As the emacs-26 trace shows, after the
>> PDF image appeared (which it did without the raw PDF being displayed),
>> the trace rapidly produced another 50 lines of output (included in the
>> attachment) before pausing, after which I killed emacs.
>
> Most of the traces come from the code that invokes timers, so I think
> you have timers running which eventually trigger redisplay, something
> that doesn't happen on Andreas's machine. That might explain why you
> see the image after a short delay, while Andreas needs to manually
> trigger redisplay for that.
Ah, that seems likely. I do have several timers running, I'll see if I
can deactivate them and whether that results in no image display.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 17:23:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Wed, 23 Jan 2019 18:26:22 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: politza <at> hochschule-trier.de, rudalics <at> gmx.at, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
>> Date: Wed, 23 Jan 2019 15:31:54 +0100
>>
>> I found that the following patch to pdf-view-goto-page eliminates the
>> display of raw PDF and the delay of the image display:
>>
>> *** /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el.orig 2019-01-21 15:56:08.033335212 +0100
>> --- /home/steve/.emacs.d/elpa/pdf-tools-20181221.1913/pdf-view.el 2019-01-23 14:54:52.381373638 +0100
>> ***************
>> *** 624,629 ****
>> --- 624,630 ----
>> (pdf-view-deactivate-region)
>> (force-mode-line-update)
>> (run-hooks 'pdf-view-after-change-page-hook))))
>> + (switch-to-buffer (current-buffer))
>> nil)
>>
>> (defun pdf-view-next-page (&optional n)
>>
>> I assume this is only a workaround.
>
> It's a workaround, yes. I believe it works because switching a buffer
> causes a more thorough redisplay of the window showing that buffer,
> and so the fact that overlay changes in it are not noticed no longer
> gets in our way.
Sounds plausible.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 18:28:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> Now, image-mode works by changing an overlay. Changes in overlays are
> examined by the display engine, and windows displaying buffers where
> overlays have been changed have the corresponding portions redrawn.
> Windows that don't have any overlay changes and whose buffer text
> didn't change are skipped by redisplay, on the assumption that nothing
> has changed in them that requires displaying some of its part anew.
> And since run_window_configuration_change_hook is called only _after_
> the display engine already examined the windows, it cannot trigger
> redisplay of the window where we show the image of the PDF document.
> Thus, the image is shown only upon next more or less thorough
> redisplay, which redraws the window in question.
So emacs 26 has
- make a new window
- in the ensuing configuration change hook make the overlay
- redisplay picks up the overlay immediately.
While emacs 27 has
- make a new window
- redisplay sees no overlay
- in the ensuing configuration change hook make the overlay
- a next through redisplay will pick up the overlay.
Now doc-view-mode has
(add-hook 'image-mode-new-window-functions
'doc-view-new-window-function nil t)
(image-mode-setup-winprops)
and pdf-view.el has
;; Keep track of display info
(add-hook 'image-mode-new-window-functions
'pdf-view-new-window-function nil t)
(image-mode-setup-winprops)
where 'image-mode-setup-winprops' does
(add-hook 'window-configuration-change-hook
#'image-mode-reapply-winprops nil t))
Strictly spoken, all of these abuse the concept of hooks. Making a
new window, putting an overlay there, setting some properties are
deterministic actions. Why do we have to do them from the hook?
Basically, hooks are needed when some other agent does a change in a
non-deterministic (from the POV of the person that puts the function
on the hook) way.
> Therefore, a question to Martin: why was the call to
> run_window_change_functions put at the very end of redisplay_internal?
> Is this intentional, and if so, what were the reasons for that?
We early discussed this (with the initial text by Stefan) as
> > > If it's run "at the end of redisplay", then I think it's too late: those
> > > hooks will often want to change something visual, and they will want it
> > > to appear right away, so it should be run just *before* redisplay.
> >
> > Note that 'window-size-change-functions' are currently already run
> > right in the middle of redisplay. Often, window sizes are correct
> > only *after* redisplay. Think of minibuffer window resizing or
> > changes in the fringes, margins or modeline sub-structures. But a
> > final word on the location of the call will have to be told by Eli.
>
> I don't think I can utter that final word, primarily because I don't
> understand Stefan's concerns.
Running the hooks at late as possible will catch most size changes
(calculating the mode line height or minibuffer heights) done by
redisplay so you have the final layout of a frame available when
running the hooks. But maybe that's just needless perfectionism.
Also, I'm still not sure whether running hooks earlier will handle
'pdf-view-new-window-function' and 'image-mode-reapply-winprops'
running the deterministic emacs 26 way. After all, the idea seems to
be
(1) Make the window.
(2) Run 'image-mode-reapply-winprops'.
(3) Run 'pdf-view-new-window-function'.
(4) Continue with overlays and properties set up.
(5) Redisplay, eventually.
If anything in (4) needs anything done in (2) and (3), running the
hooks earlier in redisplay won't help.
Note: We can always restore the emacs 26 (better emacs 25) way
'window-configuration-change-hook' is run. That won't affect the
remaining hooks and prevent scenarios as the one found here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 18:40:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jan 2019 19:27:24 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: politza <at> hochschule-trier.de, 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
>
> (add-hook 'window-configuration-change-hook
> #'image-mode-reapply-winprops nil t))
>
> Strictly spoken, all of these abuse the concept of hooks. Making a
> new window, putting an overlay there, setting some properties are
> deterministic actions. Why do we have to do them from the hook?
I don't know the answer, perhaps Andreas could explain his perspective
on this.
> Running the hooks at late as possible will catch most size changes
> (calculating the mode line height or minibuffer heights) done by
> redisplay so you have the final layout of a frame available when
> running the hooks.
Maybe this means what is now run_window_configuration_change_hook
should be divided into 2 parts: one that only reacts to changes in
dimensions, the other that reacts to new windows and changes in
window-buffer? The former will want to run at the end of redisplay,
the latter at the beginning, I think.
> Also, I'm still not sure whether running hooks earlier will handle
> 'pdf-view-new-window-function' and 'image-mode-reapply-winprops'
> running the deterministic emacs 26 way. After all, the idea seems to
> be
>
> (1) Make the window.
>
> (2) Run 'image-mode-reapply-winprops'.
>
> (3) Run 'pdf-view-new-window-function'.
>
> (4) Continue with overlays and properties set up.
>
> (5) Redisplay, eventually.
>
> If anything in (4) needs anything done in (2) and (3), running the
> hooks earlier in redisplay won't help.
I'm not sure I understand why, perhaps because I don't have a clear
idea what you mean by "continuing with overlays". Please tell more.
> Note: We can always restore the emacs 26 (better emacs 25) way
> 'window-configuration-change-hook' is run. That won't affect the
> remaining hooks and prevent scenarios as the one found here.
What are the disadvantages of doing that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Wed, 23 Jan 2019 22:21:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Wed, 23 Jan 2019 18:21:40 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Wed, 23 Jan 2019 18:13:41 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>
>> Most of the traces come from the code that invokes timers, so I think
>> you have timers running which eventually trigger redisplay, something
>> that doesn't happen on Andreas's machine. That might explain why you
>> see the image after a short delay, while Andreas needs to manually
>> trigger redisplay for that.
>
> Ah, that seems likely. I do have several timers running, I'll see if I
> can deactivate them and whether that results in no image display.
Starting with -Q to avoid the timers (as Andreas pointed out to me and I
should have been doing all along) and disabling blink-cursor-mode and
global-eldoc-mode, I can now confirm that the PDF buffer displays raw
PDF indefinitely, until I force redisplay with keyboard input (M-x, n,
etc).
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Thu, 24 Jan 2019 09:10:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 34138 <at> debbugs.gnu.org (full text, mbox):
>> Strictly spoken, all of these abuse the concept of hooks. Making a
>> new window, putting an overlay there, setting some properties are
>> deterministic actions. Why do we have to do them from the hook?
>
> I don't know the answer, perhaps Andreas could explain his perspective
> on this.
Many people (including me) do not understand the essence of most hooks
so they just replicate usage patterns from some other source. While
the original idea of the hook often gets lost this way, packages work
in some way or the other satisfactorily.
> Maybe this means what is now run_window_configuration_change_hook
> should be divided into 2 parts: one that only reacts to changes in
> dimensions, the other that reacts to new windows and changes in
> window-buffer? The former will want to run at the end of redisplay,
> the latter at the beginning, I think.
This would double the potential ways of interleaved running of
functions on the hook. I'd rather not do that.
>> (1) Make the window.
>>
>> (2) Run 'image-mode-reapply-winprops'.
>>
>> (3) Run 'pdf-view-new-window-function'.
>>
>> (4) Continue with overlays and properties set up.
>>
>> (5) Redisplay, eventually.
>>
>> If anything in (4) needs anything done in (2) and (3), running the
>> hooks earlier in redisplay won't help.
>
> I'm not sure I understand why, perhaps because I don't have a clear
> idea what you mean by "continuing with overlays". Please tell more.
When I say that steps (1)--(3) are deterministic I meant that making
the window is guaranteed to have run (2) and (3) before any action in
(4) gets executed. In (4) the application may run arbitrary code with
the guarantee that the overlay from (3) and the "winprops" from (2)
have been installed. Running 'window-configuration-change-hook' from
redisplay means this guarantee no longer holds.
>> Note: We can always restore the emacs 26 (better emacs 25) way
>> 'window-configuration-change-hook' is run. That won't affect the
>> remaining hooks and prevent scenarios as the one found here.
>
> What are the disadvantages of doing that?
That we again run the hook even if nothing has changed and do not
catch many possible changes. Hence well-behaved users of that hook
would get punished.
I'm not sure whether I would care personally. We never reached a
common agreement on what a window configuration change is and when it
happens. So while the hook represents bad design (IMHO) and nobody
should ever have used it, there never existed a viable alternative to
accomplish what it provided in the past.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Thu, 24 Jan 2019 14:27:01 GMT)
Full text and
rfc822 format available.
Message #149 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Jan 2019 10:08:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: stephen.berman <at> gmx.net, politza <at> hochschule-trier.de,
> 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
>
> >> (1) Make the window.
> >>
> >> (2) Run 'image-mode-reapply-winprops'.
> >>
> >> (3) Run 'pdf-view-new-window-function'.
> >>
> >> (4) Continue with overlays and properties set up.
> >>
> >> (5) Redisplay, eventually.
> >>
> >> If anything in (4) needs anything done in (2) and (3), running the
> >> hooks earlier in redisplay won't help.
> >
> > I'm not sure I understand why, perhaps because I don't have a clear
> > idea what you mean by "continuing with overlays". Please tell more.
>
> When I say that steps (1)--(3) are deterministic I meant that making
> the window is guaranteed to have run (2) and (3) before any action in
> (4) gets executed. In (4) the application may run arbitrary code with
> the guarantee that the overlay from (3) and the "winprops" from (2)
> have been installed. Running 'window-configuration-change-hook' from
> redisplay means this guarantee no longer holds.
I think the overlay is definitely installed, just not before redisplay
examines the windows.
> >> Note: We can always restore the emacs 26 (better emacs 25) way
> >> 'window-configuration-change-hook' is run. That won't affect the
> >> remaining hooks and prevent scenarios as the one found here.
> >
> > What are the disadvantages of doing that?
>
> That we again run the hook even if nothing has changed and do not
> catch many possible changes. Hence well-behaved users of that hook
> would get punished.
>
> I'm not sure whether I would care personally. We never reached a
> common agreement on what a window configuration change is and when it
> happens. So while the hook represents bad design (IMHO) and nobody
> should ever have used it, there never existed a viable alternative to
> accomplish what it provided in the past.
I'd like to see if there's a less radical solution.
Andreas, could you please help me? I'd like to have a way of
reproducing the problem with pdf-tools, but without poppler. Would it
be possible for you to show me some Lisp that use pdf-tools (or even
image-mode directly) to just display some fixed image, say splash.png
from etc/images, in the same way, i.e. using the same hooks, as you do
with a PDF document? I tried to write a very simplified version of
pdf-view.el for that purpose, but either my emulation was imperfect or
there are OS-dependent factors that get in the way, because with the
code I wrote the image appears immediately. It is important for me to
run code for which I know that you and Stephen see the problem.
Armed with such a test case, I will see what can be done to fix the
behavior.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Thu, 24 Jan 2019 19:42:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Andreas, could you please help me? I'd like to have a way of
> reproducing the problem with pdf-tools, but without poppler. [...]
I attached an archive containing a dummy epdfinfo script (the part
that's normally a c-program based on poppler) and an Elisp file. The
last one also contains some instructions. I hope that works for you.
The epdfinfo programm runs in an asynchronous process. In the scenario
we are discussing here, the Lisp side actively waits for the created
image via accept-process-output and this probably makes a difference
regarding the re-display behavior.
Both, pdf-tools and doc-view, need a way to be notified when a new
window of a PDF buffer is created, such that a window-specific overlay
can be created. This allows for different windows to be able to display
different pages of some PDF. Apparently this should happen *before*
re-display.
Andreas
[pdf-tools-redisplay-bug.tgz (application/gzip, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Fri, 25 Jan 2019 09:45:01 GMT)
Full text and
rfc822 format available.
Message #155 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> Both, pdf-tools and doc-view, need a way to be notified when a new
> window of a PDF buffer is created, such that a window-specific overlay
> can be created. This allows for different windows to be able to display
> different pages of some PDF. Apparently this should happen *before*
> re-display.
Why does the window have to be "new"? What happens when an existing
window regardless of whether it shows this or another PDF already (or
some completely unrelated buffer) is used for displaying a PDF?
I suppose this is an idiosyncrasy of 'image-mode' but I have yet to
find out why such a construction has been chosen.
martin
Merged 34138 34202.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 26 Jan 2019 01:55:02 GMT)
Full text and
rfc822 format available.
Merged 34138 34202.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 26 Jan 2019 07:12:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 26 Jan 2019 09:21:02 GMT)
Full text and
rfc822 format available.
Message #162 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> I'd like to see if there's a less radical solution.
One reasonable location to run window change functions should be right
before
if (windows_or_buffers_changed && !update_mode_lines)
/* Code that sets windows_or_buffers_changed doesn't distinguish whether
only the windows's contents needs to be refreshed, or whether the
mode-lines also need a refresh. */
update_mode_lines = (windows_or_buffers_changed == REDISPLAY_SOME
? REDISPLAY_SOME : 32);
in redisplay_internal.
It's slightly suboptimal because "global" values like the old selected
frame and the old selected window would still have to be updated where
we do that now and frame "local" values might be inconsistent in the
sense that when I run the hook for a frame F1 then inspecting the "old
size" of a window on a frame F2 would depend on whether we have run
the hook for F2 already in this redisplay cycle or not. But these are
not really big issues. WDYT?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 26 Jan 2019 10:53:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 26 Jan 2019 10:19:57 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: stephen.berman <at> gmx.net, politza <at> hochschule-trier.de,
> 34138 <at> debbugs.gnu.org, tsdh <at> gnu.org
>
> One reasonable location to run window change functions should be right
> before
>
> if (windows_or_buffers_changed && !update_mode_lines)
> /* Code that sets windows_or_buffers_changed doesn't distinguish whether
> only the windows's contents needs to be refreshed, or whether the
> mode-lines also need a refresh. */
> update_mode_lines = (windows_or_buffers_changed == REDISPLAY_SOME
> ? REDISPLAY_SOME : 32);
>
> in redisplay_internal.
That's at the beginning of redisplay, so yes, I think it's a better
place.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 26 Jan 2019 15:08:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 34138 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> That's at the beginning of redisplay, so yes, I think it's a better
> place.
Patch attached. Everybody involved, please try.
Thanks, martin
[run_window_change_functions.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 26 Jan 2019 15:34:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Sat, 26 Jan 2019 16:07:41 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>> That's at the beginning of redisplay, so yes, I think it's a better
>> place.
>
> Patch attached. Everybody involved, please try.
I rebuilt with it and based on initial testing, it solves the problem
for me, both with pdf-tools and doc-view.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 02 Feb 2019 09:29:02 GMT)
Full text and
rfc822 format available.
Message #174 received at 34138 <at> debbugs.gnu.org (full text, mbox):
>> Patch attached. Everybody involved, please try.
>
> I rebuilt with it and based on initial testing, it solves the problem
> for me, both with pdf-tools and doc-view.
I now installed an appropriate patch on master. Please test again.
Thank you, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 02 Feb 2019 09:34:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 34138 <at> debbugs.gnu.org (full text, mbox):
The patch works for me.
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 02 Feb 2019 09:38:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> The patch works for me.
Thanks for the information.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 02 Feb 2019 09:40:02 GMT)
Full text and
rfc822 format available.
Message #183 received at 34138 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> I now installed an appropriate patch on master. Please test again.
Works for me,
Andreas
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 02 Feb 2019 13:00:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 34138 <at> debbugs.gnu.org (full text, mbox):
On Sat, 02 Feb 2019 10:28:29 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>>> Patch attached. Everybody involved, please try.
>>
>> I rebuilt with it and based on initial testing, it solves the problem
>> for me, both with pdf-tools and doc-view.
>
> I now installed an appropriate patch on master. Please test again.
FTR, I also just updated and rebuilt and all is fine (I've been viewing
PDF files daily with no problem with the patch you had posted). Thanks.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Tue, 19 Feb 2019 08:41:01 GMT)
Full text and
rfc822 format available.
Message #189 received at 34138 <at> debbugs.gnu.org (full text, mbox):
fixed 34138 27.1
quit
> FTR, I also just updated and rebuilt and all is fine (I've been viewing
> PDF files daily with no problem with the patch you had posted). Thanks.
Fine. Closing this bug now.
Thanks, martin
bug Marked as fixed in versions 27.1.
Request was from
martin rudalics <rudalics <at> gmx.at>
to
control <at> debbugs.gnu.org.
(Tue, 19 Feb 2019 08:41:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Tue, 19 Feb 2019 08:48:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 34138 <at> debbugs.gnu.org (full text, mbox):
>> I now installed an appropriate patch on master. Please test again.
>
> Works for me,
Thanks for the information. I hopefully closed this bug now.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Sat, 30 Mar 2019 02:57:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 34138 <at> debbugs.gnu.org (full text, mbox):
# Delayed display of PDF file images /#34202 Opening a pdf shows raw file at first
close 34138 27.1
# message hangs when buffer with process visible
close 34179 27.1
# Emacs randomly hangs during redisplay
close 34260 27.1
# Zero wide scroll bars
close 34569 27.1
# Wrong unbinding order in x_consider_frame_title
close 34317 27.1
quit
martin rudalics <rudalics <at> gmx.at> writes:
> fixed 34138 27.1
> quit
>
>> FTR, I also just updated and rebuilt and all is fine (I've been viewing
>> PDF files daily with no problem with the patch you had posted). Thanks.
>
> Fine. Closing this bug now.
So, this doesn't quite close the bug, it just marks it fixed. You
should use "close" instead of "fixed" to close a bug ("close" does also
accept a version argument to mark as fixed at the same time).
bug marked as fixed in version 27.1, send any further explanations to
34138 <at> debbugs.gnu.org and Stephen Berman <stephen.berman <at> gmx.net>
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sat, 30 Mar 2019 02:57:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#34138; Package
emacs.
(Tue, 23 Apr 2019 09:23:02 GMT)
Full text and
rfc822 format available.
Message #202 received at 34138 <at> debbugs.gnu.org (full text, mbox):
> So, this doesn't quite close the bug, it just marks it fixed. You
> should use "close" instead of "fixed" to close a bug ("close" does also
> accept a version argument to mark as fixed at the same time).
I'm afraid I'll never learn to get that right.
Thanks for fixing this and the others, martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 21 May 2019 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 334 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.