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 IH49M9lLu18NJwAA0tVLHw (envelope-from ) for ; Mon, 23 Nov 2020 05:42:49 +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 yPX+LtlLu1+ZRAAAbx9fmQ (envelope-from ) for ; Mon, 23 Nov 2020 05:42:49 +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 C5FC99402B0 for ; Mon, 23 Nov 2020 05:42:48 +0000 (UTC) Received: from localhost ([::1]:41252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kh4cg-00064y-0O for larch@yhetil.org; Mon, 23 Nov 2020 00:42:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42718) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kh4bu-00064m-D6 for emacs-orgmode@gnu.org; Mon, 23 Nov 2020 00:41:58 -0500 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:45809) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kh4bs-0004nM-L4 for emacs-orgmode@gnu.org; Mon, 23 Nov 2020 00:41:58 -0500 Received: by mail-pf1-x430.google.com with SMTP id b63so13837071pfg.12 for ; Sun, 22 Nov 2020 21:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=mgrjET5zgvPc4RvKr5G41gRBHUStWDbOuNKgBZym9pI=; b=ijnhzHE0VA+5uNp3zzDDkCkuK+LeMtZijZQ1KSchsUxKskOI90nlswf7vMyhYccFPQ hHwcVQM040iBTQocQVwOoBngs5L3m4wKPYPRuB3o8VEbLgannkst9+DnnS6UZaZhw/EG tCHwFNiTj75LOq2zT5sDlG6DRaSAFZMvIEcK2ZzFkgheuIgxYEQjQPZ+LGmLDqHqDvOi AGkmGvYwXbaeAOhl2MO2dEvFFjwgAq0rolL9R0N3shQ6xaDPh6SnFJDg3KqOmfSJV4vi oBCzkbA87qjHuWuQ85AHnUaD4fLMdj1NHcvFepbTJRY/1NzlWcY3AA81RMVnj/kJmbyK 0Saw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=mgrjET5zgvPc4RvKr5G41gRBHUStWDbOuNKgBZym9pI=; b=P4EVNtQ6okmUCGaP7RQ4gbLS7LqGJSuwOM+0H5igcOGCBh83IPv27zYZnhfGyodyOz 5gR+KvGRM5U8DuBaBEgQwpaHtLS6eb7MgDL0U8GzurJNAOL2cZ3rkgSlY/GbRhersbjP 1G0QpNyQHwNwJdeiO+TVbVZYl9DqJ5oVgPJEdZi7lnJHBb64umX5yDfLNOJMgO14YR84 6iBXrL2n08deMTJ3GUJl53VEbk0pJVaLiR4zmZAghPz8wrZir0iVfqyEaY/nQcR0G35j LB/QN9Z67Pg+Y7uEbxaDaSrYuXep36c4fpWhgwZTA5lrTz8SE0DnIvMJFeSuicp2ifHJ Fmlw== X-Gm-Message-State: AOAM531EhCN9wXPR1dNUWfH7Lra5FkNOSO3n0yg5YAlV7doPeeoo9cn1 j2UvAQM+0UuPmjB0GY5Aw4DbYvn7GY9btw== X-Google-Smtp-Source: ABdhPJwEGtfevhZAAHewD+jOuwDsoNOc6mTyw6EXbCUFcHk2ZvcHIBKtbbSOcshoImdsouhd2cPg1w== X-Received: by 2002:a63:1822:: with SMTP id y34mr26375504pgl.218.1606110114753; Sun, 22 Nov 2020 21:41:54 -0800 (PST) Received: from localhost ([104.151.51.115]) by smtp.gmail.com with ESMTPSA id mv16sm12813966pjb.36.2020.11.22.21.41.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 Nov 2020 21:41:53 -0800 (PST) From: Ihor Radchenko To: Texas Cyberthal Subject: Re: One vs many directories In-Reply-To: References: Date: Mon, 23 Nov 2020 13:40:46 +0800 Message-ID: <87mtz84om9.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::430; envelope-from=yantar92@gmail.com; helo=mail-pf1-x430.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, 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-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=ijnhzHE0; 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-Spam-Score: -1.21 X-TUID: wCJwlPoGW57j >> 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. > > By philosophy, I mean the dev consensus on the correct way to do > things, and coded configuration and usability biases. I believe that org support all possibilities. The user can decide to keep many (possibly nested) org files, a few large org files, or anywhere in between. There are several parallel feature sets allowing to work in a single file as well as with a bunch of smaller files. For a single file, the user can search headings with org-goto (without a need to explicitly travel through all the nesting headline levels), reveal only headings satisfying certain keyword/tag/any other search criteria with org-sparse-tree, or built agenda views restricted to a single file (or even subtree). For multiple files located anywhere in the filesystem, there is always org-refile capable of filing the information to proper place or searching deeply nested headlines with ease regardless of the file the information is physically located in. Headlines from multiple files can be grouped using agenda views for any given search criteria (showing todo items or items for a single day/week is just a tiny subset of what agenda can do). Best, Ihor Texas Cyberthal writes: > ***** 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. > > By philosophy, I mean the dev consensus on the correct way to do > things, and coded configuration and usability biases. > > I know this is Org's philosophy because I violated it thoroughly when > writing Treefactor documentation, and was told as much. I can see how > it wouldn't be obvious to casual users. > > Good idea, I'll comment on Voit's article, thanks. > > ***** Hi Palak Mathur, > >> 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. > > I didn't anticipate this problem. Maybe practicing with Treefactor > and Dired would build this muscle over time. > > 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. > > ***** Hi Jean Louis, > > 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. > > 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. > >> I can find a mining engineer in country Senegal if I wish so, that has some work experience and I can see files pertaining to this person. But not that I would make file system directory Senegal to find the files for this person > > Of course not. You would find a person under his name, not his > country. The person can move to a different country, after all. At > most you might link him to the country, as part of a list of people > from X country. But that is something better handled by a real > database. > > To clarify, Treefactor is just an Emacs package with some minimal > opinions. 10 Bins is an opinionated directory tree template. Neither > requires the other, but they're both part of Cyborganize, my overall > PIM and publishing system.