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#68006: 30.0.50; Image-mode speed Date: Sat, 19 Oct 2024 12:34:04 +0300 Message-ID: <86h698l9mb.fsf@gnu.org> References: <87le9jlfd6.fsf@ledu-giraud.fr> <87frzjvpb5.fsf@ledu-giraud.fr> <83le9a3kqs.fsf@gnu.org> <83zfxnzyrb.fsf@gnu.org> <87mstnafie.fsf@ledu-giraud.fr> <83r0izzn1p.fsf@gnu.org> <87le95rqoh.fsf@ledu-giraud.fr> <83plyhvvso.fsf@gnu.org> <87h6jtrlci.fsf@ledu-giraud.fr> <83jzopvsgj.fsf@gnu.org> <87bka0hpto.fsf@ledu-giraud.fr> <83il48x4a8.fsf@gnu.org> <875y08gikv.fsf@ledu-giraud.fr> <831qawvx7q.fsf@gnu.org> <871qavhpxf.fsf@ledu-giraud.fr> <83edevvqyj.fsf@gnu.org> <87v887g85d.fsf@ledu-giraud.fr> <83a5pjvo3s.fsf@gnu.org> <87a5pid2zq.fsf@ledu-giraud.fr> <87o73jf46r.fsf@ledu-giraud.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10511"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, 68006@debbugs.gnu.org To: Manuel Giraud Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 19 11:35:14 2024 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 1t25re-0002ZA-5P for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Oct 2024 11:35:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t25r6-0008Q9-NS; Sat, 19 Oct 2024 05:34:40 -0400 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 1t25r5-0008Pt-MV for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 05:34:39 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1t25r5-00046K-Dx for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 05:34:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=g35hBoNsSg2RtAa8NidIZCht7tfJdXht/wn3J+A9Zro=; b=K8Z9OU2FWwy07uL4H8eT4Cq3l2d9ZjjEMOMiSFY3VTCls+94PMQOUtjXFZVo7/k5UgcggkoxLcY4jNTtwv/mmlFAv19XSqZo30fRHgxizMsxh8Dvpf07XJdwAdm9cODuLkqrdFBuLT3cOGkUA9Tm5ImeDtX+L6XmqBl3vrMH2Ia+z9GUpmo9mSpcDUiWFUau7DcakJvmt6LWvhTOxqC/Q8kv1bha3Ri/lOdSNwd0ZDroJvwoFS2hw8LQ0xOjNcg0mbVsiGOkK1vvih6jmmwYShWTTPQLgRmWufoZ0rRxJHxUlrencLW17AhsCoEWdpjeFkDAYfoI9tvhhPFg7zGpCw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t25rS-0005e3-Ft for bug-gnu-emacs@gnu.org; Sat, 19 Oct 2024 05:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Oct 2024 09:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68006 X-GNU-PR-Package: emacs Original-Received: via spool by 68006-submit@debbugs.gnu.org id=B68006.172933048221662 (code B ref 68006); Sat, 19 Oct 2024 09:35:02 +0000 Original-Received: (at 68006) by debbugs.gnu.org; 19 Oct 2024 09:34:42 +0000 Original-Received: from localhost ([127.0.0.1]:41454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t25r7-0005dJ-Kv for submit@debbugs.gnu.org; Sat, 19 Oct 2024 05:34:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49886) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t25r5-0005d4-7L for 68006@debbugs.gnu.org; Sat, 19 Oct 2024 05:34:40 -0400 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 1t25qb-00044v-2B; Sat, 19 Oct 2024 05:34:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=g35hBoNsSg2RtAa8NidIZCht7tfJdXht/wn3J+A9Zro=; b=kOm2tGNHl8b/MFO35FFR vDeNRl/2NfHfEbRO+NLR8nK44jc+NnkyHfZKSJ/p/ClgS5OoqFIG9zmbmWVvDkoPduywKWvpDGKa4 uhLMZS9rssyxcxVfYw3XAwIweJE9/HXGkf5rO3P9OoFFrUe3J7o1Bz4b9VDqq46nWH6TrKQOSJVzz JDXlXNkXQ4bN0WckZVAFLY4MkaZMKbhP8+iHlLJtkx8gHlcSyQKSkyt+E+VhyPDJY8TJfH+qu6T4A A94ozqEnWrt1aGp0CN6KWgvITfr2O0zcFTPtQvCLi2KOQgKNiKn0m+8sZoS1IijAfYpvwLoWgqbiA lruU+cv740fTOA==; In-Reply-To: <87o73jf46r.fsf@ledu-giraud.fr> (message from Manuel Giraud on Thu, 17 Oct 2024 11:51:08 +0200) 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:293861 Archived-At: > From: Manuel Giraud > Cc: stefankangas@gmail.com, 68006@debbugs.gnu.org > Date: Thu, 17 Oct 2024 11:51:08 +0200 > > I'm trying to revisit this idea of having a user controlled image cache. > The goal is to have, for instance, image-mode use it because (hopefully) > it would have a better idea of when to cache/uncache images for its > usage. > > Here is a patch of such a prototype « user image cache ». > > For the moment, I wanted to keep it minimal so the only interface to use > it goes as follow. When a user (or a program) use the image attribute > ":ttl TIME_IN_SECONDS" with `create-image' such image will be stored in > the « user cache » and not in the internal one. Images lookups use both > caches (internal and internal, in that order). A negative > TIME_IN_SECONDS means « cache this image forever ». Why do we need a separate cache for this? couldn't we instead just add the EOL field to the single cache we already have? having two caches requires to search both of them, which slows down image look up, so if we can avoid that, it's better. > I think there will be a need for user function that completely flushes > the images in this new cache. But do you think we need others commands > for such interface? We probably need a way for modifying the time an image is to be kept, at least. Thanks.