From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Is it possible to keep /all/ the heading properties in one place? Date: Thu, 25 Feb 2016 17:52:37 +0100 Message-ID: <87h9gw20mi.fsf@nicolasgoaziou.fr> References: <87fuwht5s3.fsf@gmail.com> <87lh683o7c.fsf@nicolasgoaziou.fr> <878u28ucl8.fsf@gmail.com> <878u283n15.fsf@nicolasgoaziou.fr> <87oab4sw70.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYz7f-0002Q8-4d for emacs-orgmode@gnu.org; Thu, 25 Feb 2016 11:50:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYz7b-0003rh-40 for emacs-orgmode@gnu.org; Thu, 25 Feb 2016 11:50:39 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:59583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYz7a-0003rd-TT for emacs-orgmode@gnu.org; Thu, 25 Feb 2016 11:50:35 -0500 In-Reply-To: <87oab4sw70.fsf@gmail.com> (Oleh Krehel's message of "Thu, 25 Feb 2016 15:26:11 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Oleh Krehel Cc: emacs-orgmode@gnu.org Oleh Krehel 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