> > 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 […] > 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).
