From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68006: 30.0.50; Image-mode speed Date: Mon, 21 Oct 2024 12:12:12 +0200 Message-ID: <875xplvk77.fsf@ledu-giraud.fr> References: <87le9jlfd6.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> <86h698l9mb.fsf@gnu.org> Reply-To: Manuel Giraud Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13550"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: stefankangas@gmail.com, 68006@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 21 12:12:43 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 1t2pP0-0003Lr-Bn for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Oct 2024 12:12:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t2pOv-0005lN-DP; Mon, 21 Oct 2024 06:12:37 -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 1t2pOu-0005lE-G8 for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2024 06:12:36 -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 1t2pOu-0007iq-3N for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2024 06:12:36 -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:Date:References:In-Reply-To:From:To:Subject; bh=W1zKxWHpMBxLrV7vG47gtnAIFsfrvvfIwxbV97yv2cA=; b=BAHxLkToSwpZnsL2WwN73WFgZ6mWpNmons8spJrjYvxo1Vuzw5elp7t2mWia16AHOt6RLvLlYALV17tGPy3aJlB6N0plHevO6KYsvn+gENqE47fRxIMJAga/M90PpOWs/4xbIqI4YzBJoTRKT8NdkTv/xLEBVNk2ZCib+EiOCJ+HdWlPwfJz8r9zh00Rdyy5oTr8nF7pV6MIfxbU+SSNbLXxvhhHOWvkxdAnJTgGPp1peuSLSccG1KGJKs4MQcaR6hMhDN++IRi5LplK3n2MlmR1l06TqgRQwLcwyGzjKlGts17BYidWH51oxRlZzWDLoKLxUARzWpo8q1lsaibB0A==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t2pPK-0000c6-Bj for bug-gnu-emacs@gnu.org; Mon, 21 Oct 2024 06:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Manuel Giraud Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Oct 2024 10:13: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.17295055762344 (code B ref 68006); Mon, 21 Oct 2024 10:13:02 +0000 Original-Received: (at 68006) by debbugs.gnu.org; 21 Oct 2024 10:12:56 +0000 Original-Received: from localhost ([127.0.0.1]:50320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2pPD-0000bj-TN for submit@debbugs.gnu.org; Mon, 21 Oct 2024 06:12:56 -0400 Original-Received: from ledu-giraud.fr ([51.159.28.247]:36935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t2pPB-0000ba-8r for 68006@debbugs.gnu.org; Mon, 21 Oct 2024 06:12:54 -0400 DKIM-Signature: v=1; a=ed25519-sha256; c=simple/simple; s=ed25519; bh=UMG0BYt0 PZbpV+hwNuqjtrllwMo54wJQjBXG5VvoFhA=; h=date:references:in-reply-to: subject:cc:to:from; d=ledu-giraud.fr; b=xQ9/WYRatXKHMMdjgeUMk4Qv0JB6I8 SyDvDjsS1suC8DVqHPpXAywjmkMSOwjLno5IpV8YYBywZmSM44QPgKAA== DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=rsa; bh=UMG0BYt0PZbpV+hw NuqjtrllwMo54wJQjBXG5VvoFhA=; h=date:references:in-reply-to:subject: cc:to:from; d=ledu-giraud.fr; b=Q9Spg9gviN5EU796drFMzmfIgu3w8giU3ytP3w P+WcjO6kdbQKv6OUEaNzq3eknKXQ0DnuIqZ4Nb6OLneFVCazqK38X8SXJh4cPWbechYLgA AEbdvdnwruTC+s+rEJVouYpdJskXX0aU8Kk45vyOcY2tBihp2iXKf3xKsiMd58JGbDGAO6 C+opFwRPLTQm2FeAVo6BfgxSR2Jsyx4hQw++sUKdQO9zMG/5ObfHN2tPlcqIRu6j64k7wc 3T8M4CqJGDEIq1LtMRzO7qen5gs4rhyYRyy1qEFLo+N6/DUO1FAjRl1CVX6E0SfdQmFXPU UHam5FUY8+AbY5DoPxO2LvvA== Original-Received: from computer ( [37.165.138.27]) by ledu-giraud.fr (OpenSMTPD) with ESMTPSA id 6002b18b (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Mon, 21 Oct 2024 12:12:20 +0200 (CEST) In-Reply-To: <86h698l9mb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 19 Oct 2024 12:34:04 +0300") 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:294041 Archived-At: Eli Zaretskii writes: [...] >> 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 =C2=AB=C2=A0user cache=C2=A0=C2=BB and not in the internal one. Ima= ges lookups use both >> caches (internal and internal, in that order). A negative >> TIME_IN_SECONDS means =C2=AB=C2=A0cache this image forever=C2=A0=C2=BB. > > 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. That's you (in this thread) that suggested having another cache for more "user controlled" usage and suggested that lookup_image could search in both caches. >> 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. Yes. Anyway, my last patch was completely wrong and I am working on another one. Tell me if you're interested to see where I'm headed to. --=20 Manuel Giraud