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.devel,gmane.emacs.orgmode Subject: Re: Please document the caching and its user options Date: Sat, 15 Jun 2024 17:37:50 +0300 Message-ID: <86cyoitgox.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8706"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org, michael.albinus@gmx.de To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 15 16:38:27 2024 Return-path: Envelope-to: ged-emacs-devel@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 1sIUXz-00024a-8u for ged-emacs-devel@m.gmane-mx.org; Sat, 15 Jun 2024 16:38:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIUXg-0001nh-VT; Sat, 15 Jun 2024 10:38:08 -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 1sIUXd-0001mg-RS; Sat, 15 Jun 2024 10:38:05 -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 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==; In-Reply-To: <87a5jmguq8.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Jun 2024 14:13:03 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:320149 gmane.emacs.orgmode:162084 Archived-At: > 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.