From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 8PmKHEkLeGZBlgAA62LTzQ:P1 (envelope-from ) for ; Sun, 23 Jun 2024 11:47:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id 8PmKHEkLeGZBlgAA62LTzQ (envelope-from ) for ; Sun, 23 Jun 2024 13:47:21 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=T970uQcf; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1719143241; 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=Y02H/vxX0nPKBQKW2vL5/4lrr+hwelw+JZ2uSF7iTx4=; b=CsfJ9fJSas1kI3mtbOMJ66UpRnR3OxflZLtG/AC6xCmEVtDfGq/BYZUrp+8OXVYFPqRbpb s7zbgvbbMLZ04npFsXvjLiQ6ZPAL4TaQj+xgMc/9ruOj9RSTeccJJpmHe0ZDl2JlFrnlvD Uji8EQ3LnQIlVXqE0aADPHxPlHWXWskL7iXI7876iJo3w++a2Y3xwX8UB8eU5e7Qr/gewo P1atqWngPA9WYndEq6komjBiSo7inQOU8cKeWySeaW7GIlpj7KkUQv0muCDu+0V/nCM2Zi VgfeUlMG0DvNRge/m9QLWlQsoWI/bmBsoCLqSF4WuZsSHmwSdt/4B3M5wgw6Aw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=T970uQcf; 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=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1719143241; a=rsa-sha256; cv=none; b=KrHHTUPQ95I5flRh9xz6PSIp9ylJNn3oaJnfjjETUWUExdrffA6UN8jbIJzHOlRLZcMDJJ BDDat5wlySmm5S1jzD6Gmy/LRpISG24uozcG6Keh6b0t2Q2IGPCV6CbKq4TAKrhNVrJs3C //SDoJ0jwRuw9zRp31dV3RvEFGRHY9ZWz1OguOsUlLQHVUla21Ilfh4qsA9rpN70EktVRP 1J6wF5AmNqn5zmR6EngU/kqzHeb2GUV1XKDtfeQArpQTz087rpvGPJkUGq0ueeQbp0CN3V Q8KpYvtV5r7BUQP1KFLwUd/wx3C4UmIKvrrpKtHf0Og0q7kMb4nqB56B1uM6RA== 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 1FFB468EDF for ; Sun, 23 Jun 2024 13:47:21 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sLLfy-0000UP-4h; Sun, 23 Jun 2024 07:46:30 -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 1sLLft-0000Tw-JY for emacs-orgmode@gnu.org; Sun, 23 Jun 2024 07:46:27 -0400 Received: from mail-vs1-xe31.google.com ([2607:f8b0:4864:20::e31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sLLfr-0001Ua-PU; Sun, 23 Jun 2024 07:46:25 -0400 Received: by mail-vs1-xe31.google.com with SMTP id ada2fe7eead31-48f463565ddso339807137.3; Sun, 23 Jun 2024 04:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719143181; x=1719747981; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Y02H/vxX0nPKBQKW2vL5/4lrr+hwelw+JZ2uSF7iTx4=; b=T970uQcfJEVAvrEaMmBW4KmD6BvgeBkhaamZ1c81XE9hSsZpv7FdbHqIokYsLD6QZD 4yIFSz5U/JrKLa3XnOnA6Hp9zcK4T7BeMpswt+oauA+EoInvOCMORDpMYUpCUCjSAjED 93nxBvKg89zJsAxUh5PdYMnAbSHuoQLkrKeEWJcHdrTmfWoQeWWlfe8U8ZRDqn7nzDO/ yZHxWe5DunHMaTiRKyq3uEW0I45bT/La7uHOq9+XqWHKF3kVXoP2QDu0jjuPw8QNqrf0 ANGE5zlJ53w0i+6ngDgKpOlu4ZXMs9wMyOKaUYi6x2ibrNfrp+9IUUYFcmsIXzUX8osL RUHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719143181; x=1719747981; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Y02H/vxX0nPKBQKW2vL5/4lrr+hwelw+JZ2uSF7iTx4=; b=vVFnZx4f6a2mw6t3awLd0W+BEcvawcMH6r3FkgA56sCL2BYFn+He+6ZK50slICtWOl EzvSjgZAhAuWUWII0Q5OAupr0vag60gkf5AmYdfIRo+DppP+/TtBE65ytiJQ3PtnTj8D s4RDdL0WxUmrSSPIVbh8B3c3vT5egkxvtG2V3gNBxrbhZOS/iZGahGEsndJvyEQqEvN3 xRkMk8M4bEdXV4UEh/DVF5wj7usOG9h/UG/aEoJfMDhq8Zv+o1Tj9oXuII8v1cT5pv1q gpuRqUBd5jU/4GM++NwWplEYn6DdzhM4YKSOT2ZR7wqLU78MKCZPn0uFMSbT82t1chby TyZw== X-Forwarded-Encrypted: i=1; AJvYcCXEFyWsQ5D1Vev1xpjvl4os2k2PJcEfmijBlXFbpFa7bN8Ht6dF+hrRUKB3Rvg4QiQ7U3vWky+pB6vZrAb+ZSgRV5kz7dk= X-Gm-Message-State: AOJu0YwXYzPQ7GGSvoAzDDzmC1wsdotE/H8csGZ7kyLOURg/+28rCfbS qD9mmftalLVT1atKWRNjuDkPpochoplJ19IIK87wnIxa+hj8IVzKimAagveOObkz2paHkQFg30L xYRSS5FW6aToEDJuu4EZu1rZEvvM= X-Google-Smtp-Source: AGHT+IFGtG3x834GrlUwRZGilxmwvvW3DMLi0aye7HrQCZlT5FCEl9hqhDHxLLXDlpPfj/Yd0h6a0+hu4BGAp+mbHvg= X-Received: by 2002:a67:ffd7:0:b0:48f:1674:f5bb with SMTP id ada2fe7eead31-48f529a5970mr1502975137.9.1719143181237; Sun, 23 Jun 2024 04:46:21 -0700 (PDT) MIME-Version: 1.0 References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.fsf@localhost> <87o781t676.fsf@localhost> <874j9qs0wh.fsf@localhost> In-Reply-To: <874j9qs0wh.fsf@localhost> From: Daniel Clemente Date: Sun, 23 Jun 2024 11:45:53 +0000 Message-ID: Subject: Re: Please document the caching and its user options To: Ihor Radchenko Cc: Eli Zaretskii , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::e31; envelope-from=n142857@gmail.com; helo=mail-vs1-xe31.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Spam-Score: -10.62 X-Migadu-Queue-Id: 1FFB468EDF X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -10.62 X-TUID: FBqEVzif29ik > > Thanks! > I am attaching tentative patch that improve the documentation. I hope > that it clarifies things for you. > > Thanks. I'm not sure about the "unless" part here: > Persisting the cache to disk [=E2=80=A6] > It is not recommended if the Org files > include sensitive data, unless the data is encrypted via `org-crypt'.") I first mentioned org-crypt because users of org-crypt may be surprised if they see encrypted data stored unencrypted in disk, due to this cache. A user has somefile.org which contains some headers marked with the "crypt" tag. Only those headers are encrypted. The org-element cache may now cache the whole file, including the encrypted headers (this is ok). Now the user temporarily decrypts the encrypted header, works on it some time (including closing the file and opening it again) then encrypts the section again. During the time that the header was unencrypted, the org-element cache was storing information about unencrypted data in ~/.cache/org-persist, which could even be a remote server (NFS, SMB etc), not as private as the org file itself. Apparently the data stored in the cache doesn't contain the actual paragraphs of text but it still contains plain text (like: names of tags, properties, files, macros, scheduling information), which I would call private if I'm using org-crypt. I saw some code related to the org-element cache to avoid putting encrypted files in the cache, but if I remember correctly that would be just for whole encrypted files. The part about how org-crypt works with caching could also be documented in org-crypt instead, or in the manual. The rest of the documentation change seems good, it improves things. I would just mention the shortcomings or disclaimers, if there are. For instance I worry about what may happen when different Emacs processes load the same Org files at the same time (e.g. I run several automated batch export jobs). And I guess that having a disk cache creates new problems, like when in a web browser a simple F5 won't refresh and you need S-F5. But if there are no shortcomings (i.e. all operations will always use up to date information and everything will keep working as usual when you enable on-disk cache), it's ok like it is. It's also good if it's explicitly mentioned. It could also be mentioned somewhere else, like in a cache section in the manual, if it gets one. > > My own experience, very subjective and it may be an edge case, is that > > enabling org-element-cache-persistent didn't make loading my org files > > faster; on the contrary, it made some things slower (including closing > > Emacs). > > What happens if you set `org-persist--report-time' to t in your config > and examine *Messages* buffer after opening/closing some Org files? > Look for "org-persist:..." messages. Thanks, I'll try that for some time and learn about org-persist and if there are problems I'll continue in another thread. For now I can say I see that each operation takes 0.00 or 0.01 seconds, but I have ~150 files so it amounts to a short delay (shorter than the last time time I tried it).