Re: One vs many directories

[Ihor Radchenko]

>> I am wondering what you mean by Org's philosophy. Why would it have anything 
>> to do with directories?
>
> Org's philosophy is to have one or a handful of directories without
> nesting of directories.  Users are not expected to have their Org
> files in a deeply nested tree.  Org also prefers big files with large
> trees rather than lots of little files.
>
> By philosophy, I mean the dev consensus on the correct way to do
> things, and coded configuration and usability biases.

I believe that org support all possibilities. The user can decide to
keep many (possibly nested) org files, a few large org files, or
anywhere in between. There are several parallel feature sets allowing to
work in a single file as well as with a bunch of smaller files.

For a single file, the user can search headings with org-goto (without a
need to explicitly travel through all the nesting headline levels),
reveal only headings satisfying certain keyword/tag/any other search
criteria with org-sparse-tree, or built agenda views restricted to a
single file (or even subtree).

For multiple files located anywhere in the filesystem, there is always
org-refile capable of filing the information to proper place or
searching deeply nested headlines with ease regardless of the file the
information is physically located in. Headlines from multiple files can
be grouped using agenda views for any given search criteria (showing
todo items or items for a single day/week is just a tiny subset of what
agenda can do).

Best,
Ihor

Texas Cyberthal <texas.cyberthal@gmail.com> writes:

> ***** Hi Ihor Radchenko,
>
>> I am wondering what you mean by Org's philosophy. Why would it have anything 
>> to do with directories?
>
> Org's philosophy is to have one or a handful of directories without
> nesting of directories.  Users are not expected to have their Org
> files in a deeply nested tree.  Org also prefers big files with large
> trees rather than lots of little files.
>
> By philosophy, I mean the dev consensus on the correct way to do
> things, and coded configuration and usability biases.
>
> I know this is Org's philosophy because I violated it thoroughly when
> writing Treefactor documentation, and was told as much.  I can see how
> it wouldn't be obvious to casual users.
>
> Good idea, I'll comment on Voit's article, thanks.
>
> ***** Hi Palak Mathur,
>
>> it seems overwhelming to have 10 directories. I am not saying it is not good 
>> just that I will not be able to handle those.
>
> I didn't anticipate this problem.  Maybe practicing with Treefactor
> and Dired would build this muscle over time.
>
> The rules are written to be straightforward at filing time.  One need
> only consider one object at a time.  Cascade filing means one need
> only compare the object with one directory at a time.  The first match
> wins.  I should emphasize that in the docs.
>
> Having all your headings jumbled into three huge files sounds like a
> state of permanent intractable overwhelm to me.
>
> ***** Hi Jean Louis,
>
> You are using Hyperscope as your primary PIM but integrating it with
> Org, and it sounds like you're using PostGreSQL and the directory tree
> together somehow.  I don't fully understand it.
>
> Clearly a database can do more than a directory tree alone.  The cost
> is that a database is more complex to use and maintain.  So that which
> can be handled by directory tree alone, should be.
>
>> I can find a mining engineer in country Senegal if I wish so, that has some 
>> work experience and I can see files pertaining to this person. But not that 
>> I would make file system directory Senegal to find the files for this person
>
> Of course not.  You would find a person under his name, not his
> country.  The person can move to a different country, after all.  At
> most you might link him to the country, as part of a list of people
> from X country.  But that is something better handled by a real
> database.
>
> To clarify, Treefactor is just an Emacs package with some minimal
> opinions.  10 Bins is an opinionated directory tree template.  Neither
> requires the other, but they're both part of Cyborganize, my overall
> PIM and publishing system.