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 WCY2D2JNuV/YUQAA0tVLHw (envelope-from ) for ; Sat, 21 Nov 2020 17:24:50 +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 8AX1CmJNuV/UawAAbx9fmQ (envelope-from ) for ; Sat, 21 Nov 2020 17:24:50 +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 CCC5E94028F for ; Sat, 21 Nov 2020 17:24:49 +0000 (UTC) Received: from localhost ([::1]:38686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kgWcy-0001di-P9 for larch@yhetil.org; Sat, 21 Nov 2020 12:24:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38780) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgWcT-0001bt-Cg for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 12:24:17 -0500 Received: from static.rcdrun.com ([95.85.24.50]:46531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kgWcR-000272-07 for emacs-orgmode@gnu.org; Sat, 21 Nov 2020 12:24:17 -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 00000000002C000B.000000005FB94D3D.000072E1; Sat, 21 Nov 2020 17:24:13 +0000 Date: Sat, 21 Nov 2020 18:45:08 +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.51 X-TUID: liQxNpw5kJYY * Texas Cyberthal [2020-11-21 17:45]: > Hi Jean, > > > 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. > Such a set of links could easily grow out of date if paths change, and > I wouldn't want to maintain it. If the paths never change, then I > would memorize the paths and linking them would be slower than Dired > walking to them. By principles of Doug Engelbart, once file is filed, it should be there and nowhere else, it becomes more or less static. Then you have some kind of DKR or dynamic knowledge repository that tracks where such files are. Let us say that DKR provides you with the hyperlink "K12A". This link is is then referenced from all other files. If the underlying location of the file changes, but it should not, all the hyperlinks remain always the same. > I do have a method called "Zinks" for managing UID links. It permits > paths to change without breaking anything, both target and source. > However, in the vast majority of cases I find it much easier to just > walk the directory tree. I doubt one can appreciate how useful a tree > synced to one's mind is until one has experienced it. The tree adapts > to the mind and vice versa. That is good and useful. While I do order things in a tree it is not that I think of those tree in hierarchical sense. By habit I could maybe remember but because it is not necessary to remember, it is not useful, then I don't. What I remember is the sub-tree name. For example Emacs or Emacs Lisp, then I just do the helm or ivy or other completion and find the subtree. From there on I browse for information, file it, open up or launch hyperlinks. It is not browsing the tree, it is more direct jump to the relevant part of the three. And if hyperlinks are represented as (hyperscope 123) then regardless if such link moves from subtree to subtree or underlying information changes somehow the reference to that link remains always same (as long as ID is always same). > There's no need to know the exact locations of files; walking there > is informative and useful. Or, for the trivial paths, walking is so > quick that it is faster than searching. That is good and isn't it general way of sorting things? I guess that general computer users may not be aware that they could make nice hierarchical tree of directories. System that users are offered are file managers and such are way to abstract for today's users. Back in time we did not have that many files, today we have loads and loads of files. Those programes named file manager do not manage anything by themselves. And they should. User should choose to file a file, and by any type of paradigm, user would maybe answer just 1-3 questions and file would be filed into appropriate place. It could be retrieved as fast as filed. That would be semi-automatic file management. If all files would have its meta-data then automatic file managemet could be possible. Then it would be known who is author, what is subject or tag of the file, what is its title, date of writing it, permissions (not file permissions but access permissions) and similar. Then program could file those files automatically. For images named IMG_2020111012345.jpg is possible to parse image names and if not image names then the built-in EXIF data and file all images by their dates automatically. Bunch of images coming from camera and they need to be sorted by date so in that case it can be automatic. Text files do not have its meta data. Org files could be said to have as there is TITLE and AUTHOR, DATE. But there is no rule for meta data. Good set of principles or rules when creating files could create meta data and by meta data files could be automatically filed and easily retrieved. > Search spawns distracting mismatches to read, whereas walking the > tree progressively narrows scope in a mentally comfortable way that > focuses the mind while error-checking each step. It's very > comfortable to reach the destination and be confident from the > process that I'm in the right place. That is exactly same mental concept that I use. It becomes pleasure as well. I could watch videos of other similar creators as you and I can feel the pleasure in their voices and I can understand the piece of mind when files are sorted. Unsorted files do bring mental mess in the person's mind. > > File system is database. > > Barely. Databaseness is a gradient with file system at one end and > PostGres at the other. > > Plain text and file system are the computing foundation. The largest > and best set of tools apply. Departing from them loses much. I know in computing we say "database" for those more sophisticated databases. By definition from Wordnet: * Overview of noun database The noun database has 1 sense (no senses from tagged texts) 1. database -- (an organized body of related information) Thus database can be in any form. It need not be special so much special software. It need not be software and digital data at all, it can be paper database. Simple text file can be excellent database for contacts for as long as editor provides search capabilities and there is some kind of organized way of putting data inside. > I do intend to integrate databases into Cyborganize with Dbmind, but > have barely thought about it yet. Cyborganize should run fine without > any database, but of course database is extremely useful for business > etc. Maybe complex database is not needed. As I said there are various approaches and it can be all simple. A database can be also simple LISP data structure, it could be list of hashes securely saved on the file system with possibility to add, modify, delete records. Multiple databases can be made this way for multiple subjects, let us say PEOPLE, GROUPS, LISTS, etc. Then underlying file system can follow the defined structure. > I just don't think paths need to be input into the database. The > strength of the database is freedom from the file system. It should > focus on the things a file system can't do. For example, querying all > the people who work at X company, or who live in Y country. File system can be used for the same: - symlink `People/Joe Doe` to Countries/USA/FL/Miami - symlink `People/Joe Doe` to Groups/Emacs Users/ - symlink `People/Joe Doe` to Companies/USA/PROGRAMMING INC/ To find the information: locate -A "Joe Doe" PROGRAMMING or locate -A "Joe Doe" Miami or just locate FL/Miami By symlinking into various attributes you can get selections easily. > Duplicate Org IDs aren't a problem in my experience. Noticing their > existence is a good way to reconcile the split after the dust of > execution has settled. An Org workflow shouldn't generate lots of > duplicate links. It should not but it does. Projects are repeatable sometimes. Need not be single person projects. Project that I do may have unique IDs and I have to assign same project to ABC number of people. Then I copy the subtree into the file of that person. Unique IDs are also copied. Of course it is manageable if I create some functions to delete and regenerate unique IDs. What is handy with unique IDs is that emails and threads with tasks assigned by email, containing the unique ID, can easily be located. > One that does probably indicates overuse of both links and heading > duplication. If one really does need lots of unique IDs, it's > probably a sign to move to a heavier database than Org. > > I'll fix that link. The correct URL is > https://github.com/cyberthal/Textmind-template I have cloned it and I see it is something familiar to you, not that I can understand your mind flow. In general I find any such system of organization useful for people to learn from, to adopt it or develop their way of thinking and managing files.