From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.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 oEOeAMxIbGbmqwAAe85BDQ:P1 (envelope-from ) for ; Fri, 14 Jun 2024 13:42:36 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id oEOeAMxIbGbmqwAAe85BDQ (envelope-from ) for ; Fri, 14 Jun 2024 15:42:36 +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=Ufv2TeVC; 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-Seal: i=1; s=key1; d=yhetil.org; t=1718372555; a=rsa-sha256; cv=none; b=X7nqzKkBcWaj34zlBt/Aa7Gg75ERXmB0jDDBeCD7Sw4KeMA8OXq+AnZcKhTzOqp3ACiI0R xKKfnsyQeL/9PWYrdWN9asZwu1SHdM5zC9Hn7sWedEJyCcKVPa4wVpcPcEaQH0pbVpCAY6 wxvU4ofwlTe4gia/UNEsZuBVIi0pLpOmMOLr6nVpVTrNNRu4op4pIWBMNlyt071/BMfx6f klN/bvfCZrLeJxyqGiW9lzVC569MW4WwESIkKz/iYO8eYsNjXgzi59CSjbPmhjUPDeti2q 8aItZ0r05Yi3eHf2dtSzdo32pKnOyxfhWPNdAhJ5BwldfUN0IbMSx+55b2ZtIw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=Ufv2TeVC; 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=1718372555; 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=8sVOsKUJsBQu7et+j9IzZpbF3h4KdE/yZ2mdwMuO7Ik=; b=VCgvenir5r3owqOpIA4B9HGDNiiCe9NmZf+FogsAcZAUUtLhSSuCEBCPagCpdFGE3m4mRB w+vm4LZ8rUKoXnVihHgwK+R5nYiwjhtWzsdxa6dnXBOUETMIdvgCHqdpc8rxypzzP1uBAM /zKw/el8nIOswJOPeMdc5fmkOjD6lvc+xe404zgu7qEdOl3ESmpPGwlXQLboSAVebF6u29 ibewmyDOyPTr/mvOqMVNmYZBwL3VmJ4Zf0PzZ+Feibtxdsx19jkQ8aSw8PnvKvx2W81O3q 4Ec5XLrI5irE9YFMVa+XIpcSWeolWvhRJjuBluiM8latlbxaSXFUf5AbEi4luw== 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 C0117670BA for ; Fri, 14 Jun 2024 15:42:35 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sI7Br-0005kd-E1; Fri, 14 Jun 2024 09:42:03 -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 1sI7Bp-0005kO-Iu for emacs-orgmode@gnu.org; Fri, 14 Jun 2024 09:42:01 -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 1sI7Bp-0004Hf-Ao; Fri, 14 Jun 2024 09:42:01 -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=8sVOsKUJsBQu7et+j9IzZpbF3h4KdE/yZ2mdwMuO7Ik=; b=Ufv2TeVCWfnH psQG3swh9C56gCTD6a+MvZs/HBHXsIsFwNQ5yo8tixgzaPCkk759hWPxSEAhccR8NgxBYYfOVoYQT T+1DB75RHXB2clOY18ZLOG8c0TaZD9csibU63S/KqDjlaU8PJCBtP/IOIFozOTXLaNcxq/2vxwNcP vX8BzZSkM7ADPO6aXAqBF+38e1lrMRc5B9wgvtI0x/n0ByT59kpDaVr/5iQCBAGsHpXK/gPyOORfk 8M3GiCwZf0KxWtUMm8vn/Q0LtqMg6fUUTwerAES7x1xahuSl3GlOwIizyZz1+5Zwb+ovstS8soVAE 20k/PnKgonviR47KPzazLA==; Date: Fri, 14 Jun 2024 16:41:57 +0300 Message-Id: <86a5jny72y.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko Cc: emacs-orgmode@gnu.org In-Reply-To: <874j9vllbp.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Jun 2024 13:12:42 +0000) Subject: Re: Please document the caching and its user options References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: C0117670BA X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -11.09 X-Spam-Score: -11.09 X-TUID: TolVWfbip8j1 > From: Ihor Radchenko > Cc: emacs-orgmode@gnu.org > Date: Fri, 14 Jun 2024 13:12:42 +0000 > > Eli Zaretskii writes: > > > I needed to visit org.org, the Org manual, today, and to my surprise > > saw Emacs writing some data files into the ~/.cache/org-persist/ > > directory. What's more, Emacs popped a buffer out of the blue telling > > me that it could not safely encode the data written to (I presume) > > some of those files, and asked me to select a safe coding-system. > > > > By randomly poking here and there, I've succeeded to figure out that > > this is due to org-element's caching of data from parsing Org files. > > It seems this caching is turned on by default, but is not documented > > in the Org manual, and in particular there's nothing in the manual > > about turning off the caching. > > > > Please document the caching features of Org in the manual, including > > how to turn that off. (I also question the wisdom of turning this on > > by default without as much as a single request for confirmation from > > the user.) > > 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. > FYI, Org mode has been doing various forms of caching since > forever. Recently, we just employed a bit more regular API and > introduced one more kind of caching - parser cache. In addition to the > previously existing image cache, publishing cache, ID cache, clock > cache, etc. 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. 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. I hope you now understand why I wrote this report now and not before, and why I was surprised: this caching was never so explicitly and prominently into my face, so I could have completely missed its existence. > > Please also make sure that the code which actually writes the data to > > the cache files makes a point of binding coding-system-for-write to a > > proper value (probably utf-8-unix), or forces > > buffer-file-coding-system of the buffer from which it writes to have > > such a safe value, to avoid annoying and unexpected prompting of the > > user to select a proper encoding. Lisp programs that write files in > > the background cannot fail to set a proper encoding, because the call > > to select-safe-coding-system is not supposed to be triggered by Lisp > > programs unless they run as a direct result of a user-invoked command. > > 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.