On Thu, Jun 01, 2023 at 06:34:51AM +0000, Ihor Radchenko wrote: > writes: > > > I'm already wrangling with Org caching (for now, my sweet spot > > seems to be directing it to a non-existing directory and ignoring > > the complaints: paradoxically, Emacs is snappier then). > > 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 :) > 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. > > 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... > 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 ;-) Please, don't take my complaints all too seriously. You are doing a huge work; although I don't always like the direction taken, I do admire what you're doing. I feel free to fat-finger it strategically here and there to fit my needs :-) Cheers -- t