From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AEiOEJubQmDrGQAA0tVLHw (envelope-from ) for ; Fri, 05 Mar 2021 20:59:07 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GNBlDJubQmA8KgAA1q6Kng (envelope-from ) for ; Fri, 05 Mar 2021 20:59:07 +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 472FD275A3 for ; Fri, 5 Mar 2021 21:59:06 +0100 (CET) Received: from localhost ([::1]:57012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lIHXN-00050B-FJ for larch@yhetil.org; Fri, 05 Mar 2021 15:59:05 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33388) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lIHWw-0004zq-NP for emacs-orgmode@gnu.org; Fri, 05 Mar 2021 15:58:38 -0500 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]:36521) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lIHWu-0004zz-9z for emacs-orgmode@gnu.org; Fri, 05 Mar 2021 15:58:38 -0500 Received: by mail-lj1-x229.google.com with SMTP id u18so4518549ljd.3 for ; Fri, 05 Mar 2021 12:58:35 -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=giOXGWeauVXlDldf/XDrtkKZ1pfxqAWQfrpA4PZ13fQ=; b=WONwpQULzuhS5hJNJkNsLAhIt0VRU5QNYSWjCMUEDX9btYZNYD2Kxj5HTsiesKzxcp k9snRcYIe1MraW5eZNBihJ5UjVQQcSXsbjyBvasJwniEcCu5tdLmYFqSWIG9T9itirr8 ykIDJ8Xqq+xocTQyfi/XjeImSqM3wX1nLKoH1sCgKiS+k490ww4IjYIOiiRFc9UH137z O61vcSv9q92X/vbFNAc2/HoDKYfe5Vsmx1EZJmAHtFPpY5F4xpawtM4osBYSwwnieHK+ VvLoW1gpoTLA9I4641duN8m+ClqYr/B80USYvD3vSkcYH+nDFekM9flU2jX35SHK4QgI 0ZrQ== 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=giOXGWeauVXlDldf/XDrtkKZ1pfxqAWQfrpA4PZ13fQ=; b=DiQEKvIdslBfbHQ+xSCkBSPe4vR8gnFAsdKTf8MPWLgoLCz3rwA1QV6tbpillJJXVg SRTevieKYjy+/28QBMaqK74ndpbkPM6tbtoT5VskJ2aUH1I86oo26utn70CnsYBQ5un4 2H5HJDrllaAs4mHuWKvCRiOGaiXeDlgs7cU3nvko8+gkpzluPw1EEHfiQ0CfUMjIj34c NRO7BLDmZ5QrIZ0sb1rr5PgAtu7xYD+UAmmAfJ9EWvf9gn/svPOEd/+6KciS6S6lYbpA qxH1AMKy1Strs8hYBLfWpuEuIf6STxOVm6Tsey/oln/UZHYtU9XgmQwzjLCwjiwTl9UO 41Zg== X-Gm-Message-State: AOAM531SFhFA5gnVIe54VVsMS8gqO9SCzJ8LaCYxbBNdAt5tqAJ1GLYq xclXZkX+SwipDkkTFPcZhrh7xeNbPsS/BLGlFZI= X-Google-Smtp-Source: ABdhPJwavJ87Vsr7B/ftXNh4ieh2Ly+HK9ASWoZ+/BsjzAxCfmByKHfoz4AoT350aJR0FiWm8hZfQTwQMDxo4rXG8kk= X-Received: by 2002:a05:651c:118b:: with SMTP id w11mr2773701ljo.223.1614977913130; Fri, 05 Mar 2021 12:58:33 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ab3:7842:0:0:0:0:0 with HTTP; Fri, 5 Mar 2021 12:58:32 -0800 (PST) In-Reply-To: References: <84cd818a511bdf2f58391599f1d1eb16@isnotmyreal.name> <8735xa1xyf.fsf@gmail.com> <48f365833e9f2573519494df6517aa42@isnotmyreal.name> From: Samuel Wales Date: Fri, 5 Mar 2021 13:58:32 -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::229; envelope-from=samologist@gmail.com; helo=mail-lj1-x229.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=WONwpQUL; 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: 472FD275A3 X-Spam-Score: -3.06 X-Migadu-Scanner: scn0.migadu.com X-TUID: N7h0dPxk36nr i should maybe point out that my focus in op is merely, literally something like "possibilities for code for helping the user archive or delete stuff in existing bloated org files". but i am also ok with tangents like other ideas for speed and less clutter and organizational tricks and so on. this mailing list in the old days used to talk about such things. like, what's a project, what does next mean, "is gtd for me", "at some point you have to actually /do/ a task", and will the org system get bloated and slow for users in the future. On 3/5/21, Samuel Wales wrote: > 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 > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html