Re: One vs many directories

[Texas Cyberthal <texas.cyberthal@gmail.com>]

Hi Arne,

*Almost* any computing cost pales, but not the computing cost of Emacs
choking on rendering large files.

Doubtless there are ways to mitigate that issue.  I'm unsure what the
tradeoffs would be.  Perhaps my Spacemacs does too much prettifying of
my Org buffers.  But I like pretty buffers.  It's easier to just stay
under 1 MB file size.

File opening cost should be reduced by storing text files on an SSD.
A small one will do.

Textmind/Exomind buffers should be left open.  Thus the opening cost
is paid once per session per needed file.  That is acceptable.

I'm not sure what kind of lagless Org database operations are required
in your workflow, but I suspect they could be mostly replaced by a
proper Textmind workflow and 10 Bins structure.

The alternative is to do everything in a few big files.  Org has too
much potential to misfold or otherwise mangle huge outlines in ways
difficult to spot and repair.  Nor do I want to squint at endless
asterisks when I could have Dired ergonomics instead.

Grepping my 94 Mb 6562 files (excluding archive) Textmind for
"elephantine" takes a few seconds, which is fine.  Org searching for a
nonexistent UID link takes a few minutes, which is why I run that
search nightly, to refresh the index.  My Org Agenda search scope is
only 252k in 58 files and is effectively lagless.

I guess I avoid the problem you're talking about by mostly excluding
bulk prose from the Agenda directory.  They're fundamentally different
and should be handled differently.  One is about human language, the
other is about database metadata.  The temptation to do everything
inline just because Org supports it is one of Org's biggest traps.
It's like the trap of trying to outline strictly when you should be
rambling.