From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SJolEfvYuF/xQwAA0tVLHw (envelope-from ) for ; Sat, 21 Nov 2020 09:08:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id kCz6DPvYuF+CFQAAB5/wlQ (envelope-from ) for ; Sat, 21 Nov 2020 09:08:11 +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 AA1069402C8 for ; Sat, 21 Nov 2020 09:08:10 +0000 (UTC) Received: from localhost ([::1]:60918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgOsL-0002q9-3y for larch@yhetil.org; Sat, 21 Nov 2020 04:08:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49218) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgOpB-0001xe-TJ for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 04:04:53 -0500 Received: from static.rcdrun.com ([95.85.24.50]:43523) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgOp9-0006sR-Sr for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 04:04:53 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0003.000000005FB8D831.000025F3; Sat, 21 Nov 2020 09:04:49 +0000 Date: Sat, 21 Nov 2020 12:04:39 +0300 From: Jean Louis To: Palak Mathur Subject: Re: One vs many directories Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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: Texas Cyberthal , "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; 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-Spam-Score: -0.51 X-TUID: e3H3VbsZl/fU * Palak Mathur [2020-11-21 09:13]: > On Fri, Nov 20, 2020 at 6:34 PM Texas Cyberthal > wrote: > > > > Having a tall directory tree with many leaves and branches is against > > Org's philosophy. > > > > Here is my argument that such a structure is objectively correct for > > personal info management: > > > > https://github.com/cyberthal/10-Bins-template > > > > For the record, Org works fine with this, although I had to do a bit > > of config to get around the default philosophy. > > > > I read through the README but it seems overwhelming to have 10 > directories. I am not saying it is not good just that I will not be > able to handle those. Even now when I have just three main files - > inbox, work and archive, I am very bad at refiling items (I do it but > rarely). I mostly rely on Agenda views to make things make sense for > me. With 10 directories, I will surely never be able to refile > anything as half of the time I will just be spending time in deciding > where the item belongs. > > It surely will be good for more diligent people unlike me. Thank you for nice description of your file system. In my opinion for your use case the 10 Bins system looks very appropriate. One point I wish to present, that is that WHERE the file is stored need not be known to user. And when file is retrieved this also need not be known to user as user may search how Texas said by X methods. Since Texas have presented 10 Bins now I am eagerly wanting to organize all of the file system into structure that does not let me think where the file really is located. My structure is so much more complex but I do not think about it, computer is filing it for me. I think of people, groups, lists and I find files by thinking, not by looking into file system at least not so much. When I think of Texas I write: Texas, I find 12 contacts related to Texas, then I write "Emacs" or "Cyber" if I remember Cyber. From there on, I can see hyperlinks to 10 Bins system, I can find emails of Texas Cyber and find files and his Org file as well containing notes to Texas. But I have no clear idea where that file is really located on the file system. When finding the file I find it by X methods without knowing where it is located on file system. Basic structure any filing including emails could be following: 1. INBOX, items are coming here, if inbox is not empty something is wrong. Handled items should be filed appropriately. I file emails into maildir folders like ~/Maildir/person@example.com 2. PENDING, those are things that cannot be handled for some reason, and because they are not handled they cannot be yet filed. 3. OUTBOX, those are things that need to be filed or dispatched. For example fax that has to be printed should be there. PDF export of Org file can be there as it has to be placed on USB stick to be brought to printer. SMS notes to be yet sent to people or files to be sent to people could be there. OUTBOX can be also handled by other people, not necessarily the organizer of things. 10 Bins system expands that not so related and offers more structure. There is need for org-of-org.org file that is meta Org file and that could be created on-the-fly Meta Org file by imagination named here org-of-org.org would be created based on information of: - filing the files and any types of hyperlinks like videos, movies, etc. including Org files. Upon filing such hyperlink has its structure stored somewhere. - retrieving of the files, as some files are not filed but are retrieved or launched. Retrieving files could then be logged or accounted in the file system or database for later on-the-fly referencing from org-of-org.org file. Then org-of-org.org file would be created on the fly: - it would create hierarchy of all filed files that helps the user locate the file easy without even knowing where the file is on file system - it would use the list of retrieved files to create the structured hierarchy of the retrieved files by its subjects, tags, groups Then user can click and get the meta Org file created on the fly and pinpoint where else to go with attention.