From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#34138: 27.0.50; Delayed display of PDF file images Date: Wed, 23 Jan 2019 19:27:24 +0100 Message-ID: <5C48B20C.9030100@gmx.at> References: <871s58e4gh.fsf@gmx.net> <87h8e3h90z.fsf@gmx.net> <5C4483B7.1060604@gmx.at> <87d0orgz0a.fsf@gmx.net> <837eezbazk.fsf@gnu.org> <878szfgwdu.fsf@gmx.net> <8336pnb9cq.fsf@gnu.org> <874la3gujy.fsf@gmx.net> <831s57b7ev.fsf@gnu.org> <87zhrvfdzu.fsf@gmx.net> <83zhrv9qe5.fsf@gnu.org> <87sgxnf48d.fsf@gmx.net> <83pnsq9f47.fsf@gnu.org> <871s56dm5q.fsf@gmx.net> <83lg3e9dd6.fsf@gnu.org> <87womxdgdq.fsf@gmx.net> <83fttlam3b.fsf@gnu.org> <87sgxlrfgg.fsf@hochschule-trier.de> <83bm49aj3q.fsf@gnu.org> <87a7jtd4sx.fsf@gmx.net> <834la0accs.fsf@gnu.org> <87lg3cfjef.fsf@gmx.net> <83lg3b8i8a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="34073"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 34138@debbugs.gnu.org, politza@hochschule-trier.de, tsdh@gnu.org To: Eli Zaretskii , Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 23 19:28:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gmNFy-0008kT-V9 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Jan 2019 19:28:11 +0100 Original-Received: from localhost ([127.0.0.1]:39880 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmNFy-0004qK-0e for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Jan 2019 13:28:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gmNFr-0004qD-V6 for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 13:28:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gmNFr-00053Z-0p for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 13:28:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43793) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gmNFq-00053E-T1 for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 13:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gmNFq-00015B-6G for bug-gnu-emacs@gnu.org; Wed, 23 Jan 2019 13:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Jan 2019 18:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34138 X-GNU-PR-Package: emacs Original-Received: via spool by 34138-submit@debbugs.gnu.org id=B34138.15482680654137 (code B ref 34138); Wed, 23 Jan 2019 18:28:02 +0000 Original-Received: (at 34138) by debbugs.gnu.org; 23 Jan 2019 18:27:45 +0000 Original-Received: from localhost ([127.0.0.1]:43074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmNFW-00014d-Ty for submit@debbugs.gnu.org; Wed, 23 Jan 2019 13:27:45 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:60593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gmNFU-00014P-Ny for 34138@debbugs.gnu.org; Wed, 23 Jan 2019 13:27:41 -0500 Original-Received: from [192.168.1.101] ([213.162.73.229]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MaF8e-1gSeXU3AoS-00JpsT; Wed, 23 Jan 2019 19:27:32 +0100 In-Reply-To: <83lg3b8i8a.fsf@gnu.org> X-Provags-ID: V03:K1:/JSh1bMcGefWPhLeE07t/P6yjD/nQgJ0aewqpqvMHpXAbWBmFbd OIpOOxJhBK0DigFvnMKwEyAU9MQEMSEB+gCL9nvpPj/jtdWK49SrOTpFEChnY6T9SvFYwAv yMq37JoRCVa/ROBvoj/aBxTVit9zei2RLogpQkPv0lMDNfNgaLN1ml/5VZ4evlTyuZLQxBa nynUOBjapm6y1rYGo5Faw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ufqfkhmcpGQ=:05k74n7LmELtYo118zBYnE LjrpfgEJVuF6X40AEYLMJOk6EhdXyUyyQiuhgPwQMupz5HKrpUWshmTMpYoACjPVw4mp2wl7c BhSaWXZf8ye4SQ6hjqtBhXsXKvyUgBiLiAE0a6wOTNkuRhvmI01TOe0deTFj9IX8q+7pBmhbW mkGSZpcpQKutGm2aS5CC6vNQ/bgupDF3ODPCVVeBBicnWPgmHIk7ymCh5UkBMxQJbbDy6Jp/f b2JsNB1OsM97Q5obUSdrmN54LQ4qm/MFVlPnw1ymEI617u4Qu6MmLR1zbBZ9GMsx3LtlzxEcJ 0xxheayCCpqKZEBt+XecYfoO1p2Pu1FVzviIkGcYznW1YcYOL49JwXcV8Kz1mmtE3YZc6j5ky 0x+WPpNs94Ejy8jg9C96CvUILSOYjWUQBTn09/tlyh92SbIzSkXRbco9+7UMJyzwSwStWH2Qm 6BA/eSe6glZw0g1O7k6i69MlPOKpZfG4yBKvggctzDluaEFT29IaJx1gVP5b9GaW/uANAOili BxM+scv2rQ0PdaMfGp9bd9eXMtbx1ZKft2nop0BLc0EuEeA2zlc9T7h1JKGnXRTud9r2fUXB4 xOWEUGMMUXvKJsgtY123s4p2PUMBsRarqWkOJ+CKLsaRi/48D1Ii10skcNSb1TZfyzhAmBOgd TUsyA7lfswtZfsRzSyge3Yp7hvIRY5WgQypNqP8teRwIUb2bJd+YbZe8FXhCJfBmZq7Pqq+VY AZaDQVjd3yflXxCI6QCtp4sbagpje5rr0VbVOl41NX9M4GHMbCXcBoKWSfdeqU2NvjorIsY5 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:154714 Archived-At: > 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