From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id wFJQLt6ZQmCRDQAA0tVLHw (envelope-from ) for ; Fri, 05 Mar 2021 20:51:42 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id +K39Kd6ZQmBicwAAbx9fmQ (envelope-from ) for ; Fri, 05 Mar 2021 20:51:42 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id CCACB272E9 for ; Fri, 5 Mar 2021 21:51:41 +0100 (CET) Received: from localhost ([::1]:48678 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIHQC-0000rP-OK for larch@yhetil.org; Fri, 05 Mar 2021 15:51:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIHPo-0000qn-3c for emacs-orgmode@gnu.org; Fri, 05 Mar 2021 15:51:16 -0500 Received: from mail-lf1-x12f.google.com ([2a00:1450:4864:20::12f]:36954) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIHPl-0001lE-Hh for emacs-orgmode@gnu.org; Fri, 05 Mar 2021 15:51:15 -0500 Received: by mail-lf1-x12f.google.com with SMTP id n16so5880666lfb.4 for ; Fri, 05 Mar 2021 12:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bzLqY0oz3uV9I8vsHjIIk0uqB96ouAsCJBAzm+1qfT0=; b=qxzyUWWqciaxipVCy4VwUMoh7YU3FosO0dXRD157CehyVnwvnDBEaMkzgC621zLu8V 7mwzqpD6kTMxRPnZWRDpK6H/87/jefHg3sycVgU5yG7elolGR+xY9d0YtnYiEgDY/jFY 2TGY+CtgVdWBtzApOjZTTiEvt7JaxvFZRJP8eLk0E2Ns9aiylOrxvb7Hyo90sPpTgfSv U43xpcdZ1+PPA0G8KWCMnUCcf6Adgw8aRlfsxIPG/zb4D7WSPndB4o0p8mR2znK/Y6cg hzr5j6X7T6jwN5oJ3MyGFg5293hlR6TDrXDYe5JPJ0zzG92xC5lTapmwlj1VWmGuTDP6 dVXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bzLqY0oz3uV9I8vsHjIIk0uqB96ouAsCJBAzm+1qfT0=; b=sj6diL9O1sggszzGJWjB3uGA2oEfgKA1S/fM90viku5AS2O/RYAluwC9YfrQ5bZDfu fQq6DfG2ur0i34ouJd5lLqsA2tvnv2G0widgxKruOENGqoUJX4YEgCCB9O6Os6lQcLe9 /AipJnNjkEGir5/h0o/H6sQGfCSdLGFIWuoB8gYaKRl9NA97+a8BoRcXu3yyHN4udNtC EV0BO+jMJd8gndcM6FNnYkUh6jxfpiNaUteEvwMkdJeNR0ShtUj09XzaR2+PZ1DE/Jfa WOn26kDg3Rgj2Pyh8kEnxkyMv7oiiRZvJeC+xPAxWmZC5tapHFbLY8qGYRQajC2CBaLz pcAg== X-Gm-Message-State: AOAM530K0LZMM6K2mHWZ5YnpOEP/YyPYyWqoqBBTmd5bfU2csAxZScEv Vhi1UDNwa38upb98lKr276gvPifv3rRGbt8QW4o= X-Google-Smtp-Source: ABdhPJyLmHvSKHd4QREJhVm/K4I3ma3Gpv5+aCmCRbjjVSX83NSPVQyol9EaD0SHHdvkesBkgqafE3cuLPfUT8kWqT4= X-Received: by 2002:ac2:5146:: with SMTP id q6mr2378017lfd.441.1614977471186; Fri, 05 Mar 2021 12:51:11 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab3:7842:0:0:0:0:0 with HTTP; Fri, 5 Mar 2021 12:51:10 -0800 (PST) In-Reply-To: <48f365833e9f2573519494df6517aa42@isnotmyreal.name> References: <84cd818a511bdf2f58391599f1d1eb16@isnotmyreal.name> <8735xa1xyf.fsf@gmail.com> <48f365833e9f2573519494df6517aa42@isnotmyreal.name> From: Samuel Wales Date: Fri, 5 Mar 2021 13:51:10 -0700 Message-ID: Subject: Re: Culling org files (notion of Types, many small vs few big files) To: TRS-80 Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::12f; envelope-from=samologist@gmail.com; helo=mail-lf1-x12f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.06 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=qxzyUWWq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: CCACB272E9 X-Spam-Score: -3.06 X-Migadu-Scanner: scn1.migadu.com X-TUID: WgPlej9V1CXL 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 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 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