From: Greg Sullivan <gregs@sulliwood.org>
To: Kaushal Modi <kaushal.modi@gmail.com>
Cc: Hanno Perrey <hanno@hoowl.se>, emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: Inconsistent handling of multi-line properties
Date: Mon, 28 Feb 2022 17:18:05 -0500 [thread overview]
Message-ID: <CAMAo5zt0vBBmDxMifs1qPF3uX2u-wVYYMY0FQu05KKbGgt0E4g@mail.gmail.com> (raw)
In-Reply-To: <CAFyQvY1WgU=X0p6Xuh35DktAPryJoOJA_sDUQRKCB1UQtVoT9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4073 bytes --]
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: gregs@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.modi@gmail.com> wrote:
> On Sat, Oct 2, 2021 at 11:03 AM Hanno Perrey <hanno@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
> _________________________
>
>
> =====
>
>
[-- Attachment #2: Type: text/html, Size: 5877 bytes --]
next prev parent reply other threads:[~2022-02-28 22:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-02 15:01 Hanno Perrey
2021-10-02 15:19 ` Ihor Radchenko
2022-02-28 20:09 ` Greg Sullivan
2022-03-20 5:47 ` Ihor Radchenko
2022-02-28 20:34 ` Kaushal Modi
2022-02-28 20:45 ` Kaushal Modi
2022-02-28 22:18 ` Greg Sullivan [this message]
2022-03-20 5:55 ` Ihor Radchenko
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=CAMAo5zt0vBBmDxMifs1qPF3uX2u-wVYYMY0FQu05KKbGgt0E4g@mail.gmail.com \
--to=gregs@sulliwood.org \
--cc=emacs-orgmode@gnu.org \
--cc=hanno@hoowl.se \
--cc=kaushal.modi@gmail.com \
--subject='Re: Inconsistent handling of multi-line properties' \
/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
Code repositories for project(s) associated with this 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).