Re: Is Org really so simple?

[Tom Gillespie <tgbugs@gmail.com>]

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.