From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#59902: 30.0.50; Image overlay is not updated until the cursor moves to the overlay Date: Sun, 11 Dec 2022 12:23:34 +0200 Message-ID: <83bkoautll.fsf@gnu.org> References: <87zgby87rm.fsf@localhost> <83h6y62kjp.fsf@gnu.org> <87ilim863y.fsf@localhost> <83lenh20fy.fsf@gnu.org> <87a63x7l1w.fsf@localhost> <83h6y51w66.fsf@gnu.org> <87wn6zr376.fsf@localhost> <83bkoby0zq.fsf@gnu.org> <87ilijfrac.fsf@localhost> <83o7sbwddn.fsf@gnu.org> <87zgbul2ln.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2588"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59902@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 11 11:24:19 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p4JVK-0000QW-3z for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 11 Dec 2022 11:24:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4JV6-0004gy-CU; Sun, 11 Dec 2022 05:24:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4JV5-0004gh-30 for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 05:24:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p4JV4-000167-LL for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 05:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4JV4-0008PG-9L for bug-gnu-emacs@gnu.org; Sun, 11 Dec 2022 05:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2022 10:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59902 X-GNU-PR-Package: emacs Original-Received: via spool by 59902-submit@debbugs.gnu.org id=B59902.167075422432304 (code B ref 59902); Sun, 11 Dec 2022 10:24:02 +0000 Original-Received: (at 59902) by debbugs.gnu.org; 11 Dec 2022 10:23:44 +0000 Original-Received: from localhost ([127.0.0.1]:46290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4JUl-0008Oy-Pt for submit@debbugs.gnu.org; Sun, 11 Dec 2022 05:23:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4JUj-0008Op-Ni for 59902@debbugs.gnu.org; Sun, 11 Dec 2022 05:23:42 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4JUe-00014V-DN; Sun, 11 Dec 2022 05:23:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=z716+JYUZLV0Bm+p2oV/jUnHyFCTqu8s+2/kyAxyvHs=; b=a+i3x62F1TQv AQGegXQYEpN1APhP2ev0SFcJAEYUO5W/Roi4NGqR0Lc6FoqvvOrLn/E7WnvI/LUMgoXnsByZLKup3 U0Zz81fmRXzFhe/BawRt9XZyG1JZqnaE8VOGfUSUpDmmcqvdemHFLL3E3athMXgVrcsSZp/E/trjy 3B8z4JjJMBPxubnWniEHWovD3lnP/PZ8hNvY1dCzkt/FFniMHryQuBiQL/cgcW0kfqZxOlLGemM7j PCKADt8uaQ3EUmTFS+kvRB1YcW1SWmQlCFWZqH3hxQ20hoP4koYQhEhAZEEza6oIIXX2SVZVk+Kp2 z/PcI8luxAo21SpIJ7xaMw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4JUd-0004bb-Py; Sun, 11 Dec 2022 05:23:36 -0500 In-Reply-To: <87zgbul2ln.fsf@localhost> (message from Ihor Radchenko on Sun, 11 Dec 2022 09:19:16 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250588 Archived-At: > From: Ihor Radchenko > Cc: 59902@debbugs.gnu.org > Date: Sun, 11 Dec 2022 09:19:16 +0000 > > Eli Zaretskii writes: > > > The idea of clearing images from time to time was discussed, but AFAIR > > we didn't find a good way that fits all the needs for doing so. > > Are you referring to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33275 > ? That's one of them, yes. There were others. > I do not see anyone proposing cache expiry time there. Expiry is not > really related to this particular bug report, but might be a good idea > to help large memory consumption that is reported from time to time (I > reported once for pdfs and I have seen people report memory issues with > images). > > > I think this is best left to the application level. In particular, in > > this case, the application _knows_ when it will replace the image > > file. > > No. Not really. Source block execution does not pass any information > about updating/not updating images to Org image display code. Even if it > did, the same issue could appear when the image file changes on disk > outside Emacs. Then I don't think I understand what you expect Emacs to do in these cases. We have no idea when the image file is replaced, and cannot have such an idea without examining the file at high enough frequency. Doing this "from time to time" is going to miss some changes, or take note of them too late. What else is possible? > I was still able to make some improvements in Org's image code thanks to > your replies. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a12d15df9 > > Yet, do note that flickering two different image versions when moving > point is unexpected even considering the information you provided. Flickering is expected when you do something that affects a large portion of the Emacs display. For example, the same will happen if you change a large overlay at high enough frequency. There's no way around that except not doing that. Why was this implementation chosen for whatever feature that produces images? Emacs doesn't react instantly to changes in disk files that it visits, and here you expect it to do so. Isn't it possible to implement this in some other way, like have the program produce its image data in a temporary Emacs buffer, then use that buffer's contents for creating an image? Then I believe the updated image will have a different hash value, and there will be no cache-related collisions.