From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kaushal Modi Subject: Re: Parsing property drawers in subtree scope exports Date: Thu, 06 Jul 2017 17:08:32 +0000 Message-ID: References: <87y3s84mxp.fsf@nicolasgoaziou.fr> <87injc2l95.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114b18503813390553a92b71" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47563) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dTAGm-0007nx-6G for emacs-orgmode@gnu.org; Thu, 06 Jul 2017 13:08:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dTAGk-00048Q-RF for emacs-orgmode@gnu.org; Thu, 06 Jul 2017 13:08:48 -0400 Received: from mail-lf0-x231.google.com ([2a00:1450:4010:c07::231]:36500) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dTAGk-00045V-9j for emacs-orgmode@gnu.org; Thu, 06 Jul 2017 13:08:46 -0400 Received: by mail-lf0-x231.google.com with SMTP id h22so8149214lfk.3 for ; Thu, 06 Jul 2017 10:08:44 -0700 (PDT) In-Reply-To: <87injc2l95.fsf@nicolasgoaziou.fr> 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" To: Nicolas Goaziou Cc: emacs-org list --001a114b18503813390553a92b71 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 1, 2017 at 12:08 PM Nicolas Goaziou wrote: > Kaushal Modi writes: > > > I didn't follow that. Do you mean that the "EXPORT_" is a special > > prefix? > > I do. See (info "(org) Export settings"). > Thanks! Sorry for not reading that earlier. For reference: > When exporting sub-trees, special node properties in them can override the above keywords. They are special because they have an =E2=80=98EXPORT_= =E2=80=99 prefix. For example, =E2=80=98DATE=E2=80=99 and =E2=80=98OPTIONS=E2=80=99 keywords = become, respectively, =E2=80=98EXPORT_DATE=E2=80=99 and =E2=80=98EXPORT_OPTIONS=E2=80=99. Except = for =E2=80=98SETUPFILE=E2=80=99, all other keywords listed above have an =E2=80=98EXPORT_=E2=80=99 equivalent. > > Should that be added to these? > > > > =3D=3D=3D=3D=3D > > :options-alist '((:hugo-front-matter-format "HUGO_FRONT_MATTER_FORMAT" > nil > > org-hugo-front-matter-format) > > (:hugo-tags "HUGO_TAGS" nil nil) > > =3D=3D=3D=3D=3D > > If you set this, you can access to EXPORT_HUgo_TAGS property > with :hugo-tags. > Thanks. That works. Just curious though.. if one specifies certain keywords to be exporter specific keywords in the backend definition in :options-alist, it is evident that those keywords are specifically for export. Should the requirement to have "EXPORT_" prefix before them be relaxed? Do you foresee things not happening right if we started doing that= ? > > I already tried above, but I don't know how to get the ":HUGO_TAGS" val= ue > > from the property drawer, in subtreep export only, in the body filter > (with > > only body and info available). > > (plist-get info :hugo-tags) > I was already doing that, but I was missing the "EXPORT_" prefix in the property drawer keys. Thanks! > > Otherwise, you simply need to retrieve it and store it before calling > >> `org-export-to-file' or whatever. > > > > > > Hmm, will give this a try.. may be look at the pre export hook? > > You can also do that, if you don't use the "EXPORT_" prefix above. > Using "EXPORT_" prefix works, but then the keys become too wordy; example: EXPORT_HUGO_CATEGORIES. So I have two options: - Make use of the inbuilt EXPORT_ prefix and get rid of the "HUGO_" prefix from the exporter backend definition. Then if categories are specified per-Org-file, it would look like "#+CATEGORIES: foo bar", and if they are specified per subtree, it would look like ":EXPORT_CATEGORIES: foo bar" in the property drawer. - Do not use the "EXPORT_" keyword in the property drawers, but then either do the pre-export parsing, or.. above suggestion to update Org ox to not require "EXPORT_" before FOO if FOO is a special keyword defined in the backend? > However, you need to expand the buffer first, because it will be > narrowed to the current subtree. I need exactly that. My idea is to have a single Org file with one subtree per a blog post. So each subtree will have meta data about that post, like data, categories, etc. --=20 Kaushal Modi --001a114b18503813390553a92b71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 1,= 2017 at 12:08 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
Kaushal Modi <kaushal.modi@gmail.com> writes:

> I didn't follow that. Do you mean that the "EXPORT_" is = a special
> prefix?

I do. See (info "(org) Export settings").
Thanks! Sorry for not reading that earlier. For reference:

>=C2=A0When exporting sub-trees, special node prop= erties in them can override the above keywords. They are special because th= ey have an =E2=80=98EXPORT_=E2=80=99 prefix. For example, =E2=80=98DATE=E2= =80=99 and =E2=80=98OPTIONS=E2=80=99 keywords become, respectively, =E2=80= =98EXPORT_DATE=E2=80=99 and =E2=80=98EXPORT_OPTIONS=E2=80=99. Except for = =E2=80=98SETUPFILE=E2=80=99, all other keywords listed above have an =E2=80= =98EXPORT_=E2=80=99 equivalent.=C2=A0
=C2=A0
> Should that be added to these?
>
> =3D=3D=3D=3D=3D
> :options-alist '((:hugo-front-matter-format "HUGO_FRONT_MATTE= R_FORMAT" nil
> org-hugo-front-matter-format)
> (:hugo-tags "HUGO_TAGS" nil nil)
> =3D=3D=3D=3D=3D

If you set this, you can access to EXPORT_HUgo_TAGS property
with :hugo-tags.

Thanks. That works. Ju= st curious though.. if one specifies certain keywords to be exporter specif= ic keywords in the backend definition in :options-alist, it is evident that= those keywords are specifically for export. Should the requirement to have= "EXPORT_" prefix before them be relaxed? Do you foresee things n= ot happening right if we started doing that?
=C2=A0
> I already tried above, but I don't know how= to get the ":HUGO_TAGS" value
> from the property drawer, in subtreep export only, in the body filter = (with
> only body and info available).

(plist-get info :hugo-tags)

I was alrea= dy doing that, but I was missing the "EXPORT_" prefix in the prop= erty drawer keys. Thanks!
=C2=A0
> Otherwise, you simply need to retrieve it and store it before call= ing
>> `org-export-to-file' or whatever.
>
>
> Hmm, will give this a try.. may be look at the pre export hook?

You can also do that, if you don't use the "EXPORT_" prefix a= bove.

Using "EXPORT_" prefix = works, but then the keys become too wordy; example: EXPORT_HUGO_CATEGORIES.=

So I have two options:

-= Make use of the inbuilt EXPORT_ prefix and get rid of the "HUGO_"= ; prefix from the exporter backend definition. Then if categories are speci= fied per-Org-file, it would look like "#+CATEGORIES: foo bar", an= d if they are specified per subtree, it would look like ":EXPORT_CATEG= ORIES: foo bar" in the property drawer.
- Do not use the &qu= ot;EXPORT_" keyword in the property drawers, but then either do the pr= e-export parsing, or.. above suggestion to update Org ox to not require &qu= ot;EXPORT_" before FOO if FOO is a special keyword defined in the back= end?
=C2=A0
However, you need to expand the buffer first, because it will be
narrowed to the current subtree.
=C2=A0
I need e= xactly that. My idea is to have a single Org file with one subtree per a bl= og post. So each subtree will have meta data about that post, like data, ca= tegories, etc.
--

Kaushal Modi

--001a114b18503813390553a92b71--