Re: Storing sensitive data indefinitely in variables or buffers: Whether and how to fix?

[Ihor Radchenko <yantar92@posteo.net>]

tomas@tuxteam.de writes:

>> You will hit an error, sooner or later. We are going to use cache in more
>> scenarios.
>
> I get to keep both parts, I know. I'd definitely prefer an official
> switch, but with no code to offer I won't even dare to complain :)

Maybe `org-element-cache-persistent' is enough for your needs?
This specific part can be disabled. The problem is rather with caching
previews and remote images - we previously had to rely on
`org-preview-latex-image-directory' and similar case-by-case approaches,
but aim to centralize cache storage into unified API.

>> If your Emacs is snappier without cache, you likely experience slowdowns
>> on long sessions. If so, it is another problem you are just postponing.
>
> Actually not. Rather around the start. If interested, I can try
> to provide data. But I won't bother people with it without a
> request.

If you are seeing "Reading from ... took ...sec", it may be either disk
reading speed (unlikely) or older Emacs where `read' was less optimized.

>> > I'd hate to end up with a setup like the monster browsers have
>> > these days: an obscure set of sqlite databases you need a huge
>> > amount of dedication to extract some slivers of information from.
>> 
>> I am sure we will not.
>> 
>> For multi-session, it is up to you whether to store information in
>> SQLite database or in plain text files. The default for
>> `multisession-storage' is 'files. I doubt that we are going to change
>> this default in the nearest dozen of years (It is Emacs after all :])
>
> It is not specifically about SQLite...

Well. The current de facto situation is scattered files in your
.emacs.d. Not sure how it is better.

>> For org-persist, it is designed to store disposable information that can
>> be re-generated any time. Even then, org-persist tries to keep the
>> index.eln human-readable.
>
> ...but about complexity. Having a generic cache which works for all
> applications will make the code (application code and cache data)
> necessarily more inscrutable. OTOH, every little application doing
> its own thing is problematic in its own way. As an engineer, you
> seldom win ;-)

Not sure here. I'd rather say that the situation is an opposite.
Have you looked inside index.eln created by org-persist? It is not far
from how automatically generated `custom-set-variables' reads.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>