From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id oJ/QA5jkuF8HGwAA0tVLHw (envelope-from ) for ; Sat, 21 Nov 2020 09:57:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id kF8WO5fkuF9VMQAAbx9fmQ (envelope-from ) for ; Sat, 21 Nov 2020 09:57:43 +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 3D5B6940222 for ; Sat, 21 Nov 2020 09:57:43 +0000 (UTC) Received: from localhost ([::1]:50388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgPeH-0005qk-PD for larch@yhetil.org; Sat, 21 Nov 2020 04:57:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42744) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgPdv-0005qU-JF for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 04:57:19 -0500 Received: from static.rcdrun.com ([95.85.24.50]:35659) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgPds-0000Ko-Ol for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 04:57:19 -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 00000000002C0013.000000005FB8E479.00002B71; Sat, 21 Nov 2020 09:57:13 +0000 Date: Sat, 21 Nov 2020 12:53:36 +0300 From: Jean Louis To: Texas Cyberthal 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: "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.99 X-TUID: TOBgHGBZV8P+ * Texas Cyberthal [2020-11-21 10:19]: :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 913ca9e4-17b4-4366-9a35-45838cace538 :END: > ***** Hi Ihor Radchenko, > > > I am wondering what you mean by Org's philosophy. Why would it have anything to do with directories? > > Org's philosophy is to have one or a handful of directories without > nesting of directories. Users are not expected to have their Org > files in a deeply nested tree. Org also prefers big files with large > trees rather than lots of little files. Is it? I did not know that. But it is definitely tedious to keep all Org files in one directory or few sub-directories. That is where 10 Bins paradigm becomes useful or other similar filing software. It is just good to file it into fixed place with fixed hyperlink that is easily captured somewhere. What I mean is when file is filed into ABC/STRUCT/XYZ/001/2020/11/20/2020-11-20/ is that such link can quickly be captured in some main file like: * ABC :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 8459366d-e95e-4a2f-9eac-c093375d733c :END: ** STRUCT :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 5d3b208f-dfec-4916-af7e-be784641d3f8 :END: *** XYZ :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 19705797-19b5-46d4-ab7d-2414589a5e68 :END: **** 001 :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: ddf01399-3b6a-40d5-9a8c-55cadd2d08b2 :END: ***** 2020 :PROPERTIES: :CREATED: [2020-11-21 Sat 12:53] :ID: 5faef432-0abc-4953-bd81-2ffae69ecec1 :END: [[file:ABC/STRUCT/XYZ/001/2020/11/20/2020-11-20/file.org][File.org is filed file]] When such capture is done automatically upon filing then the link may be reused in other files. By using the Meta Org File user automatically creates an index of filed files and can search for the file in the Org file itself and open the file from the Meta Org File without knowing where the file is really located. > The rules are written to be straightforward at filing time. One need > only consider one object at a time. Cascade filing means one need > only compare the object with one directory at a time. The first match > wins. I should emphasize that in the docs. > > Having all your headings jumbled into three huge files sounds like a > state of permanent intractable overwhelm to me. That overwhelm I felt myself and found similar way like you Texas to file the files and I am still expanding into meta-level of organizing things. > You are using Hyperscope as your primary PIM but integrating it with > Org, and it sounds like you're using PostGreSQL and the directory tree > together somehow. I don't fully understand it. My primary PIM is on higher level than HyperScope as HyperScope is part of PIM which I call CRM or Customer Relationship Management as it does not manage only my personal information. In the practical sense it is more or less same thing only that allows work in group. It is just so similar to various other CRM software around. HyperScope is not file system. It is dynamical knowledge repository of hyperdocuments, any kinds of documents. Other similar projects are: Semantic Synchrony https://github.com/synchrony/smsn Hypothes.is Annotate the web, with anyone, anywhere. https://web.hypothes.is/ GNOWSYS: A Kernel for Semantic Computing! https://www.gnu.org/software/gnowsys gstudio https://gitlab.com/gnowledge/gstudio Project Xanadu https://en.wikipedia.org/wiki/Project_Xanadu Those links I am quickly inserting into buffer exactly by using Hyperscope. I am just pressing one key W and hyperlink from HyperScope buffer is creating those hyperlinks above. In general it is a tree based database that hyperlinks to all kinds of hyperdocuments. Hyperdocument is also a note in the database itself. But it can be Org file or any other file regardless where it is located, be it on the WWW or file system. It can be video that I have to watch or specific part of video. Then subtrees or the whole HyperScope database can be expanded into one Meta Org File if I wish. It is not "export" in the sense but one could say it is similar to export. > Clearly a database can do more than a directory tree alone. The cost > is that a database is more complex to use and maintain. So that which > can be handled by directory tree alone, should be. File system is database. What I keep in the PostgreSQL database it can be kept directly in the file system while program can manage various other relations. There is also EIEIO in Emacs which I found recently that also may be used as a database and there is GNU Emacs database. EDB or GNU Emacs database https://www.gnuvola.org/software/edb/ and various other interfaces to databases. Database need not be complex. It carries only the structure. I find it much easier and less complex to define the database table then to work with program that has to replicate all those algorithms that databases have built-in. Database is like storage for custom variables. You have already defined 10 Bins, the database in that sense could just define more complexities while program can handle such complexities automatically. Database does not store files for file system, that is not my preferred way. It just keeps the structure for filing. Same structure could be kept with EIEIO or even with defcustom or simple lists. But when it becomes more complex that is where database becomes useful. I can keep 100 or 500 people in lists, but searching, indexing, unique IDs, all those stuff can be handled by the database without me thinking about it. Example is with unique Org IDs in the package `org-id`. I do use such unique IDs. But I have to have the package, somebody has to program the package and those unique IDs may not be so unique. For example if I copy the substree I need to take care to change the unique IDs to something else. If Org file is copied I need to take care that unique IDs get updated. There is human error involved. Database can have defined field such as `TABLE_ID SERIAL NOT NULL PRIMARY KEY` and that is is where I stop thinking about unique ID. It is unique and it is enforced over all table of items. If I wish to delete item, fine. If I wish to copy item from one subtree to other, there will be new unique ID, if I just change the parent of the item, the unique ID still remains there. Org development does try to accommodate this principle but it is text and files are everywhere so I see Org programs try to track the files, some are not tracked and so on, at some point of time it becomes not manageable. In general beyond thinking how a table should be defined there is nothing so much complex with databases. And that design and planning is usually programmed so users do not even think about database and tables. Your link `template' on the page: https://treefactor-docs.nfshost.com/ under: "Here is a template you can use to start your own Textmind. " is not working, it is asking me to sign up on the third site. These are all very useful and logical options: https://treefactor-docs.nfshost.com/2-commands/1-throw/ Myself I write Org files for planning and projects which are then executed by printing them and carrying such projects in the field. In that sense the TODO items are always repeated and I do not refile things, almost never if ever I did so. I do not remember. Often there are tasks related to people so each person has its Org file here, I do not mix information pertaining to various people in Org files. This way I can send whole file to the person for review and modifications. RCS versioning is enough to keep things simple and to see differences between the files. One subject is kept in one Org file. If something is done and not necessary to be visible it can be archived. More than that I do not re-file things from one file to other as I simply keep right Org file for right thing. Concept of refiling in Treefactor is fine concept regardless of my personal preferences. > opinions. 10 Bins is an opinionated directory tree template. You gave me idea to expand my personal organization into file system that I can forget about it. > Neither requires the other, but they're both part of Cyborganize, my > overall PIM and publishing system. Definitely I need to read more about it on your website. Jean