From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SN6pByCVvF/xegAA0tVLHw (envelope-from ) for ; Tue, 24 Nov 2020 05:07: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 mp0 with LMTPS id oIuAAyCVvF/vPQAA1q6Kng (envelope-from ) for ; Tue, 24 Nov 2020 05:07:44 +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 9474A9404E5 for ; Tue, 24 Nov 2020 05:07:41 +0000 (UTC) Received: from localhost ([::1]:41346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khQYE-0000Ra-UU for larch@yhetil.org; Tue, 24 Nov 2020 00:07:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42902) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khQXQ-0000RK-F3 for emacs-orgmode@gnu.org; Tue, 24 Nov 2020 00:06:49 -0500 Received: from static.rcdrun.com ([95.85.24.50]:59317) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khQXM-0006Jo-9R for emacs-orgmode@gnu.org; Tue, 24 Nov 2020 00:06:48 -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 00000000002C1AE6.000000005FBC94E2.00004C4F; Tue, 24 Nov 2020 05:06:41 +0000 Date: Tue, 24 Nov 2020 08:06:32 +0300 From: Jean Louis To: Tom Gillespie Subject: Re: Is Org really so simple? Message-ID: References: <878sauhhv1.fsf@web.de> <875z5ygwwr.fsf@web.de> <87r1olfvh4.fsf@web.de> <878sascg5j.fsf@localhost> 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: "Dr. Arne Babenhauserheide" , Texas Cyberthal , "emacs-orgmode@gnu.org" , Ihor Radchenko 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: 1.99 X-TUID: iXj4EedZUOpi * Tom Gillespie [2020-11-23 23:41]: > I have read many perspectives like this of late on this mailing list. > In summary I think that Org is such an incredibly flexible and > powerful tool that many users have not the faintest idea what other > users are doing with it (for example I am completely mystified by the > level of activity in the one vs many files thread and its counterpart > on the orgmode subreddit). I have many files but I do not hyperlink them as they are in the other sense self-contained. This is due to my individual use case. I simply do not know why should I hyperlink from one file to other as subjects of the files are so much separate. My way of handling things is to designate a project with TODOs, but I do not have TODOs in many various files so those agenda adding functions are rather disturbing me then helping as those are few seconds of delay for nothing. My TODO things are in separate files and they are many times not really "My TODO". They are rather TODO for people to which I assign tasks, and send such. Those people do not need to write Org files, they get it by email and execute in the real world, then they report back. When searching for tasks I do not use agenda, I use people from where I quickly enter the Org file related to that person without knowing where it is located, there are many Org files like that. That is how I do not encounter problems others do encounter. One bulk of 173 Org files in one single directory I do not search with Agenda rather with grep as those are simply not TODO/Action related. There are just 2-3 files that have TODO/Action related stuff and they are on key bindings. I am in transition to stop with Org tracking my TODO actions and just use it for the written instructions, prose and project management which is then printed on the paper and assigned to people. While my TODO notes I will simply keep in the database as it gives me better access and tracking. Just recently I have implemented dumb version control or backup for database entries so that entry is first saved before editing for later comparison or revisions. If I am to use RCS or other revision control system on user's Org files, this would mean I would need to invoke the version control in hundreds of directories and use all the keybindings, etc. With the program backed version control when editing Org file from database, it is automatically saved in the `vc' table without me thinking anything about it. If there is any version control, users should not think about it. It should be a built-in feature. > Despite this, in a sense, Org is just as simple as it has always > been On that I am not convinced at all. 129 Emacs .el files are in the Org distribution here and that I do not call simple. Maybe outline-mode is simple on which org is built upon. > which is why people build on top of it, and thus there isn't really > any way to "go back" to a simpler time -- such a time is fictional, > it has never existed. Right. > I can say for myself that it is not Org that has changed, it is how > I use it. I used to use it in simple ways, and still can if I want, > but now I use it as a substrate for self describing (sometimes > self-modifying) interactive programs -- as complex as you can get. I will look into that package to see if it has good ideas for HyperScope dynamic knowledge repository that I am working on, something like meta Org. > For some use cases there are performance issues and for others > workflow issues. I have no workflow issues and performance only when Org updates its stuff which I do not need. I would like to see some more automated link construction functions and recognitions of other modes. For example when browsing gopher:// or gemini:// pages with M-x elpher that I can quickly construct hyperlinks and insert somewhere. Org has such functions to read email and obtain hyperlink, to use eww and obtain hyperlink and similar. It just needs more and more. Hyperlinking is what I need but I need it in more textual and peculiar non-common way. I would rather like to have simple text files formatted any how so that file can be readable and sent to other people while meta information and hyperlinks can be defined in separate file or other pieces of information. GNU Hyperbole offers similar system where buttons and hyperlink information is defined in separate files. I can include GNU Hyperbole hyperlinks in any file and they will not look so complex as Org files. This link looks complicated if not in Org mode: [[https://www.example.com/something/more/here][Fetch software]] This link can be in any mode and looks simpler: <(Fetch software)> but in that case hyperlinks are defined elsewhere, not in same file. > Thus we arrive back at your original complaint, which is that Org > files are not sufficiently self-contained. No complaint, just my viewpoint. I do not mind of principles, philosophy, etc. I do not need Org files to be sufficiently self-contained. I have some preferences but for Org I do not mind and accept it as such. As said, I would prefer having text files which can be upgraded with meta file to show all the hyperlinks. That is what I am using now in HyperScope. > In order to make them self-contained you currently have to copy and > paste a bunch of boilerplate into files (thus the workflow > issues). Yes and no. I think that what you explained is not something to think of. That is why when I create a person, like Karl, I can locate person in the database and press F4 and Org file is created specifically for that person with all details inside, like title, author, assignmets, few basic headings such as Tasks and Transactions including the table of transactions. If I am thinking of groups of people, there is artist group and staff member group, so there could be templates for artist group and staff members, and by simply clicking on one single key the Org file is created on the fly for that specific person without me knowing where the file is located or putting any hand written templates. It is just there, already saved and opened and I do not even need to save it. Click and go. > I have been working on an extension for Org (orgstrap > https://github.com/tgbugs/orgstrap ) with the goal of making Org files > self-describing, if not fully self-contained (There is a distinction > between the two, but only for certain failure modes. Also, why force > __DATA__ to be embedded with the file when everything has to be > dereferenced at some point anyway? I have just given idea that meta data like properties and anything else could be defined in separate section of same file which in turn could export itself to full Org or something else. Separate section of Org file or separate meta data file could provide hyperlinks for specific keywords without those being hyperlinsk in the original file. Switching between Org type view and meta Org type view could be easy. The idea is there just for thinking, I will definitely not work on such as I work different > You could embed it later if it fits your use case, or you could > embed the org file in the data!). In that sense I have database columns that hold Org data, not files. I edit such just as usual, it is just not on the file system and it does not need to be Org file, it can be just any type of a file that Emacs support and any type of a mode. That way I am getting meta level hierarchy of hyperdocuments that can be just anything. > If you want a database to handle relational data, great, describe > what you need to access it in the org file that will act as the > interface to that relational data, that way if the database access > is down you won't get cryptic errors, but a big warning that says > "hey! a service required to use functionality in this file correctly > is missing!" I would not like creating too many things by hand, that is why computer has to take those tasks from me. So I am working other way around like adding records to the database and then viewing stuff with the Org. Database is exported to Org buffer, not file, but could be saved as file and then all relational elements and hyperlinks can be already there automatically. If person Karl received email ABC, that ABC can be hyperlink to the email, I can see all SMS, previous email conversation and so on and that works by clicking on the automatically generated hyperlinks. It would be pain in the ass that information that is already available to be collected by computer I have to collect with my efforts. Thus any pieces of information that already exists should be converted on the fly to hyperlinks to hyperdocuments without user having to construct it by hand. Hand work is for those files where one wish to create references for the first time. But if any referencable objects already exists and are related to any other objects than Org files can be created on the fly to inspect such relations.