From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Oleh Krehel <ohwoeowho@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Is it possible to keep /all/ the heading properties in one place?
Date: Thu, 25 Feb 2016 17:52:37 +0100 [thread overview]
Message-ID: <87h9gw20mi.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87oab4sw70.fsf@gmail.com> (Oleh Krehel's message of "Thu, 25 Feb 2016 15:26:11 +0100")
Oleh Krehel <ohwoeowho@gmail.com> writes:
> 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.
(Parsing - regexp - trivially: pick only two)
There already is a parser, and a syntax definition.
>> 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:.
Contents of :LOGBOOK: can be almost anything. You need a parser
understanding the whole Org syntax to parse it. I don't see how it would
make anything easier. Also, you cannot parse Org syntax only using
regexps.
>> 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.
I'm against making syntax customizable. I'd rather have a clear
definition of a single syntax anyone could implement.
However, I agree we could allow to customize how meta-data is
/displayed/. Since planning lines and properties drawers are required to
be next to each other, it is easy to make them disappear under the same
overlay. See, for example, `org-end-of-meta-data'.
> 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.
I do not feel like asking users to write directly the AST for their
plain text documents, really. Parsing an Org document is a solved
problem. I do not pretend the solution cannot be improved, but at least,
it is complete.
I'm not sure about your motivations. If they are about reducing visual
clutter, you can work it out at the display level. I'm pretty sure this
improvement would be appreciated.
OTOH, if they are about making it easier to implement external parsers,
I think you should try first to implement the current syntax. It is
quite documented and not really hard to grok.
Regards,
--
Nicolas
next prev parent reply other threads:[~2016-02-25 16:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 10:59 Is it possible to keep /all/ the heading properties in one place? Oleh Krehel
2016-02-25 13:37 ` Nicolas Goaziou
2016-02-25 13:46 ` Oleh Krehel
2016-02-25 14:03 ` Nicolas Goaziou
2016-02-25 14:26 ` Oleh Krehel
2016-02-25 16:52 ` Nicolas Goaziou [this message]
2016-02-25 18:21 ` Eric S Fraga
2016-02-26 16:35 ` Rasmus
2016-02-28 9:35 ` Eric S Fraga
2016-02-28 11:32 ` Rasmus
2016-02-28 12:44 ` Eric S Fraga
2016-02-28 16:46 ` Rasmus
2016-02-28 17:05 ` Eric S Fraga
2016-02-25 19:17 ` Oleh Krehel
2016-02-25 20:16 ` Nicolas Goaziou
2016-02-26 8:18 ` Oleh Krehel
2016-02-28 8:59 ` Nicolas Goaziou
2016-02-28 12:17 ` Oleh Krehel
2016-02-28 16:34 ` Thomas S. Dye
2016-02-29 10:05 ` Nicolas Goaziou
2016-02-29 13:42 ` Thomas S. Dye
2016-02-29 15:00 ` Nicolas Goaziou
2016-02-29 13:53 ` Marcin Borkowski
2016-02-29 15:05 ` Nicolas Goaziou
2016-02-29 17:57 ` Revisiting moving manual to Org (was: Is it possible to keep /all/ the heading properties in one place?) Kyle Meyer
2016-02-29 17:17 ` Is it possible to keep /all/ the heading properties in one place? Achim Gratz
2016-02-29 18:01 ` Thomas S. Dye
2016-02-29 18:47 ` Nicolas Goaziou
2016-02-25 17:47 ` Michael Brand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h9gw20mi.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=ohwoeowho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).