Can `org-element-map' act on secondary-strings?

Can `org-element-map' act on secondary-strings?

[Thorsten Jolitz]

Hi List, 

when parsing an Org file with org-element-parse-buffer, headline titles
and section contents (e.g.) end up as secondary strings in the
parse-tree that do have a ':parent' attribute.

When I try to modify all :parent attributes inside a parse-tree with
`org-element-map' (by mapping over all element and object types), the
secondary strings in the parse-tree remain untouched.

Is there a way to make `org-element-map' act on these secondary strings
too? 

-- 
cheers,
Thorsten

Re: Can `org-element-map' act on secondary-strings?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> when parsing an Org file with org-element-parse-buffer, headline titles
> and section contents (e.g.) end up as secondary strings in the
> parse-tree that do have a ':parent' attribute.
>
> When I try to modify all :parent attributes inside a parse-tree with
> `org-element-map' (by mapping over all element and object types), the
> secondary strings in the parse-tree remain untouched.
>
> Is there a way to make `org-element-map' act on these secondary strings
> too? 

I'm not sure to understand your question.

"Secondary string" is not an object type, so you cannot explicitly
search for them in a parse tree.

Also, secondary strings do not have a :parent property (or any property
whatsoever: they are just lists).

Though, if you map over objects, e.g., bold text, `org-element-map' will
also look for them within secondary lists.


HTH,

-- 
Nicolas Goaziou

Re: Can `org-element-map' act on secondary-strings?

[Thorsten Jolitz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> when parsing an Org file with org-element-parse-buffer, headline titles
>> and section contents (e.g.) end up as secondary strings in the
>> parse-tree that do have a ':parent' attribute.
>>
>> When I try to modify all :parent attributes inside a parse-tree with
>> `org-element-map' (by mapping over all element and object types), the
>> secondary strings in the parse-tree remain untouched.
>>
>> Is there a way to make `org-element-map' act on these secondary strings
>> too? 
>
> I'm not sure to understand your question.
>
> "Secondary string" is not an object type, so you cannot explicitly
> search for them in a parse tree.
>
> Also, secondary strings do not have a :parent property (or any property
> whatsoever: they are just lists).
>
> Though, if you map over objects, e.g., bold text, `org-element-map' will
> also look for them within secondary lists.

I meant these strings that I find in parse-trees that apparently do have a
parent-proptery:

