emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* Inconsistent handling of multi-line properties
@ 2021-10-02 15:01 Hanno Perrey
  2021-10-02 15:19 ` Ihor Radchenko
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Hanno Perrey @ 2021-10-02 15:01 UTC (permalink / raw)
  To: emacs-orgmode

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?

* heading with multi-line property
:PROPERTIES:
:LOCATION: Someplace
:LOCATION+: Some Street 5
:LOCATION+: 12345 Small Town
:END:

#+begin_src emacs-lisp
(org-entry-get (point) "LOCATION")
#+end_src

#+RESULTS:
: Someplace Some Street 5 12345 Small Town


#+begin_src emacs-lisp
(save-excursion
   (goto-char (point-min))
   (org-element-property :LOCATION (org-element-at-point)))
#+end_src

#+RESULTS:
: Someplace

#+begin_src emacs-lisp
(save-excursion
   (goto-char (point-min))
   (org-element-property :LOCATION+ (org-element-at-point)))
#+end_src

#+RESULTS:
: 12345 Small Town


Thanks and cheers,

Hanno


^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: Inconsistent handling of multi-line properties
    2021-10-02 15:01 Inconsistent handling of multi-line properties Hanno Perrey
  @ 2021-10-02 15:19 ` Ihor Radchenko
    2022-02-28 20:09   ` Greg Sullivan
    2022-02-28 20:34 ` Kaushal Modi
    2022-03-20  5:55 ` Ihor Radchenko
    2 siblings, 1 reply; 8+ messages in thread
  From: Ihor Radchenko @ 2021-10-02 15:19 UTC (permalink / raw)
    To: Hanno Perrey; +Cc: emacs-orgmode
  
  Hanno Perrey <hanno@hoowl.se> writes:
  
  > 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 proposed to change PROPERTY/PROPERTY+ handling in org-element (among
  other things):
  https://orgmode.org/list/87bl4p6n0m.fsf@localhost
  
  However, that code still need some testing.
  
  Best,
  Ihor
  
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• • * Re: Inconsistent handling of multi-line properties
      2021-10-02 15:19 ` Ihor Radchenko
    @ 2022-02-28 20:09   ` Greg Sullivan
      2022-03-20  5:47     ` Ihor Radchenko
      0 siblings, 1 reply; 8+ messages in thread
    From: Greg Sullivan @ 2022-02-28 20:09 UTC (permalink / raw)
      To: Ihor Radchenko; +Cc: Hanno Perrey, emacs-orgmode
    
    [-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
    
    I would really like the ability to use the ":myProperty+: " to create
    multi-line properties for the org-export-taskjuggler exporter.
    However, the mentioned patch is quite large and mostly focused on headline
    caching, as far as I can tell.
    @Ihor or @Hanno, Is there a patch just to get the :myProperty+: syntax to
    work properly with org-element-property?
    Thanks much.
    -- Greg
    
    --
    Greg Sullivan   email: gregs@sulliwood.org   cell: 617-417-4746
    70 Pigeon Hill Street, Rockport, MA 01966
    
    
    On Sat, Oct 2, 2021 at 11:19 AM Ihor Radchenko <yantar92@gmail.com> wrote:
    
    > Hanno Perrey <hanno@hoowl.se> writes:
    >
    > > 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 proposed to change PROPERTY/PROPERTY+ handling in org-element (among
    > other things):
    > https://orgmode.org/list/87bl4p6n0m.fsf@localhost
    >
    > However, that code still need some testing.
    >
    > Best,
    > Ihor
    >
    >
    
    [-- Attachment #2: Type: text/html, Size: 1969 bytes --]
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

  • • * Re: Inconsistent handling of multi-line properties
        2022-02-28 20:09   ` Greg Sullivan
      @ 2022-03-20  5:47     ` Ihor Radchenko
        0 siblings, 0 replies; 8+ messages in thread
      From: Ihor Radchenko @ 2022-03-20  5:47 UTC (permalink / raw)
        To: Greg Sullivan; +Cc: Hanno Perrey, emacs-orgmode
      
      Greg Sullivan <gregs@sulliwood.org> writes:
      
      > I would really like the ability to use the ":myProperty+: " to create
      > multi-line properties for the org-export-taskjuggler exporter.
      > However, the mentioned patch is quite large and mostly focused on headline
      > caching, as far as I can tell.
      > @Ihor or @Hanno, Is there a patch just to get the :myProperty+: syntax to
      > work properly with org-element-property?
      
      That patch has been merged. However, the part about merging
      :myProperty+: into :myProperty: did not work as well as I thought
      initially. Now, all the instances of :myProperty+: do get merged and can
      be accessed via (org-element-property :MYPROPERTY+ element). However,
      they are not merged into :myProperty: because it would interfere with
      property inheritance.
      
      Merging everything into :MYPROPERTY is possible, but it might break
      third-party packages that do not expect element properties to be lists
      (currently, most export backends assume element properties to be strings).
      I am reluctant to work on this unless Nicolas displays a clear support of
      such change.
      
      An alternative could be modifying org-element-property or
      org-export-get-node-property to support multiline properties.
      
      Meanwhile, export backends might be changed to look into :PROPERTY+ in
      addition to :PROPERTY. For org-export-taskjuggler, you may implement
      this feature yourself. Note that org-export-taskjuggler is not a part of
      Org core. It is in org-contrib and currently not maintained.
      
      Best,
      Ihor
      
      
      ^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: Inconsistent handling of multi-line properties
    2021-10-02 15:01 Inconsistent handling of multi-line properties Hanno Perrey
    2021-10-02 15:19 ` Ihor Radchenko
  @ 2022-02-28 20:34 ` Kaushal Modi
    2022-02-28 20:45   ` Kaushal Modi
    2022-02-28 22:18   ` Greg Sullivan
    2022-03-20  5:55 ` Ihor Radchenko
    2 siblings, 2 replies; 8+ messages in thread
  From: Kaushal Modi @ 2022-02-28 20:34 UTC (permalink / raw)
    To: Hanno Perrey; +Cc: emacs-orgmode
  
  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
                         _________________________
  
  
  =====
  
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• • * Re: Inconsistent handling of multi-line properties
      2022-02-28 20:34 ` Kaushal Modi
    @ 2022-02-28 20:45   ` Kaushal Modi
      2022-02-28 22:18   ` Greg Sullivan
      1 sibling, 0 replies; 8+ messages in thread
    From: Kaushal Modi @ 2022-02-28 20:45 UTC (permalink / raw)
      To: Hanno Perrey; +Cc: emacs-orgmode
    
    On Mon, Feb 28, 2022 at 3:34 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.
    
    Sorry, ignore my email noise. I had never tried ox-icalendar before.
    But I just tried it with your test snippet and it doesn't work as
    expected even with the EXPORT_ prefix.
    
    Also, I don't see any location info get exported to the .ics file
    (with or without the EXPORT_ prefix). So I don't know what I should
    expect to see in the .ics file.
    
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

  • * Re: Inconsistent handling of multi-line properties
      2022-02-28 20:34 ` Kaushal Modi
      2022-02-28 20:45   ` Kaushal Modi
    @ 2022-02-28 22:18   ` Greg Sullivan
      1 sibling, 0 replies; 8+ messages in thread
    From: Greg Sullivan @ 2022-02-28 22:18 UTC (permalink / raw)
      To: Kaushal Modi; +Cc: Hanno Perrey, emacs-orgmode
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: Inconsistent handling of multi-line properties
    2021-10-02 15:01 Inconsistent handling of multi-line properties Hanno Perrey
    2021-10-02 15:19 ` Ihor Radchenko
    2022-02-28 20:34 ` Kaushal Modi
  @ 2022-03-20  5:55 ` Ihor Radchenko
    2 siblings, 0 replies; 8+ messages in thread
  From: Ihor Radchenko @ 2022-03-20  5:55 UTC (permalink / raw)
    To: Hanno Perrey; +Cc: emacs-orgmode
  
  Hanno Perrey <hanno@hoowl.se> writes:
  
  > 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?
  >
  > * heading with multi-line property
  > :PROPERTIES:
  > :LOCATION: Someplace
  > :LOCATION+: Some Street 5
  > :LOCATION+: 12345 Small Town
  > :END:
  
  Confirmed.
  
  I am not sure if this should be fixed on org-export-get-node-property
  level. Icalendar may want to concatenate the multi-line property
  specially. The usual Org approach is merging such properties into a
  single line.
  
  I can see multiple solutions:
  1. Change Org's behaviour globally and make org-element-property return
     a list for multi-line properties. This will likely break things, but
     I would be in favour, unless Nicolas disagrees.
  2. Change org-export-get-node-property to behave like org-entry-get and
     concatenate multi-line properties into a single line
  3. Change ox-icalendar to consider :LOCATION+ properties and merge them
     during export.
  
  Best,
  Ihor
     
  
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-03-20  5:58 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-02 15:01 Inconsistent handling of multi-line properties 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
2022-03-20  5:55 ` Ihor Radchenko

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).