From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id oBW1Nf4UQWCVOQAA0tVLHw (envelope-from ) for ; Thu, 04 Mar 2021 17:12:30 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id wNh7Mf4UQWDVbwAAB5/wlQ (envelope-from ) for ; Thu, 04 Mar 2021 17:12:30 +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 20A4F1967F for ; Thu, 4 Mar 2021 18:12:29 +0100 (CET) Received: from localhost ([::1]:57024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lHrWW-0003Lo-HU for larch@yhetil.org; Thu, 04 Mar 2021 12:12:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHrVG-0002JF-W0 for emacs-orgmode@gnu.org; Thu, 04 Mar 2021 12:11:14 -0500 Received: from server173-4.web-hosting.com ([68.65.122.210]:56797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lHrVD-0006TJ-02 for emacs-orgmode@gnu.org; Thu, 04 Mar 2021 12:11:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=isnotmyreal.name; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:References:In-Reply-To:Subject:To:From:Date:MIME-Version:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z7DJ5iC7PIHfBzOLu60URgPhiNoc3mHWbIRzYcQbsDA=; b=QJcLrovZmbC0z5MBjFQZOWZFFi F6gUjVFi2OrCopFQEPMFVd3ecph7rrsAgjq5IkKfMSLTZ/TpX62oDik6HnNH0FPCCwXMjYHH9giTs 4AYrXTwTd3caXra5rzWX/WROWy1GO4HalnDzqwFopHfCW128B4qOwmtPEeCp1ogVZ2mHmjFSFfX+o qcQJeIi6xN/1tdYkSmqiYmEOPa5oMY8onpfuLc3cPBRVfQmDt8dUYJFfMtS5ntgDcQQtbIE+104qD gbqzxSkz3BK1k2p9QxuEZd3GWiA+Yz9wFxSdKhVtwlF78BlRbFSAB44oFxcKKFqb6U/+kW8W3xAr/ RTdXOyhg==; Received: from [::1] (port=33156 helo=server173.web-hosting.com) by server173.web-hosting.com with esmtpa (Exim 4.93) (envelope-from ) id 1lHrUQ-002eyo-An for emacs-orgmode@gnu.org; Thu, 04 Mar 2021 12:10:22 -0500 MIME-Version: 1.0 Date: Thu, 04 Mar 2021 12:10:18 -0500 From: TRS-80 To: emacs-orgmode@gnu.org Subject: Re: Culling org files In-Reply-To: References: Message-ID: <84cd818a511bdf2f58391599f1d1eb16@isnotmyreal.name> X-Sender: lists.trs-80@isnotmyreal.name User-Agent: Roundcube Webmail/1.3.15 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server173.web-hosting.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isnotmyreal.name X-Get-Message-Sender-Via: server173.web-hosting.com: authenticated_id: lists.trs-80@isnotmyreal.name X-Authenticated-Sender: server173.web-hosting.com: lists.trs-80@isnotmyreal.name X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Received-SPF: pass client-ip=68.65.122.210; envelope-from=lists.trs-80@isnotmyreal.name; helo=server173-4.web-hosting.com X-Spam_score_int: -4 X-Spam_score: -0.5 X-Spam_bar: / X-Spam_report: (-0.5 / 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, HAS_X_OUTGOING_SPAM_STAT=1.583, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1614877950; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=z7DJ5iC7PIHfBzOLu60URgPhiNoc3mHWbIRzYcQbsDA=; b=Ew7NtX8GJ50V5XiyfygEy+WRKpoNYCZBVQfHw5ME/j9bA8b9cpG0hN1xG2YjZauxgXEjO+ gAJpyT9DJ/6pYQluNmmLahUTMGynD7ZZBTwuU/uqCMUEafBQQt1lVtOOinBoHpOOKxU6mw jJzYlw7xpA3soZmidqms7SqUVoqKQ0G/V8gWmyUPy9qZq88XuAXyr0YdK08X2KzzZoOfNx dcCnKEnjGxHO1zgPwcsCdymD4yeHmCqBPo6mS1gspUVK7TRK51UW5LeJjQ4r4qkW2qsle+ UQIYwu/KzXJXFzoW5c9OZsBlQRqWvAUC8kwz0srtcZSbqrhPG+uFtmgC4j4PDw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1614877950; a=rsa-sha256; cv=none; b=SfetHVjyPeAtvOBjWWCvzsSMXhILx8H6HxnCfMhU1k73h7PHta6jkC600raIEWauwCw6Dm mSG9fLLToST4r3u19vcX76WKic3DKY01LBe7t3ilnL7dmxDaQOsLOpAaaeyh2NR8OS1U9k 8EFy5M+amEjXmWUtKmxukhJRhZ+fJx599P6FCAtztNiOjuRBafT4/vvBwYZpv+jAYNjKk3 RTfQqcQj5PoNbO7QB+nIkMi1TsydOnotNkArOmm9TAxYa3AshJlogAC7duLSUqsw7ejV6U 7eP1kvdq+I9Bbhr6uYtWIWiW7GS+i3LkxEWxpHnxDeHSpRwc+4/qgW+w+xZPrg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=isnotmyreal.name header.s=default header.b=QJcLrovZ; 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-Spam-Score: -1.36 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=isnotmyreal.name header.s=default header.b=QJcLrovZ; dmarc=none; 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: 20A4F1967F X-Spam-Score: -1.36 X-Migadu-Scanner: scn0.migadu.com X-TUID: 0q/IninOKFTy On 2021-03-03 16:59, Samuel Wales wrote: > along lines of reducing logbook entries I guess you must have picked up on my comment in another recent thread. :) > i often want to reduce org > files, and i wonder if anybody already had the same desire. > > here are some random ideas. my org files are so > large i might have written this list a few times.... > > 1) list links to duplicate headlines > 2) list links to duplicate body text > 3) list links to duplicate entries > 4) list links to duplicate entries, body text, or > headlines using fuzzy matching > - suppose you captured an email slightly differently a > few times > 5) show in agenda the biggest few tasks so you can go to > them and reduce them or doneify them > 6) (waves hands) git magic to find old entries that might > be stale > 7) show in agenda the tasks with biggest logbook drawers > so you can go to them and reduce them > 8) find similar body text that are in distant subtrees > that might be candidates for refactoring using org-id > linking > 9) show in agenda deepest olpath levels > 10) indicate deep, shallow, text-filled, etc. top levels > 11) show in agenda entries with most children > 12) archive logbook drawer entries older than 1 year > - get rid of drawer if empty > - put the drawer entries into a logbook drawer in a > new task, with a similar header, that then gets > doneified. then that gets archived when you archive > stuff. > 13) operate on lines matching a pattern > - e.g. "* [2021-02-17 Wed 20:35] whatever" lines > might be insubstantial notes that do not need to > clutter the inactive timestamp display in the agenda > and thus should be moved to a target location with > query > - that target location would presumably not be in an > agenda file > 14) function to lint all agenda files > 15) reduce false positives in lint > > well, idk if htese are good ideas. just thought maybe we > could form a cult of "don't let org files get too big". I have come to similar conclusion about "don't let org files get too big." Besides agenda speed, I think it is just easier to conceptualize things when each file covers only a limited scope, trees are more shallow, etc. So, lately (last year or more), I have been trying a "many small (up to perhaps medium)" instead of "few big" files approach (along with some custom tooling) and it has been working /a lot/ better for me. I really feel on top of things for the first time in a long time. My agenda is not cluttered. I can focus on important things, while not losing track of the rest, etc. I could write a whole lot about my "custom tooling" but as that is an entire package in its own right (still in experimental development and thus unreleased), I will limit my comments here only to the "archival" portion of this problem. I realized, at least in my case, after mulling this over for some time, that there seem to be a few distinct cases which would need to be handled by a custom archival function: - If the TODO is still active, and the number of logbook entries exceed some (definable) threshold, either move the older entries to a similarly named archive file/heading, or (also definable) simply delete them. This would cover things like habits and other recurring tasks that tend to generate lots and lots of entries over time. This is perhaps the part I mentioned in the other thread recently. - If the TODO is completed (and perhaps also after it becomes a certain (again, definable) age), then move the whole TODO to a similarly named archive file. - There was another, but I think it was for the case where the entire file is a project (which is a bit specific to my own setup). Ideally, this custom function would handle all the above cases, and could be called with point at each headline, so it would be easy to map over a file or even a directory full of files, in order to automate the archival process (perhaps annually?). Cheers, TRS-80