emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Is it possible to keep /all/ the heading properties in one place


From: Oleh Krehel
Subject: Re: [O] Is it possible to keep /all/ the heading properties in one place?
Date: Thu, 25 Feb 2016 15:26:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Nicolas Goaziou <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]