Thank you very much for that suggestion.
Unfortunately, that does not seem to work for org-export-taskjuggler.
An exported taskjuggler file has extremely simple syntax. For a report, for
example, there is the header, "textreport id name {"
then a series of "attribute_name", "value" pairs such as "formats html".
Some attributes take multi-line string values, which are designated
"-8<- \n line1 \n line2 \n ->8-" (but with actual newlines rather than
"\n"s).
The taskjuggler export uses a very simple approach: when an org headline is
tagged as a report, it cycles through the properties, and for each
property, simply emits the property name followed by the property value (
org-taskjuggler-valid-report-attributes contains names such as "formats'
and "center"):(org-taskjuggler--indent-string > (org-taskjuggler--build-attributes > report org-taskjuggler-valid-report-attributes)) > where > (defun org-taskjuggler--build-attributes (item attributes) > (mapconcat > (lambda (attribute) > (let ((value (org-element-property > (intern (upcase (format ":%s" attribute))) > item))) > (and value (format "%s %s\n" attribute value)))) > (remq nil attributes) "")) > For an org source such as ** Reports > :PROPERTIES: > :REPORT_KIND: textreport > :formats: html > :center: -8<- > :center+: [#Plan Plan] | [#Resource_Allocation Resource Allocation] > :center+: ---- > :center+: === Plan === > :center+: <[report id="plan"]> > :center+: ---- > :center+: === Resource Allocation === > :center+: <[report id="resourceGraph"]> > :center+: ->8- > :END: > unfortunately, (org-element-property :center) returns only "-8<-", whereas I want it to return a 9-line string. -- Greg -- Greg Sullivan email: gr...@sulliwood.org cell: 617-417-4746 70 Pigeon Hill Street, Rockport, MA 01966 On Mon, Feb 28, 2022 at 3:37 PM Kaushal Modi <kaushal.m...@gmail.com> wrote: > On Sat, Oct 2, 2021 at 11:03 AM Hanno Perrey <ha...@hoowl.se> wrote: > > > > Hej, > > > > I have noticed that properties that stretch over multiple lines using > > the :value+: syntax are ignored by org-element-property and therefore > > also by e.g. org-export-get-node-property when exporting to ics via > > ox-icalendar.el (see example below). I was wondering now whether this is > > intentional and to be expected or a bug? > > I use the :value+: syntax for the subtree properties regularly. For > exports, though, you need to prefix the properties with EXPORT_. > > See the (org) Export Settings node in Org manual. > > > When exporting sub-trees, special node properties can override the > above keywords. These properties have an ‘EXPORT_’ prefix. For > example, ‘DATE’ becomes, ‘EXPORT_DATE’ when used for a specific > sub-tree. Except for ‘SETUPFILE’, all other keywords listed above have > an ‘EXPORT_’ equivalent. > > Here's one of the pathogenic test cases of ox-hugo: > > ===== > ** Custom front matter in multiple lines > :PROPERTIES: > :EXPORT_FILE_NAME: custom-front-matter-multiple-lines > :EXPORT_DATE: 2017-07-24 > :EXPORT_HUGO_CUSTOM_FRONT_MATTER: :foo bar > :EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :baz zoo > :EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :alpha 1 > :EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :beta "two words" > :EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :gamma 10 > :EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :empty_string "" > :END: > ===== > > All the HUGO_CUSTOM_FRONT_MATTER properties get collected as expected. > > Here's another example: > > ===== > #+author: > #+options: toc:nil > * Heading > :PROPERTIES: > :EXPORT_AUTHOR: abc def > :EXPORT_AUTHOR+: ghi jkl > :EXPORT_AUTHOR+: kmo pqr > :END: > ===== > > C-c C-e C-s t A exports to: > > ===== > _________________________ > > HEADING > > abc def ghi jkl kmo pqr > _________________________ > > > ===== > >
