From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id EGGPLHOnbWY7AgEAe85BDQ:P1 (envelope-from ) for ; Sat, 15 Jun 2024 14:38:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id EGGPLHOnbWY7AgEAe85BDQ (envelope-from ) for ; Sat, 15 Jun 2024 16:38:43 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=CuITp5Pn; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1718462323; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=J4ylEm52CPqsxEc53Jij3mPZ5QRUNjbi0kRoMePN7BA=; b=slx0xThPfpEfJMh9fKfLLD2YfHlRTGne89zIToT/RqjmSki5wcZ4jLRSAfZ7eLubdZFTm6 zfLKl3GtDe7BetvMlHT/8bLgdKvD5BkomceBTqkwXHS/RgZ1MCF6yXB2QY6y3UTZTvB9OW dH+0vVhyCFFt3yQDe+zvXVU7hNE2IPLWRi6tDmhQ+t5RdhEj4UxmtKbd8MCkAC1CIKoLK3 D+9AT2vU0zn2v0ttUTUWPUvhwgzrJF5a/u2vtWcPNxoA7TM9YXQD28AvQ700ChPKX44yJQ dogMVm1RzbuAGCrlC+R8CXse0N9NU3Zo8OXJSyrp+UHEeJtXZp4PQSarfJKHfw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718462323; a=rsa-sha256; cv=none; b=I5BS+15uVNHnmH5BVZlgDjssR9DZmDaNfsMtRLnqD6xZik1LvUkg9d+V6r/0kgNwUVYhtH oXN+5N/MiqACH+CYwi7xIckuFxCQsIIly6T6tiy2uKdP9cjbknB9gYrr0r6yMLhuOOa2ET LYndqqucVe1amHyipYiJxO2yWhjBdqSmKUPNJMqXT/PvZ1+5WC+XLEgHPR1ZHvJewvwUtL R/TQnP8zBcDBL+/+3R1KZz9io6hQQng7pENsgYefXZDggYtYvHRD2VM5N90rnEkQjVz/YL ekE3jZ8yntznDrAVd745lIWL/baDjgGQLnixpYmKyU4lVvvM4zWRq3RTx7DcIQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=CuITp5Pn; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 65E85AF28 for ; Sat, 15 Jun 2024 16:38:43 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIUXg-0001nf-Sv; Sat, 15 Jun 2024 10:38:08 -0400 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 1sIUXd-0001mg-RS; Sat, 15 Jun 2024 10:38:05 -0400 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 1sIUXd-0002Nt-FD; Sat, 15 Jun 2024 10:38:05 -0400 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=J4ylEm52CPqsxEc53Jij3mPZ5QRUNjbi0kRoMePN7BA=; b=CuITp5PntiYa bmHYhtGJyUmULJsuIjthy2YjMX7KqGEhmnWaVLiTBPPRk48Dxx0I7K2AuW5EmtgCrtravAbTO10j+ 5W0h+4K/vYEB4dwZMF7VJQSWhKdEiNQMyIozMXnTSWOAVn0Yx3NocE69xqaMsdR1wl6LCvYGXogXV 5LWQXgckfNhPwoTl/EBGUlYmmJq82ndW6mfimaOGnb0Wat1nTSIM9EX09xVMsAslNJyd0z1OVc607 xVSO7LtaDbp7vAN59fkgqPUo5uQ9k3J3db6Z6Ba52TsmiruVIM2Aq4AUgOnlQaMAxeFboNkj3Wqjz ncemzu4aSB7D3qOnuHKO0w==; Date: Sat, 15 Jun 2024 17:37:50 +0300 Message-Id: <86cyoitgox.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org, michael.albinus@gmx.de In-Reply-To: <87a5jmguq8.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Jun 2024 14:13:03 +0000) Subject: Re: Please document the caching and its user options References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.fsf@localhost> <86a5jny72y.fsf@gnu.org> <877cerk0bz.fsf@localhost> <861q4zy0va.fsf@gnu.org> <87y176gyou.fsf@localhost> <86msnmtl5o.fsf@gnu.org> <87a5jmguq8.fsf@localhost> X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -8.10 X-Spam-Score: -8.10 X-Migadu-Queue-Id: 65E85AF28 X-Migadu-Scanner: mx11.migadu.com X-TUID: pkEIYbnxhUD1 > From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org, Michael Albinus > > Date: Sat, 15 Jun 2024 14:13:03 +0000 > > CCing emacs-devel as I'd like to upgrade this discussion to Emacs-wide > context. > > Eli Zaretskii writes: > > >> ... I wanted to know what is being cached, why, and in what file/directory. > >> > > > ... > >> Would it be possible for Emacs to define a framework for cache/var/data > >> locations? Such framework would not only be useful in the context of > >> this discussion, but also to tackle the issue with packages sprinkling > >> things randomly into .emacs.d or ~/ (see > >> https://github.com/emacscollective/no-littering/) > > > > I think Emacs already provides all the framework for caching that is > > needed. Caching simply means you write some data to file, and all the > > building blocks of that already exist, for quite some time, actually. > > The only thing that is application dependent is the data to be cached > > and how to serialize that, but that cannot be usefully generalized. > > I was referring to some kind of global option that defines cache > directory, data directory, etc. Something akin XDG. We already have xdg-cache-home (and a few others in xdg.el). Is that what you meant? > Also, caching is not as simple, because caches may contain sensitive > data. (see > https://list.orgmode.org/orgmode/CAM9ALR8fuSu0YWS1SehRw7sYxprJFX-r2juXd_DgvCYVKQc95Q@mail.gmail.com/) > Some users may want to move caches to read-restricted location > or even to location dependent on where the cache is originating from > (separate caches depending on whether default-directory is from > encrypted volume, remote mount, etc) AFAIK, Emacs has APIs for at least some of that, but whether to use them is up to the application, I think. > Finally, we got several requests to have caches cleared up upon exiting > Emacs, which is also something that should be better managed centrally, > by Emacs, for all possible kinds of cache/history data. Deleting files in a directory, recursively if needed, is already available. is that what you meant? > >> > multisession is an optional package, it is neither preloaded nor > >> > turned on by default in Emacs. > >> > >> It is used by default in emoji.el (C-x 8 e r) > > > > Which is also optional. And a minor feature at that. > > It is just for now. > TRAMP (by no means a minor feature), has the following TODO item in > tramp-cache.el: > > ;;; TODO: > ;; > ;; * Use multisession.el, starting with Emacs 29.1. How far are you prepared to go just to make a point? > >> (Also, should we open some kind of bug report to track documenting > >> multisession in the manual?) > > > > I don't mind, but it sounds like an exaggeration to me. > > I kind of agree, if we talk about the current state of affairs. But, I'd > like to discuss this in the context I elaborated on above - more > centralized cache management. Can we first fix the problems for which I started this thread? The more general issues should be subjects of separate discussions, IMO.