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 QJsBLU9ibGYxogAAe85BDQ:P1 (envelope-from ) for ; Fri, 14 Jun 2024 15:31:27 +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 QJsBLU9ibGYxogAAe85BDQ (envelope-from ) for ; Fri, 14 Jun 2024 17:31:27 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hh6c+QnK; 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=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1718379057; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=c45PTEZfPbzCr+KdcXRboOWZ3Bf/fJ+UWB8sKIMp4ok=; b=O9H9+rQqIbJR2A4h59ODo/2NY3i7Dp3UFM/EtQrx5SRDuHlBI1p+j0dRp//Vtrt+ZVjUVR Imi8+xkuylcK0DaDUrYPdeT01SONzjMbue39TCkqIlkwRAjDNWQLg+piOGCUakX+/6TKCI +p72pemheYO4bcMjCcMcggIFVUix709zQwwYM/Omnti5rqGYvZGl/705zdWQ2EnElZAh+3 WuXJ4KiyqnQtm9Porw/PDilaF5PZRT/kL/3nYNUR+NeldLN77QsQCIftYhHBP+dWZRc1UN FKp7dcH/grIMe4VvIHxzzXhj0tpA/KF71whlDIvpVd28zWybWfbTd2g/bBjlqw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=hh6c+QnK; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718379057; a=rsa-sha256; cv=none; b=XkBeEG7rogopRs0xO6CPiGCe0TLcQXi86OEOQtmBxpd6WhJieus6S/cmOuSnzgLMtvS/Vk tr1xRRkut29cAyRQ9mEDHhv0Q+BwuYPzqvWil5+O8TiQi3rnTCDE9iokJo5TY+k+UMCS+D wz6w8qOInfa1/Mee/FL212rRGMuIWiyIYRVc0CHmsinXiAyr+6g9m5s02IJubabYAzFqad IuTklmbIecD2Lh5GL6KLl2A8YHbeKyXHINKiOlTBzmZPHb1maSnFiRxycV3xwpIQn3pAVU edPSmxHhuJ9OQ6nFMPA/OK6ixrAJqY3Wtk/w3n/GEXztasab17uqgR9/aKZTdg== 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 0523A6CEB2 for ; Fri, 14 Jun 2024 17:30:57 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sI8sQ-0008ME-0F; Fri, 14 Jun 2024 11:30:07 -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 1sI8sM-0008IJ-M8 for emacs-orgmode@gnu.org; Fri, 14 Jun 2024 11:30:03 -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 1sI8sJ-0000Dh-KE for emacs-orgmode@gnu.org; Fri, 14 Jun 2024 11:30:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B8BA3240103 for ; Fri, 14 Jun 2024 17:29:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718378996; bh=+9J2K4icXzvIPwt+cunJOKcfL1p37GUYl7+7xs/+Jzs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=hh6c+QnKmVrDMg5ohxZDrK4ExK+8JvhVVubA62iWD2crwD2xYjAMO5dw2cr/Evwb3 hFBT6F5y8c67AyXpb5ruwLcfBJ3cF1KsfbMgAmV2P1nzZ7r7RB/DyN7jtSOmMb5JJw 0E9wI7932366zk05irqVPuxEsrNa7uS6CA6ure57x17/nhCMGVD75nq90ETV9/+ap5 u7Tg7hKwFktSQkbrUQrAmMqiWqqmGRVzW1KaoYW9gKCzspC8YaNMym/jglmZ2fWE09 JhjkwSH6SDUgPTZHYtFuWdCH1XoMC15gENkoUP+vJllfnrhkaN0oDHIuRH3vI8ksee nNAvPbsBi/34Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W139w1V7Bz6txS; Fri, 14 Jun 2024 17:29:55 +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: <86a5jny72y.fsf@gnu.org> References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.fsf@localhost> <86a5jny72y.fsf@gnu.org> Date: Fri, 14 Jun 2024 15:31:28 +0000 Message-ID: <877cerk0bz.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.56 X-Spam-Score: -9.56 X-Migadu-Queue-Id: 0523A6CEB2 X-Migadu-Scanner: mx13.migadu.com X-TUID: 0a2SIVEhbN+s Eli Zaretskii writes: >> Hmm. What aspect of caching do you want us to document? > > First and foremost, that it exists, and is turned on by default. The > manual is currently completely silent about it. > > Next, please document the user options that control this caching, and > especially those options which can be used to turn this caching off or > direct it to a different place. I am not convinced that we have to do it. Firstly, it is not clear if you are asking to document caching parser state specifically or all kinds of caching Org mode does. Secondly, I am not sure if we have to document the details of caching at all in the manual. We do not document all the custom options in the manual; just the most important/useful. 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? > I'm not a heavy user of Org, but I do have several Org files that I > visit from time to time. This was the first time I got prompted about > anything related to this caching. The prompt you saw is indeed a bug. > ... Moreover, I think this was the > first time the Org file I visited was parsed by Org and the results > cached: I have a feature on my system that prominently indicates when > the machine is heavily loaded, and I was surprised to see it in action > when I visited org.org. I never had this activated before just by > visiting an Org file. I presumed the high load was due to the > parsing. So either this is very new, or maybe my Org files are much > simpler than doc/misc/org.org, and so the parsing I triggered before > was much less expensive. Org mode uses parser since long time ago. Previously, the parser was invoked without any caching, even in-memory. Since Org 9.6, we implemented in-memory and on-disk caches for the parser. This allowed us to utilize the parser more frequently, without relying upon half-accurate regexp matches. Overall, it decreased CPU loads, but there are different scenarios; sometimes CPU load is larger momentarily. >> I believe that this particular problem has been solved in >> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c8f88589c >> It is a part of Org 9.7. > > Maybe. Try visiting org.org on a system whose locale is set to, say, > Latin-1, and see if you get the warnings about a safe coding-system. > > But why do you use utf-8 there and not utf-8-unix? Come to think > about it, why not emacs-internal? Those files are used internally by > Org, so they should be able to encode any characters supported by > Emacs, not just those which have UTF-8 encoding. And using native EOL > convention is not needed, and will get in the way if the user shares > these files between systems. Mostly because we chose whatever looked reasonable. I am not 100% sure what is the practical difference between `utf-8' and `utf-8-unix' and why the latter should be considered better. As for `emacs-internal', we try to make files readable if at all possible. In particular, index.eld file is even pretty-printed for user convenience. The idea is to keep things in plain text and not in binary formats, following the overall spirit how Emacs usually stores data. (I think you may recall people raising their voice about plain text vs. binary during the discussion of multisession feature and the use of sqlite database). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at