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
comment.
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...@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 <theophil...@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.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
