Re: Is Org really so simple?

[Jean Louis]

* Tom Gillespie <tgbugs@gmail.com> [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.