emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Thorsten Jolitz <tjolitz@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PARSER] Why not add properties to type 'org-data'?
Date: Thu, 05 Sep 2013 21:14:56 +0200	[thread overview]
Message-ID: <87zjrrytan.fsf@gmail.com> (raw)
In-Reply-To: <87y57be0zv.fsf@gmail.com> (Thorsten Jolitz's message of "Thu, 05 Sep 2013 17:34:12 +0200")

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Wouldn't it make sense to replace 
>
> ,----------------------------------------------
> | (org-data nil (section (:begin 1 :end 52 ...)))
> `----------------------------------------------
>
> with something like
>
> ,-------------------------------------------------------------------------
> | (org-data (:id-or-name file001 :input-file /my/file.org :author me :date
> | 01-01-2013 :description my planning data) (section (:begin 1 :end 52
> | ...)))
> `-------------------------------------------------------------------------
>
> ?

This is way beyond parser's attributions. For example, getting the right
date means that every SETUPFILE keyword should be inspected. INCLUDE
keywords too. And some macros could get expanded in the process.

Also keep in mind that some keywords, e.g. DESCRIPTION, are defined and
made special at the export framework level (see
`org-export-options-alist'). There are just regular keywords to the
parser. IOW, for the parser, there is no difference between

  #+DESRCIPTION: something

and

  #+FOO: something

At one point, I thought about combining parse tree and information
channel, much like what you're suggesting, but in `ox.el'. It would give
something like an "Org closure" wrapping both contents and environment
together.

But I discarded that idea, as it was very artificial: the minute the
closure was created, it was splitted again so it could get processed.


Regards,

-- 
Nicolas Goaziou

  reply	other threads:[~2013-09-05 19:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 15:34 [PARSER] Why not add properties to type 'org-data'? Thorsten Jolitz
2013-09-05 19:14 ` Nicolas Goaziou [this message]
2013-09-05 21:24   ` Thorsten Jolitz
2013-09-07  7:15     ` Nicolas Goaziou
2013-09-07  9:28       ` Thorsten Jolitz

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=87zjrrytan.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=tjolitz@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).