From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id gFMRB96QbWYfNAEAe85BDQ:P1 (envelope-from ) for ; Sat, 15 Jun 2024 13:02:22 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id gFMRB96QbWYfNAEAe85BDQ (envelope-from ) for ; Sat, 15 Jun 2024 15:02:22 +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=ayUcJaPk; 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"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1718456542; 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=WF2VcRuMzgUHswefbQe20owgwE45PKys9Z/6OXV8Yh8=; b=TNe9Rd06IakWv98ml7wsQkuINZ8YJeAN/7JQsQgeFZZd58dvRAEQ7Ybw6iQ+ZOPEfUx26x WmPYH2TDicwOlITQ3/Xe/RiaK17t/C6RUjXSD94paJ6uFF0mJoauPDRDnTW+GlcZEJ9OdV 7/yk7e2wIxlCzAG3kAl1w9Q/ZPjPYb37x8irBFJMDTWj+WbYIzAEVdqQWUgfe/w6UCfypT LwrIYCVKFXuLAvaltGYaesKCHTu+30KRR4tYx8CVLlKbGYDdfDAaGHpdvpqlpQp5iQ2fS/ ftO24JfK4A4Op/wgC9bCuqas2KidhTTloqLVuo75n54v2uXjBMcnoFS/DCBnPw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=ayUcJaPk; 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"; dmarc=pass (policy=none) header.from=gnu.org ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718456542; a=rsa-sha256; cv=none; b=J4T8n4W1MW88ywtoDoY5ZcT7Qf6DeDes1ZPDk0kNIpQHcBwr8VLjJRPjIzyyG4Dz4vf503 53ND54QwZl2KilNqZnqpstz4Y3857I07J6CNDS88CBp3tb9dipDCkNhhqw/oM3qGqfPy1b NipOEpO9VHG5F2zfoaHyv1Vw1uYepJHH3u/XtH7iPinYgf5sQHnQeimyw7hE/GgS/5POhT pB29XsSLWHGzOfSngLD4M5U/YaKj5uZQ8d4PifA8YebZp1gobRJEO1QUF0PZA0VU8PiOST mkF/kpcmi5IUkMQ6kgkFMoNua+hGsjZH2jWrX8nUirZiOtOtlleMpThUm9T3Xg== 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 ECB9B616C5 for ; Sat, 15 Jun 2024 15:02:21 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIT2M-0003iz-Nf; Sat, 15 Jun 2024 09:01:42 -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 1sIT2K-0003iM-6H for emacs-orgmode@gnu.org; Sat, 15 Jun 2024 09:01:40 -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 1sIT2J-00075k-61; Sat, 15 Jun 2024 09:01:39 -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=WF2VcRuMzgUHswefbQe20owgwE45PKys9Z/6OXV8Yh8=; b=ayUcJaPkiAV+ MLNx8A5xP9681vDbmtQ5cKo/jgApVtXthjSXhLYSV5Rl25n6LlPQ00hfrPU4VxJrQq/F0p+FosYUp 0ywi+fqQ7TIim7SpcXRZ7uvxbg9y/26Kj58MGs6OxFPJ2GnhdDU6A2NaxFBy65ySNwxeCREOaRgnN //c7maauD8blRgsXzZoweb45u77kz/OzvGV5diq/ziRyBzG2jRy/Zcr3KbfupYyR7ug13QaoQ0aCO T2KzsiLuZ8AbHdp4W6znPlq5FFw3D3nfKeh4WYU5cc2s6tj7eg1Mw6L+XEiqp6Fe4iMAxkChFnfdI Uw+llGxw77uoJl/PGtrTHQ==; Date: Sat, 15 Jun 2024 16:01:23 +0300 Message-Id: <86msnmtl5o.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko Cc: emacs-orgmode@gnu.org In-Reply-To: <87y176gyou.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Jun 2024 12:47:29 +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> 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: -11.10 X-Spam-Score: -11.10 X-Migadu-Queue-Id: ECB9B616C5 X-Migadu-Scanner: mx13.migadu.com X-TUID: KbzSzQuFHBnP > From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Date: Sat, 15 Jun 2024 12:47:29 +0000 > > Eli Zaretskii writes: > > >> I am not convinced that we have to do it. > > > > That's too bad. When a user finds out about this caching, how do you > > propose that he/she looks for the information about it? I wanted to > > know what is being cached, why, and in what file/directory. It took > > me quite some time to find the answers, since Org is a very large > > package, and there's no org-cache.el file or similar to serve as the > > immediate suspect. Surely, such a basic functionality should be at > > least hinted in the documentation, so that users new which options to > > look at and where? > > Maybe. Although it is not clear where to document such things. > Ideally, it would be nice if caches were managed by Emacs itself, with > all the cache storage locations customizeable across various packages. > Then, documenting cache locations in the Emacs manual would suffice. > > 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. > >> Emacs user manual does not document `multisession-directory' - something > >> very close to how we implement Org caches. So, apparently, customizing > >> `multisession-directory' and even the very multisession feature > >> existence is not deemed necessary inside Emacs manual. Why would it be > >> different for Org mode manual? > > > > 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. > Of course, if you say that multisession and similar things should be > documented, I will follow. Let's discuss the details. I think at least emoji.el should say somewhere in its doc strings that it caches the previously used emoji sequences, yes. > (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. > > The emacs-internal encoding is not binary. In almost all the cases it > > is indistinguishable from utf-8-unix. It differs where a buffer > > includes characters outside of the Unicode codespace. The usual > > practice in Emacs is that files holding internal data use > > emacs-internal to make sure all the characters are saved correctly and > > can be later restored correctly. > > Then, I agree that using emacs-internal for cached data makes sense. > > Note, however, that I see no indication about such convention in the > manual. The opportunities for using it are rare enough. But I added that now, in the hope that someone will actually read all those recommendations.