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 OB5wNKDBbmZaVQAAe85BDQ:P1 (envelope-from ) for ; Sun, 16 Jun 2024 10:42:41 +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 OB5wNKDBbmZaVQAAe85BDQ (envelope-from ) for ; Sun, 16 Jun 2024 12:42:40 +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="M/eEWemy"; 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=1718534560; 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=rTxouUjL8MIE/I05em3C19Dcx0dmtHSVNSBTdlAJc10=; b=H7RWfBILSYirUAzT+a9VEIXhgWSdD+hATfPcxvC+hxZl5JAxxAL0ZT4vEkhzCv8/QouCHr 0WiV/tnsyqsLczNEKFhtaqSgCQH6hlIIz0vMrf5svxLAwU67Ye6qKHkytnC1YyNOsoaxsY nSRkpJD4UjhfxouMwe8BZ73BaGT5Jwsu+kgHe+IqRLWzkZs4KLYRpcTTz5nJnbs4TdwyFU q4SuEmASyP5sgKKCuzFhYGhhF/nS/YKOUjdESMuj6vrjPFhxalrtBH9ElQXKJ7WdvaBkvu lA/b1/R0Svw7UuGDQFtu6M4qRxfBV03pAe3GX/Bwn2rz7Kg0GkxVnSf5rpDaNQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718534560; a=rsa-sha256; cv=none; b=WEnpVRyHnF+B+latrpnD4Rvm9c02yGKv7CdIcJIx4VMTEujoB7PIu6zuPFADOElpnj9hIx HhN9cPg0+XWLKmXxA86Q9EgUbQnft1HCEjoPFuqIzC8MgFsF1MQS3GCBbuCHe2G3w7qG27 Zs4eoGzDxuY9KZO2C+Q3cPHaKZCPLaRQ809E4v6IYeqPjKB296IpNFtn8wSYwL8WcWM7Lh Z3KJGmafwrWUUs2GTs5AgCSUyuGeTW+sYsfdIX6E6DZ8PU4R1R3yL4kfkrz0yCZvzVmXrd NHaZiqN/ZjIlCHcgnfRdsSgF4cxdEzYXExNHAMQ5GQCg1O794VsbHbRFtOjg5A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b="M/eEWemy"; 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 7D8E474F92 for ; Sun, 16 Jun 2024 12:42:40 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sInKP-0008FY-Km; Sun, 16 Jun 2024 06:41:41 -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 1sInKM-0008Ei-M2; Sun, 16 Jun 2024 06:41:38 -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 1sInKL-00059e-7u; Sun, 16 Jun 2024 06:41:37 -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=rTxouUjL8MIE/I05em3C19Dcx0dmtHSVNSBTdlAJc10=; b=M/eEWemyPahk ECcXx+sbiDf18PF7KmtanpYgVSEKJIKk/EGQDg/285HemHb6XkDQK8ePrO4HE5sTJdEFJCM0uujnH eE1wj29qxrsqp9sZHBJtYFPlBNxbknIZS5+cgXopj4a3VhoVslzwN1LKORAZ/BYjRYG6laGipd4WO v+8JZZljCC4QG8CCz5ssMCkAimrn6CLYDIQxpl5C60nUK4vephfwA15bSRApy4mvtU5D1jBSqanvD PnJ6WI7KIrnsI+/5UHQnoZ/VFKUiaa2bRdXP0PB+zSkoiQ0joBmzDh5O1hf53IC7lVVUQG+yNjfD4 FfGgXOrm9srfuwHb2Wsgfg==; Date: Sun, 16 Jun 2024 13:41:34 +0300 Message-Id: <86le35rwyp.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: <87h6dti7gh.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jun 2024 09:05:02 +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> <86cyoitgox.fsf@gnu.org> <87h6dti7gh.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: 7D8E474F92 X-Migadu-Scanner: mx11.migadu.com X-TUID: AUQ2EOlhjUCR > From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org, michael.albinus@gmx.de > Date: Sun, 16 Jun 2024 09:05:02 +0000 > > Eli Zaretskii writes: > > >> 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? > > Yes, except that `xdg-cache-home' is limited: > > 1. It cannot be customized by users Of course it can: just make the default value of a defcustom be derived by xdg-cache-home, and users can then customize the option to a different value if they want. > 2. It may sometimes return nil The fallback is well-known. > 3. It is limited to XDG - not all the Emacs platforms No, it's supported on all platforms, even if XDG isn't. > What I had in mind is a new custom option for cache dir (defaulting to > OS-specific cache like XDG on Linux or something equivalent on Windows) > + a new API function like `system-cache-home' that will be guaranteed to > return some kind of meaningful dir. Using xdg-cache-home and its fallbacks is a de-facto standard of solving this in Emacs, and it supports all the platforms. Even startup.el uses it (albeit by customized code, to avoid interfering with user customizations) when looking for init files and suchlikes. So I think you raise a problem that is already solved in Emacs. > >> 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. > > What are those APIs? Making files and directories readable only by the owner, for example: set-file-modes and with-file-modes. All the other Lisp programs in Emacs use that, so why would Org need something special? > >> 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? > > No. I mean a new user option like `clear-caches-on-exit' that will work > across all the packages. Having a single option for all the caches makes little sense to me. This must be a per-cache setting. However, users on XDG platforms can have that via XDG system-wide settings. > Having to set this for each specific package (with some packages not > documenting that they use cache, or users not expecting that cache may > be used and not reading _all_ the docs carefully enough) is not ideal, > IMHO. I cannot disagree more. Each cache has its own logic for when it is a good time to empty the cache. > > Can we first fix the problems for which I started this thread? The > > more general issues should be subjects of separate discussions, IMO. > > If there is a global Emacs-wide customization how to handle caches, > there will be no need to document it in Org mode manual. I respectfully ask the Org developers to solve this particular issue first, without waiting for some hypothetical general Emacs feature, which may or may not materialize. > like to see if introducing such global customization is feasible before > making non-trivial changes to Org manual. (I am not even sure where to > document these things in the manual yet; they seem way too generic wrt > Org mode's scope) A new chapter should be fine, if no existing chapter is relevant. TIA