emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: TRS-80 <lists.trs-80@isnotmyreal.name>
Cc: emacs-orgmode@gnu.org
Subject: Re: Culling org files (notion of Types, many small vs few big files)
Date: Fri, 5 Mar 2021 13:51:10 -0700	[thread overview]
Message-ID: <CAJcAo8vBVcU94XXVgRhVO+EEJwKpZteJrszLbFmp6-FTF5De2w@mail.gmail.com> (raw)
In-Reply-To: <48f365833e9f2573519494df6517aa42@isnotmyreal.name>

the closest thing i have to types is merely this

- some files go in org-agenda-files, by basename pattern
- some to text search extra files, pattern, don't need the tses
- some to neither, no pattern [blog.org]
- some get put manually in refile targets

which has no real connection to either ontology [like hvac], or
types/purposes/statuses [like your project type] as you have.

it is merely what things i need in ts agenda vs. search agenda view.

to me the outline is a forest with the tree problem [i.e. the fact
that we want graphs not trees] kludged using id links and searching.
files are major categories.  too many and i get confused what is
where.  tree structure is by ontology, not types.

i think my agenda views therefore wouldn't be any less cluttered or
confusing if i had more files or shallower trees.  [assuming i set
category property which i do.]  so that is why i was confused by your

i find that the more complex a system i develop, the more i regret it
later because i can't just reverse it, i can't do maintenance at
anything close to a sufficient rate, and i get confused.

the ts comment i made is merely that i do like "***** LOG [2021-03-05
Fri 13:44] hi" usefully.  not sure if relevant.

On 3/5/21, TRS-80 <lists.trs-80@isnotmyreal.name> wrote:
> On 2021-03-04 16:11, Samuel Wales wrote:
>>> tim> naming convention ... to determine what is included
>> this is also what i do.  org-agenda-files is just set at startup
>> according to basename pattern.
> I find it very interesting that all three of us seem to have
> independently arrived at some of same conclusions.
> Originally I did not want to go off on this tangent, but now I wonder
> how close what I am doing is to what you guys are doing.
> In my case, I came up with some notion of "Types."  Each Org file MAY
> use one of a list of defined Types at the beginning of the file name
> (which is also the first top level headline in the file, starting at
> position 0), followed by a delimiter (currently ": ").[0]
> I keep experimenting with my list of Types (I probably have too many),
> but there are a few that definitely seem useful so far.  For example:
> - Project: Pretty self-explanitory.
> - Area: A concept lifted straight from PARA Method ("a sphere of
>    activity with a standard to be maintained over time").[1]
>    - Equipment: A special type of Area: that pertains to a single major
>      piece of equipment (like a vehicle) or some group of related
>      equipment (e.g. "small shop equipment" or "home appliances",
>      etc.).
> - HowTo: Literally "how to do x" which is great for remembering those
>    obscure command line invocations (or whatever) that you only use 2x
>    per year.  Combined with headline level completing-read search (see
>    below) this becomes very powerful/handy.
> So then, by default, any of Org files starting with either Area:,
> Equipment:, or Project: are the only ones that are considered "active"
> for purposes of agenda and scanned for TODOs (implemented as a simple
> `directory-files' function and a regexp).  I use my system as a
> combination of TODO and PIM[2], so this makes a nice logical split
> where all those PIM "random notes" do not impact the agenda
> performance whatsoever.
> I have some other custom agenda functions as well, for things like
> periodic reviews (in the GTD sense) and others.  Org's Agenda really
> is essentially just like a database query engine when you get right
> down to it (except storing in plain text of course).
>>> trs> [smaller files] My agenda is not cluttered.
>> it is not clear to me why more smaller files and shallower trees in
>> the outline would improve the agenda.  sounds good though.
> I somewhat addressed this above with Types (which improve
> performance), but as to your specific point (clutter)...
> OK, so maybe not /directly/.  But rather the whole system have
> improved my engagement, by way of no longer feeling lost/overwhelmed
> as I did with very deep trees in only a few files.  I think it is just
> easier to reason about some small subset of the whole at one time, as
> represented in a single file.  In theory, I guess you could accomplish
> the same by narrowing subtrees or other methods, but for whatever
> reason separate files seem to appeal more to me than those other ways
> (probably because they are also faster to navigate, among other
> benefits).  However, to each their own here, I suppose.
> I think I was also responding to some specific comment you made about
> time stamps (re: "cluttered").
> There is also this whole "inter linking" / "atomicity" thing.  I came
> to Orgmode from TiddlyWiki, and that was the only thing I missed, this
> notion of many small "atomic" nodes, which could then be put back
> together in many different ways (links, tags, etc.) as opposed to a
> (usually single, large) tree which (at least somewhat) imposes a
> particular structure and implicit categorization.  Nowadays the
> Zettelkasten stuff have become quite popular, but it is exactly the
> same notion.  Tree knowledge structures are great when many people
> must share the same info, for example law codes.  Or reference
> manuals.  But in our own PIM, we should be more free to link
> information together in whatever way suits our own brains.  And be
> able to link it back together in multiple, sometimes differing, ways.
> I seem to also recall some discussion of research even supporting the
> idea that our brains actually function more like an "interconnected
> web" than a "tree" structure (can you tell I am a bit of a PIM geek
> and have been interested in this subject for some years now?).  :D
> Thinking further, I guess my usage has also become possible by some of
> the search and other tools I have built /around/ my directory full of
> small files, which obviate some of the reasons for keeping things in
> "one or a few big files."
> One example is my custom headline search function (which uses grep
> under the hood)[3].  It has been very helpful in being able to locate
> things.  Now I have a completing-read search over all headlines in all
> my files (which will jump to that location upon selection).  I have
> found that by carefully constructing headlines that this works "well
> enough" for almost all my search needs so far.[4]
>> On 3/4/21, Tim Cross <theophilusx@gmail.com> wrote:
>>> My use pattern also constantly evolves as my requirements and
>>> priorities
>>> change. It is and probably always will be, a work in progress!
> I consider mine an ongoing experiment as well, which is why I have not
> (as of yet) published anything.  But I'm glad I decided to discuss it
> on the list, as now I see I'm not the only one to reach some of same
> conclusions!
> Cheers,
> TRS-80
> [0] But I need to change that because colon I learned is an illegal
> character on exFAT file system (i.e., larger SD cards, which becomes a
> problem when syncing to mobile).
> [1] https://fortelabs.co/blog/para/
> [2] Personal Information Management
> [3] So it doesn't need to open a bunch of files in Emacs / Org.  It's
> also fast enough (so far) to use "live."
> [4] I originally planned to implement additional full text search
> functions using things like org-ql, [rip-]grep, and/or Recoll, but so
> far this has proved to be unnecessary.

The Kafka Pandemic

Please learn what misopathy is.

  parent reply	other threads:[~2021-03-05 20:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-03 21:59 Culling org files Samuel Wales
2021-03-04 17:10 ` TRS-80
2021-03-04 19:25   ` Tim Cross
2021-03-04 21:11     ` Samuel Wales
2021-03-05 16:12       ` Culling org files (notion of Types, many small vs few big files) TRS-80
2021-03-05 20:32         ` Tim Cross
2021-03-05 20:51         ` Samuel Wales [this message]
2021-03-05 20:58           ` Samuel Wales

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8vBVcU94XXVgRhVO+EEJwKpZteJrszLbFmp6-FTF5De2w@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=lists.trs-80@isnotmyreal.name \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).