* Can `org-element-map' act on secondary-strings?
@ 2013-07-06 14:38 Thorsten Jolitz
2013-07-06 17:14 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Thorsten Jolitz @ 2013-07-06 14:38 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-06 14:38 Can `org-element-map' act on secondary-strings? Thorsten Jolitz
@ 2013-07-06 17:14 ` Nicolas Goaziou
2013-07-08 7:16 ` Thorsten Jolitz
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2013-07-06 17:14 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-06 17:14 ` Nicolas Goaziou
@ 2013-07-08 7:16 ` Thorsten Jolitz
2013-07-08 7:39 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Thorsten Jolitz @ 2013-07-08 7:16 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-08 7:16 ` Thorsten Jolitz
@ 2013-07-08 7:39 ` Nicolas Goaziou
2013-07-08 12:06 ` Thorsten Jolitz
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2013-07-08 7:39 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-08 7:39 ` Nicolas Goaziou
@ 2013-07-08 12:06 ` Thorsten Jolitz
2013-07-08 13:00 ` Nicolas Goaziou
0 siblings, 1 reply; 9+ messages in thread
From: Thorsten Jolitz @ 2013-07-08 12:06 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-08 12:06 ` Thorsten Jolitz
@ 2013-07-08 13:00 ` Nicolas Goaziou
2013-07-08 13:48 ` Thorsten Jolitz
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Goaziou @ 2013-07-08 13:00 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-08 13:00 ` Nicolas Goaziou
@ 2013-07-08 13:48 ` Thorsten Jolitz
2013-07-08 14:08 ` Jambunathan K
0 siblings, 1 reply; 9+ messages in thread
From: Thorsten Jolitz @ 2013-07-08 13:48 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-08 13:48 ` Thorsten Jolitz
@ 2013-07-08 14:08 ` Jambunathan K
2013-07-08 16:54 ` Thorsten Jolitz
0 siblings, 1 reply; 9+ messages in thread
From: Jambunathan K @ 2013-07-08 14:08 UTC (permalink / raw)
To: Thorsten Jolitz; +Cc: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Can `org-element-map' act on secondary-strings?
2013-07-08 14:08 ` Jambunathan K
@ 2013-07-08 16:54 ` Thorsten Jolitz
0 siblings, 0 replies; 9+ messages in thread
From: Thorsten Jolitz @ 2013-07-08 16:54 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-07-08 16:54 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-06 14:38 Can `org-element-map' act on secondary-strings? Thorsten Jolitz
2013-07-06 17:14 ` Nicolas Goaziou
2013-07-08 7:16 ` Thorsten Jolitz
2013-07-08 7:39 ` Nicolas Goaziou
2013-07-08 12:06 ` Thorsten Jolitz
2013-07-08 13:00 ` Nicolas Goaziou
2013-07-08 13:48 ` Thorsten Jolitz
2013-07-08 14:08 ` Jambunathan K
2013-07-08 16:54 ` Thorsten Jolitz
Code repositories for project(s) associated with this public 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).