Re: [O] [Feature Request] Make property-drawers exportable
On 25.9.2013, at 11:31, Carsten Dominik wrote:
> Hi everyone,
>
> I would like to come back to this issue.
>
> While I can follow the argumentation that drawers are meta data and that it
> is really hard for a backend to do something general and correct with them, I
> am still wondering if it wouldn't be good to have some default way to export
> them anyway. I'd be perfectly content to have is such that drawers can be
> exported as an @example block. I also think that the export of drawers
> should definitely be OFF by default.
>
> Having the default backends allow export of drawers as examples opens the
> door to use filters to modify it. This has the advantage that a new backend
> does not have to be defined. I am experimenting right now with defining
> filters with Babel in buffers, and I am finding this a powerful way to tweak
> the export of an individual file.
P.S. of course there is also the possibility that I could use Babel to define
or temporarily modify an export backend on the fly - but I have not figured out
how this might work..
>
> The reason why I am bringing this up is the following:
>
> I am reviving the Org Issues file, see the other thread on the mailing list.
> I would like to be able to export the LOOGBOOK state changes, and these are
> naturally located in a drawer.
>
> The problem here is that the export is happening on worg, in an automatic
> way. So it is not really an easy option to define a new backend that will be
> used for just this file, because publishing on Worg uses org-to-html.
>
> Now, being the person with the keys, I *could*, of course go and define a
> special backend on Worg that does what I want - but I do also understand the
> wish expressed by a couple of people in this thread.
>
> We still have the variable org-export-with-drawers in ox.el. My proposal
> would be to set the default to nil, plain and simple, and use a t value to
> make drawers export as @example. Safe enough, and easy enough.
>
> Regards
>
> - Carsten
>
> On 17.6.2013, at 21:04, Nicolas Goaziou wrote:
>
>> Thorsten Jolitz writes:
>>
>>> Nicolas Goaziou writes:
>>
Property drawers are Org meta data, they are not for user's
cosumption. Though you can export some properties with macros (see
{{{property{NAME macros).
>>>
>>> I don't really agree. Property drawers are for meta data used by
>>> Org-mode too, obviously, but they are perfectly suited for meta-data
>>> about the document, as well as those simple data-base features described
>>> in the manual.
>>
>> It seems I wasn't clear enough. More on this below.
>>
>>> Why deny Org users the full benefit of these other uses for
>>> property-drawers by denying them the possibility to export their
>>> document meta-data or data-bases?
>>
>> I don't deny anyone the right code this:
>>
>> (defun my-latex-property-drawer (drawer contents info)
>> (concat "\\begin{example}\n"
>> (org-element-interpret-data drawer)
>> "\\end{example}"))
>>
>> (org-export-define-derived-backend 'my-latex 'latex
>> :translate-alist '((property-drawer . my-latex-property-drawer)))
>>
>> [...]
>>
>>> And whats wrong with a simple CD collection database implemented with
>>> property-drawers, as described in the manual? Why shouldn't people be
>>> allowed to export their CD database to some text-formatting backend?
>>
>> Database example is interesting. My point is that you will never want to
>> dump the whole database in your exported document because Org may fill
>> it with its own meta-data, making the output look like garbage. Also,
>> some backends (ox-icalendar, at least) create properties during export,
>> so you would even get new properties in your output.
>>
>> It's perfectly fine to export the part of a database you're interested
>> in, like your whole CD collection, but it requires to filter out Org
>> meta-data, and to properly format your own properties. This depends so
>> much on the contents of your database that it is impossible to provide
>> good defaults for it.
>>
>> Therefore, default export doesn't even try. Instead, tools are provided
>> to access values from your own database (again, macro
>> {{{property(...)}}}) so they can be exported. If you have special needs
>> for your database, just code them and plug them in.
>>
>> You have a choice.
>>
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [O] [Feature Request] Make property-drawers exportable
Hi everyone,
I would like to come back to this issue.
While I can follow the argumentation that drawers are meta data and that it is
really hard for a backend to do something general and correct with them, I am
still wondering if it wouldn't be good to have some default way to export them
anyway. I'd be perfectly content to have is such that drawers can be exported
as an @example block. I also think that the export of drawers should
definitely be OFF by default.
Having the default backends allow export of drawers as examples opens the door
to use filters to modify it. This has the advantage that a new backend does
not have to be defined. I am experimenting right now with defining filters
with Babel in buffers, and I am finding this a powerful way to tweak the export
of an individual file.
The reason why I am bringing this up is the following:
I am reviving the Org Issues file, see the other thread on the mailing list. I
would like to be able to export the LOOGBOOK state changes, and these are
naturally located in a drawer.
The problem here is that the export is happening on worg, in an automatic way.
So it is not really an easy option to define a new backend that will be used
for just this file, because publishing on Worg uses org-to-html.
Now, being the person with the keys, I *could*, of course go and define a
special backend on Worg that does what I want - but I do also understand the
wish expressed by a couple of people in this thread.
We still have the variable org-export-with-drawers in ox.el. My proposal would
be to set the default to nil, plain and simple, and use a t value to make
drawers export as @example. Safe enough, and easy enough.
Regards
- Carsten
On 17.6.2013, at 21:04, Nicolas Goaziou wrote:
> Thorsten Jolitz writes:
>
>> Nicolas Goaziou writes:
>
>>> Property drawers are Org meta data, they are not for user's
>>> cosumption. Though you can export some properties with macros (see
>>> {{{property{NAME macros).
>>
>> I don't really agree. Property drawers are for meta data used by
>> Org-mode too, obviously, but they are perfectly suited for meta-data
>> about the document, as well as those simple data-base features described
>> in the manual.
>
> It seems I wasn't clear enough. More on this below.
>
>> Why deny Org users the full benefit of these other uses for
>> property-drawers by denying them the possibility to export their
>> document meta-data or data-bases?
>
> I don't deny anyone the right code this:
>
> (defun my-latex-property-drawer (drawer contents info)
>(concat "\\begin{example}\n"
>(org-element-interpret-data drawer)
>"\\end{example}"))
>
> (org-export-define-derived-backend 'my-latex 'latex
>:translate-alist '((property-drawer . my-latex-property-drawer)))
>
> [...]
>
>> And whats wrong with a simple CD collection database implemented with
>> property-drawers, as described in the manual? Why shouldn't people be
>> allowed to export their CD database to some text-formatting backend?
>
> Database example is interesting. My point is that you will never want to
> dump the whole database in your exported document because Org may fill
> it with its own meta-data, making the output look like garbage. Also,
> some backends (ox-icalendar, at least) create properties during export,
> so you would even get new properties in your output.
>
> It's perfectly fine to export the part of a database you're interested
> in, like your whole CD collection, but it requires to filter out Org
> meta-data, and to properly format your own properties. This depends so
> much on the contents of your database that it is impossible to provide
> good defaults for it.
>
> Therefore, default export doesn't even try. Instead, tools are provided
> to access values from your own database (again, macro
> {{{property(...)}}}) so they can be exported. If you have special needs
> for your database, just code them and plug them in.
>
> You have a choice.
>
>
> Regards,
>
> --
> Nicolas Goaziou
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [O] [Feature Request] Make property-drawers exportable
Nicolas Goaziou writes:
> Thorsten Jolitz writes:
>
>> Nicolas Goaziou writes:
>
>>> Property drawers are Org meta data, they are not for user's
>>> cosumption. Though you can export some properties with macros (see
>>> {{{property{NAME macros).
>>
>> I don't really agree. Property drawers are for meta data used by
>> Org-mode too, obviously, but they are perfectly suited for meta-data
>> about the document, as well as those simple data-base features described
>> in the manual.
>
> It seems I wasn't clear enough. More on this below.
>
>> Why deny Org users the full benefit of these other uses for
>> property-drawers by denying them the possibility to export their
>> document meta-data or data-bases?
>
> I don't deny anyone the right code this:
>
> (defun my-latex-property-drawer (drawer contents info)
> (concat "\\begin{example}\n"
> (org-element-interpret-data drawer)
> "\\end{example}"))
>
> (org-export-define-derived-backend 'my-latex 'latex
> :translate-alist '((property-drawer . my-latex-property-drawer)))
>
> [...]
I'm sure you don't, but what if I write some library that should be used
by others that can't be assumed to have installed 'my-latex.el'?
Then I can't base that library on the use of property drawers, what I
really would like to do, since its a feature I like very much, and IMO
one of the best supported features in Org-mode both for interactive and
programmatical use.
>> And whats wrong with a simple CD collection database implemented with
>> property-drawers, as described in the manual? Why shouldn't people be
>> allowed to export their CD database to some text-formatting backend?
>
> Database example is interesting. My point is that you will never want to
> dump the whole database in your exported document because Org may fill
> it with its own meta-data, making the output look like garbage. Also,
> some backends (ox-icalendar, at least) create properties during export,
> so you would even get new properties in your output.
may be in the database example, but not in my application example -
there, all meta-info in property drawers is suitable for export, and no
other (Org-specific) meta info is added.
> It's perfectly fine to export the part of a database you're interested
> in, like your whole CD collection, but it requires to filter out Org
> meta-data, and to properly format your own properties. This depends so
> much on the contents of your database that it is impossible to provide
> good defaults for it.
>
> Therefore, default export doesn't even try. Instead, tools are provided
> to access values from your own database (again, macro
> {{{property(...)}}}) so they can be exported. If you have special needs
> for your database, just code them and plug them in.
>
> You have a choice.
Ok, these are arguments that are easily understood. I'll have to take a
second look at those macros, they definitely look ugly, but maybe they
are usefull..
Thanks so far.
--
cheers,
Thorsten
Re: [O] [Feature Request] Make property-drawers exportable
Thorsten Jolitz writes:
> Nicolas Goaziou writes:
>> Property drawers are Org meta data, they are not for user's
>> cosumption. Though you can export some properties with macros (see
>> {{{property{NAME macros).
>
> I don't really agree. Property drawers are for meta data used by
> Org-mode too, obviously, but they are perfectly suited for meta-data
> about the document, as well as those simple data-base features described
> in the manual.
It seems I wasn't clear enough. More on this below.
> Why deny Org users the full benefit of these other uses for
> property-drawers by denying them the possibility to export their
> document meta-data or data-bases?
I don't deny anyone the right code this:
(defun my-latex-property-drawer (drawer contents info)
(concat "\\begin{example}\n"
(org-element-interpret-data drawer)
"\\end{example}"))
(org-export-define-derived-backend 'my-latex 'latex
:translate-alist '((property-drawer . my-latex-property-drawer)))
[...]
> And whats wrong with a simple CD collection database implemented with
> property-drawers, as described in the manual? Why shouldn't people be
> allowed to export their CD database to some text-formatting backend?
Database example is interesting. My point is that you will never want to
dump the whole database in your exported document because Org may fill
it with its own meta-data, making the output look like garbage. Also,
some backends (ox-icalendar, at least) create properties during export,
so you would even get new properties in your output.
It's perfectly fine to export the part of a database you're interested
in, like your whole CD collection, but it requires to filter out Org
meta-data, and to properly format your own properties. This depends so
much on the contents of your database that it is impossible to provide
good defaults for it.
Therefore, default export doesn't even try. Instead, tools are provided
to access values from your own database (again, macro
{{{property(...)}}}) so they can be exported. If you have special needs
for your database, just code them and plug them in.
You have a choice.
Regards,
--
Nicolas Goaziou
Re: [O] [Feature Request] Make property-drawers exportable
Dnia 2013-06-17, o godz. 17:48:49
Thorsten Jolitz napisał(a):
> Nicolas Goaziou writes:
>
> > Hello,
> >
> > Thorsten Jolitz writes:
> >
> >> for me property-drawers are a very useful feature of Org-mode,
> >> since the need to store meta-data for a document is so frequent and
> >> property-drawers are human- and machine-readable, easy to handle
> >> interactively and programmatically, and avoid all that nasty
> >> redundancy and accidental variation of giving meta-data as free
> >> text.
> >>
> >> However, property-drawers are not exported except separating blank
> >> lines. This is a real pity in my eyes, since parts of an Org-mode
> >> document that can't be exported are visible only to the author of
> >> the document and a few fellows that use the raw Org document too.
> >> This might make sense in some cases, but in others the property
> >> information should be visible in the exported docs too.
> >
> > This has been requested before.
>
> I know, because I missed that feature before, and I remember others
> did ask for it too.
>
> > Property drawers are Org meta data, they are not for user's
> > cosumption. Though you can export some properties with macros (see
> > {{{property{NAME macros).
>
> I don't really agree.
Neither do I!
> Property drawers are for meta data used by
> Org-mode too, obviously, but they are perfectly suited for meta-data
> about the document, as well as those simple data-base features
> described in the manual. Why deny Org users the full benefit of these
> other uses for property-drawers by denying them the possibility to
> export their document meta-data or data-bases?
>
> I mean, everything else in Org-mode is more or less configurable, why
> hardcode in this case that export is (by default) impossible?
>
> Whats wrong e.g. with
>
> ,---
> | * My Source-file
> | :PROPERTIES:
> | :github-repo: <>
> | :licence: <>
> | :END:
> `---
>
> ?
>
> This is not Org meta-data, its meaningless to Org-mode, but its
> meta-data about the document, easily stored and accessed, readable,
> and stays in the background during visibility cycling. And its for
> user consumption, thus there should be a way to export this.
>
> And whats wrong with a simple CD collection database implemented with
> property-drawers, as described in the manual? Why shouldn't people be
> allowed to export their CD database to some text-formatting backend?
>
> IMO there should be transoder functions for property-drawers just like
> for other elements in the main backend libs, not in some derived
> backend. If by default they are not exported, nothing changes, but at
> least the user has a choice.
Another use-case: properties might be used as the source of data in
tables/spreadsheets. Now I *really* would like to export my spreadsheet
to LaTeX, together with the "source data". (As I wrote on the list
some time ago, I used spreadsheets to prepare solutions to problems for
a course I'm teaching. Exporting the solutions w/o the givens is
stupid. Of course, I could put them also in the table, but this seems
artificial for me.
Another use case: assume I prepare a test, with each (sub)node a
problem. It would be natural to put the maximum mark for each problem
in properties, and (obviously) I'd like to be able to export them
(mapped to some LaTeX command, maybe even something like
\orgproperty{name}{value} - I could deal with the formatting on the
LaTeX side then.).
> cheers,
> Thorsten
Best,
--
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University
Re: [O] [Feature Request] Make property-drawers exportable
Nicolas Goaziou writes:
> Hello,
>
> Thorsten Jolitz writes:
>
>> for me property-drawers are a very useful feature of Org-mode, since
>> the need to store meta-data for a document is so frequent and
>> property-drawers are human- and machine-readable, easy to handle
>> interactively and programmatically, and avoid all that nasty redundancy
>> and accidental variation of giving meta-data as free text.
>>
>> However, property-drawers are not exported except separating blank
>> lines. This is a real pity in my eyes, since parts of an Org-mode
>> document that can't be exported are visible only to the author of the
>> document and a few fellows that use the raw Org document too. This might
>> make sense in some cases, but in others the property information should
>> be visible in the exported docs too.
>
> This has been requested before.
I know, because I missed that feature before, and I remember others did
ask for it too.
> Property drawers are Org meta data, they are not for user's
> cosumption. Though you can export some properties with macros (see
> {{{property{NAME macros).
I don't really agree. Property drawers are for meta data used by
Org-mode too, obviously, but they are perfectly suited for meta-data
about the document, as well as those simple data-base features described
in the manual. Why deny Org users the full benefit of these other uses
for property-drawers by denying them the possibility to export their
document meta-data or data-bases?
I mean, everything else in Org-mode is more or less configurable, why
hardcode in this case that export is (by default) impossible?
Whats wrong e.g. with
,---
| * My Source-file
| :PROPERTIES:
| :github-repo: <>
| :licence: <>
| :END:
`---
?
This is not Org meta-data, its meaningless to Org-mode, but its
meta-data about the document, easily stored and accessed, readable, and
stays in the background during visibility cycling. And its for user
consumption, thus there should be a way to export this.
And whats wrong with a simple CD collection database implemented with
property-drawers, as described in the manual? Why shouldn't people be
allowed to export their CD database to some text-formatting backend?
IMO there should be transoder functions for property-drawers just like
for other elements in the main backend libs, not in some derived
backend. If by default they are not exported, nothing changes, but at
least the user has a choice.
--
cheers,
Thorsten
Re: [O] [Feature Request] Make property-drawers exportable
Hello,
Thorsten Jolitz writes:
> for me property-drawers are a very useful feature of Org-mode, since
> the need to store meta-data for a document is so frequent and
> property-drawers are human- and machine-readable, easy to handle
> interactively and programmatically, and avoid all that nasty redundancy
> and accidental variation of giving meta-data as free text.
>
> However, property-drawers are not exported except separating blank
> lines. This is a real pity in my eyes, since parts of an Org-mode
> document that can't be exported are visible only to the author of the
> document and a few fellows that use the raw Org document too. This might
> make sense in some cases, but in others the property information should
> be visible in the exported docs too.
This has been requested before. Property drawers are Org meta data, they
are not for user's cosumption. Though you can export some properties
with macros (see {{{property{NAME macros).
You can also create a derived back-end that will handle these elements
just fine.
AFAIK all backends (excepted "org", for obvious reasons) ignore property
drawers, as they should.
Regards,
--
Nicolas Goaziou
[O] [Feature Request] Make property-drawers exportable
Hi List, for me property-drawers are a very useful feature of Org-mode, since the need to store meta-data for a document is so frequent and property-drawers are human- and machine-readable, easy to handle interactively and programmatically, and avoid all that nasty redundancy and accidental variation of giving meta-data as free text. However, property-drawers are not exported except separating blank lines. This is a real pity in my eyes, since parts of an Org-mode document that can't be exported are visible only to the author of the document and a few fellows that use the raw Org document too. This might make sense in some cases, but in others the property information should be visible in the exported docs too. I don't really consider the export options (#+TITLE, #+AUTHOR etc) as a replacement for property drawers, in some situations I would like to use property drawers and see them exported. So here is my feature request, at least for the most important backends ASCII, HTML and LATEX: add a function for property drawer export and an export option to turn on/off this export. PS the status-quo of property-drawer export at the moment: 1. backends that (seem to) deal with property drawers: ,--- | 3 matches for "property-drawer" in buffer: ox-html.el | 83:(property-drawer . org-html-property-drawer) |2893:(defun org-html-property-drawer (property-drawer contents info) |2894: "Transcode a PROPERTY-DRAWER element from Org to HTML. | | 3 matches for "property-drawer" in buffer: ox-odt.el | 66:(property-drawer . org-odt-property-drawer) |3017:(defun org-odt-property-drawer (property-drawer contents info) |3018: "Transcode a PROPERTY-DRAWER element from Org to ODT. | | 1 match for "property-drawer" in buffer: ox-org.el | 91:(property-drawer . org-org-identity) | | 3 matches for "property-drawer" in buffer: ox-texinfo.el | 96:(property-drawer . org-texinfo-property-drawer) |1399:(defun org-texinfo-property-drawer (property-drawer contents info) |1400: "Transcode a PROPERTY-DRAWER element from Org to Texinfo. `--- but in all cases (except ox-org.el) the function looks like this: ,- | (defun org-html-property-drawer (property-drawer contents info) | "Transcode a PROPERTY-DRAWER element from Org to HTML. | CONTENTS is nil. INFO is a plist holding contextual | information." | ;; The property drawer isn't exported but we want separating blank | ;; lines nonetheless. | "") `- 2. backends that don't (really) deal with property drawers: ,- | 1 match for "property-drawer" in buffer: ox-man.el | 83:(property-drawer . (lambda (&rest args) "")) | | 1 match for "property-drawer" in buffer: ox-latex.el | 70:(property-drawer . (lambda (&rest args) "")) | | ox-ascii.el: not found | ox-icalendar.el: not found | ox-md.el: not found `- -- cheers, Thorsten
