Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
> Because not everything is a node property.
This shouldn't prevent us from keeping things that /are/ node properties
all in one place.
> TODO keywords, tags and properties are all different, and blurring the
> distinction between them would not make Org easier. Note that Org
> doesn't force you to use any of them.
I would most definitely make Org easier in some respects. Suppose a
person wants to parse an Org file's content, just for displaying it on a
website (like Github does right now). If all properties were in a single
place, they could be trivially skipped with a regex, resulting in an
almost ASCII-like export of the Org file.
> CLOCK cannot be located within PROPERTIES drawer because it not
> a key-value association. You can have multiple clocks with different
> values.
:LOGBOOK: could be the key, and all of its contents would be the value.
Same thing with putting :TAGS: into :PROPERTIES:.
> SCHEDULED and DEADLINE could have been moved within PROPERTIES drawer.
> It was even discussed a couple of times on this ML. However, Carsten
> decided to keep them separated, mainly because such an important
> information should not be hidden in the document, in particular for
> newcomers. I still agree with him.
Could we have an option to customize this? Just declare a standard
getter and setter interface for :SCHEDULED: and :DEADLINE:. I'll
customize them in my config to put them in the :PROPERTIES: drawer.
Here's another idea for the :PROPERTIES: drawer that might make things a
lot less hairy - make it fully in Lisp:
(properties
(scheduled [2016-02-25 Thu])
(id ca23d969-d189-4d38-aee3-aa21feb5b305)
(logbook
(clock [2016-02-25 Thu 15:03])
(clock [2016-02-25 Thu 14:33] [2016-02-25 Thu 14:58])
(clock [2016-02-25 Thu 13:24] [2016-02-25 Thu 13:49]))
(added [2016-02-25 Thu 11:24]))
I think it would greatly enhance the parsing of Org files, and simplify
many functions in org.el. With this, a simple `read' will suffice to
parse all the stuff.