#+begin_src emacs-lisp
(headline ... :title (#("topic number one" 0 16 (:parent #1))))

(paragraph (:begin 114 ...)
#("Hello subtopic number one " 0 26 (:parent #4)))
#+end_src

I concluded that they are the secondary values listed here:

#+begin_quote
org-element-secondary-value-alist is a variable defined in `org-element.el'.
Its value is

((headline . :title)
 (inlinetask . :title)
 (item . :tag)
 (footnote-reference . :inline-definition))

Alist between element types and location of secondary value.
#+end_quote

plus the actual (string) content of paragraphs (e.g.).

I can change the :parent attribute of the headline containing the above
:title string (or of the paragraph containing the above content string)
with `org-element-map', but those :parent references inside the strings
remain untouched.

I can access them by writing some code, of course, I only wanted to know if
`org-element-map' might be able to access them out-of-the-box somehow.

-- 
cheers,
Thorsten

Re: Can `org-element-map' act on secondary-strings?

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> I meant these strings that I find in parse-trees that apparently do have a
> parent-proptery:
>
> #+begin_src emacs-lisp
> (headline ... :title (#("topic number one" 0 16 (:parent #1))))
>
> (paragraph (:begin 114 ...)
> #("Hello subtopic number one " 0 26 (:parent #4)))
> #+end_src

All strings contained in an element or a secondary string have a parent
property.  Try 

  (org-element-map (org-element-parse-buffer) 'plain-text 'identity)

on the following Org buffer

  #+begin_src org
  * A
  B
  #+end_src

> I concluded that they are the secondary values listed here:

No. The secondary values are lists: "topic number one", which has
a :parent property, belongs to a list stored in :title property.  That
list is the secondary value.

> I can change the :parent attribute of the headline containing the above
> :title string (or of the paragraph containing the above content string)
> with `org-element-map', but those :parent references inside the strings
> remain untouched.

Why would they be changed? The :parent reference in the headline is
another headline, or the full tree whereas the :parent reference in
these strings is the headline itself. IOW, they are unrelated.

> I can access them by writing some code, of course, I only wanted to know if
> `org-element-map' might be able to access them out-of-the-box somehow.

As said in my previous post, `org-element-map' can access them.

Do you have a simple example showing what you want to achieve?


Regards,

-- 
Nicolas Goaziou

Re: Can `org-element-map' act on secondary-strings?

[Thorsten Jolitz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

Hello,

> All strings contained in an element or a secondary string have a parent
> property.  Try
>
>   (org-element-map (org-element-parse-buffer) 'plain-text 'identity)

> Do you have a simple example showing what you want to achieve?

Thanks, the 'plain-text type was what I missed. I used

#+begin_src emacs-lisp
  (append '(org-data)
          org-element-all-elements
          org-element-all-objects)
#+end_src

as types for mapping, but need to add '(plain-text) to the types to access
those :parent properties inside text-strings.

My use case is to turn a parse tree that is a circular list into a regular
list, and it seems that I achieved it now, e.g. using your minimal example

#+begin_src org
* A
B
#+end_src

I get this "non-circular" parse-tree:

#+begin_src emacs-lisp
(org-data nil

  (headline (:raw-value "A" :begin 1 :end 7 :pre-blank
     0 :hiddenp nil :contents-begin 5 :contents-end 7 :level
     1 :priority nil :tags nil :todo-keyword nil :todo-type
     nil :post-blank 0 :footnote-section-p nil :archivedp
     nil :commentedp nil :quotedp nil :CATEGORY nil :title (#("A" 0
     1 (:parent 1))) :parent 0 :elem-id 1)

      (section (:begin 5 :end
         7 :contents-begin 5 :contents-end 7 :post-blank 0 :parent
         1 :elem-id 2)

         (paragraph (:begin 5 :end 7 :contents-begin
             5 :contents-end 7 :post-blank 0 :post-affiliated 5 :parent
             2 :elem-id 3) #("B" 0 2 (:parent 3))))))
#+end_src

I have a special use for this, but maybe this can be useful in other
cases too, e.g. when people want to operate directly on the parse-tree
and find it more difficult to handle circular-lists than 'normal' lists.

--
cheers,
Thorsten

Re: Can `org-element-map' act on secondary-strings?

[Nicolas Goaziou]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Thanks, the 'plain-text type was what I missed. I used
>
> #+begin_src emacs-lisp
>   (append '(org-data)
>           org-element-all-elements
>           org-element-all-objects)
> #+end_src
>
> as types for mapping, but need to add '(plain-text) to the types to access
> those :parent properties inside text-strings.

You don't need `org-data' type. The tree root doesn't have any property
anyway.

> My use case is to turn a parse tree that is a circular list into a regular
> list, and it seems that I achieved it now, e.g. using your minimal example

[...]

> I have a special use for this, but maybe this can be useful in other
> cases too, e.g. when people want to operate directly on the parse-tree
> and find it more difficult to handle circular-lists than 'normal'
> lists.

I don't know why you would want that nor why it would make things
easier, but as long as it suits you, that's fine.


Regards,

-- 
Nicolas Goaziou

Re: Can `org-element-map' act on secondary-strings?

[Thorsten Jolitz]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> You don't need `org-data' type. The tree root doesn't have any property
> anyway.

I used that because I wanted the whole parse-tree as return value, but
no matter what `org-element-map' returns, it changes the parse-tree by
side-effects anyway, so I can just ignore the return value and use the
modified parse-tree stored somewhere instead - right?

-- 
cheers,
Thorsten

Re: Can `org-element-map' act on secondary-strings?

[Jambunathan K]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> You don't need `org-data' type. The tree root doesn't have any property
>> anyway.
>
> I used that because I wanted the whole parse-tree as return value, but
> no matter what `org-element-map' returns, it changes the parse-tree by
> side-effects anyway, so I can just ignore the return value and use the
> modified parse-tree stored somewhere instead - right?

I have a hard time trying to imagine what you are trying to do.  You
should try to explain to us what you are trying to accomplish.

    Why are you storing a parse-tree?

    What does the parse-tree store?

    Does the buffer of which it is a representation change, when the parse
    tree changes.

    How are you trying to "use" the parse tree?  Is it meant for one-way
    or two-way conversion - i.e., interpretation or exportation.

Re: Can `org-element-map' act on secondary-strings?

[Thorsten Jolitz]

Jambunathan K <kjambunathan@gmail.com> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>>> You don't need `org-data' type. The tree root doesn't have any property
>>> anyway.
>>
>> I used that because I wanted the whole parse-tree as return value, but
>> no matter what `org-element-map' returns, it changes the parse-tree by
>> side-effects anyway, so I can just ignore the return value and use the
>> modified parse-tree stored somewhere instead - right?
>
> I have a hard time trying to imagine what you are trying to do.  You
> should try to explain to us what you are trying to accomplish.
>
>     Why are you storing a parse-tree?

I'm transforming a parse tree for my needs, using `org-element-map', but
since this functions returns what it mapped and, as Nicolas pointed out,
its kind of fruitless to map top-level 'org-data type (since it has no
property list), I store the parse-tree in some global variable that
gives me easy access to the whole (modified) parse-tree. 

But its not really about storing something, thats just for convenience. I
can (and do) wrap `org-element-map' into a function that receives a
complete parse-tree and returns a complete parse-tree after modifying
some parts of it (without storing something).

>     What does the parse-tree store?

its just about a complete parse-tree as produced by
`org-element-parse-buffer' transformed into a different syntax in
several steps.

>     Does the buffer of which it is a representation change, when the parse
>     tree changes.

no, the parse-tree is only prepared to be digested by a different
programming-language. 

>     How are you trying to "use" the parse tree?  Is it meant for one-way
>     or two-way conversion - i.e., interpretation or exportation.

in the end it will be used for two-way conversion, but I'm still working
on the "from-elisp-to-..." part (while learning how the org-mode parser
and the export framework work).

I don't want to talk too much about the project until I know its going
to work out. When there is something tangible I will announce it...

-- 
cheers,
Thorsten