On Tue, 22 Jan 2019 22:54:16 +0100 Stephen Berman wrote: > On Tue, 22 Jan 2019 18:25:23 +0200 Eli Zaretskii 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