From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 4OU3EW2WbWYe3AAA62LTzQ:P1 (envelope-from ) for ; Sat, 15 Jun 2024 13:26:05 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 4OU3EW2WbWYe3AAA62LTzQ (envelope-from ) for ; Sat, 15 Jun 2024 15:26:05 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GkQE0eu1; dmarc=pass (policy=none) header.from=posteo.net; 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-Seal: i=1; s=key1; d=yhetil.org; t=1718457965; a=rsa-sha256; cv=none; b=V/73qrKhDaLg0JWLXb1Oba23TN3SMhyzmUkXpSHKEAGrKzqaO19Cq+qlEdtcoRpX44eo+3 0oqB9Q5MZ6eSxb5IhCtIt9LGX4spQGosp0jfzdpuEZIHivzYDPWz3ke4gio20sfFRZsMN9 z18sempxOjviX1srYko9lTKUraDX0QGi+CgREIGeJ9mmp89H3jjSHUPRGhMpbFFCQ1vFaB D2sqwvFiXbzxljTTOCI0zeiXUbhophr8LM7yl5zFpLq2iGLtEeTjNiGcwTUnY714pX+GAs cb3n3MgSnmWWy3wIgxGFBLYv9qZNYWOEOdr2LskLHAd+M/QuDBt5RSQVLzG4hw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GkQE0eu1; dmarc=pass (policy=none) header.from=posteo.net; 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=1718457965; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=MrQB9HTikCgu54Gm22SRu3r5jyiE3+eYEXPFDGil+c4=; b=rXXHrs9/blO1AzGqzI6i8ceyeOYARKWUS6lpeS3BbsMArBIt+FCbi6nGwh5uhQjUaALAXg VIb1liV0vVbZAqj+PUCOxI7o9cNSCGddwCU+28rSseeXb789uzl7hsEA26W4TrnAdIr3pS F6e6xhGu1pVqMxpUvK5xzmRgv31pfSvKxO4Gn4iNNshPW/jkgShoOcGPQqJCMuJxs/Vl6m PAFvDn0d0eKCwUmJ7vP5KbEyFgWsMU4GRChS0OllZAj4JiemZVwuVhqYe9AcuXBzxV+u1I p3obTEg/BH//KRvHhWo2UBHVAYKtDPqF92goA9InM2s2pu+tInBQJlxa3wrfKw== 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 2019166DC1 for ; Sat, 15 Jun 2024 15:26:05 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sISn8-0001g4-Jz; Sat, 15 Jun 2024 08:45:58 -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 1sISn6-0001fn-Vb for emacs-orgmode@gnu.org; Sat, 15 Jun 2024 08:45:56 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sISn4-000435-Do for emacs-orgmode@gnu.org; Sat, 15 Jun 2024 08:45:56 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A7AEA240101 for ; Sat, 15 Jun 2024 14:45:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718455551; bh=Ig1qOKI53HbvunklzWFj12EHG+sBOViNCIMyhYACnHw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=GkQE0eu1dlr9fohFs0NQaA/FYjzWxrIdjICdlrolSJGXBvOVw/GY0CRePcjiolpfC kSr6bq7gnYvP8O/eapwLxPcNe2gNMc8pLSkmx/espXIUBA9QucIY9fJgXJEXpCVrF3 /zK+nz/ltsxxjW+KTupsxc6oGksvqgwvRvxn3PbSR19jyAi81Lxps0BcLxa+W11XCc oGOOrRBmGn5cbaCwWvoFri/Md419yvUC01CSxM1XQ6lr4qO8SzERF56G6s/Zf1fMIp wRf8HGf8bjwKYxA2BR6sjeNOHSu01kmK0v7ECe30AplvMgMW/Hh5chtLE9DbamNECV GXiN2y61lf2IQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W1bV66zZYz9rxL; Sat, 15 Jun 2024 14:45:50 +0200 (CEST) From: Ihor Radchenko To: Eli Zaretskii Cc: emacs-orgmode@gnu.org Subject: Re: Please document the caching and its user options In-Reply-To: <861q4zy0va.fsf@gnu.org> References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.fsf@localhost> <86a5jny72y.fsf@gnu.org> <877cerk0bz.fsf@localhost> <861q4zy0va.fsf@gnu.org> Date: Sat, 15 Jun 2024 12:47:29 +0000 Message-ID: <87y176gyou.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 2019166DC1 X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.57 X-Spam-Score: -9.57 X-TUID: RDHKE55z16RB 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/) >> 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) > ... And even if Emacs makes a mistake of > not documenting anything it is not a valid argument to make the same > mistake elsewhere. I 100% agree. But my default assumption is that things added to Emacs are usually documented in the manual, if necessary. I assumed that the judgment was that documenting multisession was not necessary and worked out of that assumption. Of course, if you say that multisession and similar things should be documented, I will follow. Let's discuss the details. (Also, should we open some kind of bug report to track documenting multisession in the manual?) > 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 only relevant bit is The coding system =E2=80=98utf-8-emacs=E2=80=99 specifies that the d= ata is represented in the internal Emacs encoding (*note Text Representations::). This is like =E2=80=98raw-text=E2=80=99 in that no= code conversion happens, but different in that the result is multibyte data. The name =E2=80=98emacs-internal=E2=80=99 is an alias for =E2=80=98utf-8-emacs-u= nix=E2=80=99 (so it forces no conversion of end-of-line, unlike =E2=80=98utf-8-emacs=E2=80=99, which = can decode all 3 kinds of end-of-line conventions). However, I cannot come to the conclusion you pointed from reading that paragraph. Would it make sense to add the tip about storing Elisp data somewhere in the Elisp manual? --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at