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 AHfcGgMjvF/OJAAA0tVLHw (envelope-from ) for ; Mon, 23 Nov 2020 21:00:51 +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 6AC1FgMjvF/ebQAA1q6Kng (envelope-from ) for ; Mon, 23 Nov 2020 21:00:51 +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 B644C94028F for ; Mon, 23 Nov 2020 21:00:50 +0000 (UTC) Received: from localhost ([::1]:37236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khIx7-0006zG-Gr for larch@yhetil.org; Mon, 23 Nov 2020 16:00:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khIeS-0005QT-Cz for emacs-orgmode@gnu.org; Mon, 23 Nov 2020 15:41:33 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:39779) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1khIeP-0008Ot-W8 for emacs-orgmode@gnu.org; Mon, 23 Nov 2020 15:41:32 -0500 Received: by mail-wm1-x32d.google.com with SMTP id s13so715387wmh.4 for ; Mon, 23 Nov 2020 12:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sqY2mf/CA/B+Q5Ah+zKWH3Sye/UuyV4bNlUISOKFywk=; b=s4V28kVQr8k4U6i8favqiKXMBmC6RiVoDA8XQC9UtAqh+c48+1d3WeEpQnk1tX+/9e TqnfzH+5vTiyrpOJCcv4JntT1kiKnwqIsee8zaDp8rNBV2plIdf+UiNQg03pr/P/BaB6 dGHc1sZqMWjpKyPgLEBcSbfJtLd09GwAdN0BOM39mVd+IWQ8mQUV6RP4o1dAYBMBw783 7JQfHgJxWHMpHGOS6npw5qYtYaHQmthY5pSNxbP03zFfbIWFj1IIax6Yv1CPQ/yTk3RX Hcor7Xh8DAo7PVX9D7suagB7D8NzBOH9jD1H/qUfVfUR/VdP7upzt49L8lpfayW3VjTs NF/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sqY2mf/CA/B+Q5Ah+zKWH3Sye/UuyV4bNlUISOKFywk=; b=VeJFa3ctbJ+I891aXbmK+nvGBto0Ftg8utG1oxgtwd81+o19XCnnkjSr87mmNeAIv/ tjLNtKTV6UUt3kyQG1ui7VsmLxMpzH2nNzvpkqvPLysuShSCS0vDrBRbTBctUpHmCmqJ HNutlwDm0+ry2J4NtFZn8EhBbOam6Q8AGW1RuUUus9VQxbNOEj0UnzggrGX19z9I/1gV QmuidqMmLHlCSxmFbEqgqPMP3BleI8vpjXJtD/pGtGdXfNthKWxBTTX/I0Fi4pCxxEnl EGhBeaHdsTl9nee4U72IvMHD1Wo2eIqRKFZtsgjaJ7gb9zink1rHMufD+NxSFBEBMvke o6RQ== X-Gm-Message-State: AOAM531lirLMef+K9ruicwBUCaXaNUOOl/mltWFt8eoFHXr5NCIezF6V G9TFTj34Czbq4ATuknPR4eFx3XOOGN5dQK8ncjo= X-Google-Smtp-Source: ABdhPJxfYbR6L+h73gp8wuUNg6ATwcbn1TsB3uO5ouaHriNnuLoFbtzp1cRFymcZQSgosoXMFiui+OUyLWhhJ22O2iU= X-Received: by 2002:a1c:98cd:: with SMTP id a196mr753761wme.42.1606164087729; Mon, 23 Nov 2020 12:41:27 -0800 (PST) MIME-Version: 1.0 References: <87y2ive1i4.fsf@localhost> <878sauhhv1.fsf@web.de> <875z5ygwwr.fsf@web.de> <87r1olfvh4.fsf@web.de> <878sascg5j.fsf@localhost> In-Reply-To: From: Tom Gillespie Date: Mon, 23 Nov 2020 15:41:14 -0500 Message-ID: Subject: Re: Is Org really so simple? To: Jean Louis Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=tgbugs@gmail.com; helo=mail-wm1-x32d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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: "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=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=s4V28kVQ; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 2.59 X-TUID: DtKLvMOkw9z5 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). Despite this, in a sense, Org is just as simple as it has always been 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. 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. For some use cases there are performance issues and for others workflow issues. The performance issues are likely to be resolved via more developer time. The workflow issues have to be resolved by writing custom elisp code, in many times that elisp gets packaged as org extensions. Thus we arrive back at your original complaint, which is that Org files are not sufficiently self-contained. In order to make them self-contained you currently have to copy and paste a bunch of boilerplate into files (thus the workflow issues). For some things the boilerplate is seemingly unavoidable, even using #+setupfile: doesn't work if you are trying to solve a problem in a certain way in Org. Other times, you could solve the same problem without any boilerplate using a slightly different approach, but not always. 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? You could embed it later if it fits your use case, or you could embed the org file in the data!). I came at the problem from the perspective of reproducible research, but it seems like there are many use cases for being able to move information implicit in the environment into an Org file explicitly. 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!" For the described frustration with needing to track users, give the org-file an embedded id and use that to access and update the assignees associated with a file. There is no need to choose Org or something else, you can have your comfortable org-mode workflow, and your data-appropriate store.