Invalid read syntax (#) in org-element parse tree

Invalid read syntax (#) in org-element parse tree

[Thorsten Jolitz]

Hi List, 

here is an excerpt of a parse tree produced with
'org-element-parse-buffer': 

,-------------------------------------------------------------
| (section (:begin 1 :end 624 :contents-begin
| 1 :contents-end 623 :post-blank 1 :parent #0) (keyword (:key
| TITLE :value Program "Blues for Icke" :begin 1 :end
| 39 :post-blank 0 :post-affiliated 1 :parent #1)))
`-------------------------------------------------------------

When I evaluate a function with this list as data, I get an error:

,--------------------------------------------------------
| Debugger entered--Lisp error: (invalid-read-syntax "#")
|   read(#<buffer *scratch*>)
|   preceding-sexp()
|   eval-last-sexp-1(t)
|   eval-last-sexp(t)
|   eval-print-last-sexp()
|   call-interactively(eval-print-last-sexp nil nil)
`--------------------------------------------------------

from the doc in 'org-element.el' I learn that:

,------------------------------------------------------------------------
| ;; Notwithstanding affiliated keywords, each greater element, element
| ;; and object has a fixed set of properties attached to it. [...]
| 
| ;; `:parent' which refers to the element or object containing it. [...]
| 
| ;; Lisp-wise, an element or an object can be represented as a list.
| ;; It follows the pattern (TYPE PROPERTIES CONTENTS), where:
| ;;   TYPE is a symbol describing the Org element or object.
| ;;   PROPERTIES is the property list attached to it.  See docstring of
| ;;              appropriate parsing function to get an exhaustive
| ;;              list.
| ;;   CONTENTS is a list of elements, objects or raw strings contained
| ;;            in the current element or object, when applicable.
| ;;
| ;; An Org buffer is a nested list of such elements and objects, whose
| ;; type is `org-data' and properties is nil.
`------------------------------------------------------------------------

There are a lot of usages of '#' in Emacs Lisp, but I couldn't figure
out how (and why) it is used in ':parent #1'. 

Nic Ferrier wrote an exhaustive library with "routines for working with
key/value data structures like hash-tables and alists and plists"
(https://github.com/nicferrier/emacs-kv/blob/master/kv.el), but I cannot
apply any of the functions due to the read error. Do I really have to
treat the parse tree as text first and eliminate the '#' before I can
use it as list in Emacs Lisp, or did I simply manage to get the wrong
represantation of the parse tree somehow?

Thanks for any advice.

-- 
cheers,
Thorsten

Re: Invalid read syntax (#) in org-element parse tree

[Nicolas Goaziou]

Hello,

Thorsten Jolitz <tjolitz@gmail.com> writes:

> here is an excerpt of a parse tree produced with
> 'org-element-parse-buffer': 
>
> ,-------------------------------------------------------------
> | (section (:begin 1 :end 624 :contents-begin
> | 1 :contents-end 623 :post-blank 1 :parent #0) (keyword (:key
> | TITLE :value Program "Blues for Icke" :begin 1 :end
> | 39 :post-blank 0 :post-affiliated 1 :parent #1)))
> `-------------------------------------------------------------
>
> When I evaluate a function with this list as data, I get an error:
>
> ,--------------------------------------------------------
> | Debugger entered--Lisp error: (invalid-read-syntax "#")
> |   read(#<buffer *scratch*>)
> |   preceding-sexp()
> |   eval-last-sexp-1(t)
> |   eval-last-sexp(t)
> |   eval-print-last-sexp()
> |   call-interactively(eval-print-last-sexp nil nil)
> `--------------------------------------------------------

[...]

> There are a lot of usages of '#' in Emacs Lisp, but I couldn't figure
> out how (and why) it is used in ':parent #1'. 

See (info "(elisp) Read Syntax for Circular Objects")

> Nic Ferrier wrote an exhaustive library with "routines for working with
> key/value data structures like hash-tables and alists and plists"
> (https://github.com/nicferrier/emacs-kv/blob/master/kv.el), but I cannot
> apply any of the functions due to the read error. Do I really have to
> treat the parse tree as text first and eliminate the '#' before I can
> use it as list in Emacs Lisp, or did I simply manage to get the wrong
> represantation of the parse tree somehow?

I'm not sure about what you want to do with the parse tree. The usual
function to work with it is `org-element-map'. You may want to have
a look at its docstring, as it contains examples.


Regards,

-- 
Nicolas Goaziou

Re: Invalid read syntax (#) in org-element parse tree

[Thorsten Jolitz]

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

Hello,

> I'm not sure about what you want to do with the parse tree. The usual
> function to work with it is `org-element-map'. You may want to have
> a look at its docstring, as it contains examples.

I want to write an 'unusual' backend that does not need anything else
from the exporting framework but the parse-tree as a list. So all I need
would be a workaround for this read-error issue, i.e. a tip how to get
a version of the parse tree that can be used as list in a Lisp program. 

I could not find any explanation for the '#1' and '#2' syntax I
encountered, so I don't really know what its all about. 

-- 
cheers,
Thorsten

Re: Invalid read syntax (#) in org-element parse tree

[Nicolas Goaziou]

Thorsten Jolitz <tjolitz@gmail.com> writes:

>> I'm not sure about what you want to do with the parse tree. The usual
>> function to work with it is `org-element-map'. You may want to have
>> a look at its docstring, as it contains examples.
>
> I want to write an 'unusual' backend that does not need anything else
> from the exporting framework but the parse-tree as a list. 

Then you don't want the exporting framework at all, only org-element.el.

Anyway I'm confused. The parse-tree _is_ a list. To convince yourself,
evaluate the following in any Org buffer:

  (listp (org-element-parse-buffer))

> So all I need would be a workaround for this read-error issue, i.e.
> a tip how to get a version of the parse tree that can be used as list
> in a Lisp program.

Have you tried (setq print-circle t) ?

> I could not find any explanation for the '#1' and '#2' syntax I
> encountered, so I don't really know what its all about.

It is explained in the info link I gave you.


Regards,

-- 
Nicolas Goaziou

Re: Invalid read syntax (#) in org-element parse tree

[Thorsten Jolitz]

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

>> I want to write an 'unusual' backend that does not need anything else
>> from the exporting framework but the parse-tree as a list. 
>
> Then you don't want the exporting framework at all, only org-element.el.

yes, only the parser. 

> Anyway I'm confused. The parse-tree _is_ a list. To convince yourself,
> evaluate the following in any Org buffer:
>
>   (listp (org-element-parse-buffer))
>
>> So all I need would be a workaround for this read-error issue, i.e.
>> a tip how to get a version of the parse tree that can be used as list
>> in a Lisp program.
>
> Have you tried (setq print-circle t) ?
>
>> I could not find any explanation for the '#1' and '#2' syntax I
>> encountered, so I don't really know what its all about.
>
> It is explained in the info link I gave you.

I read this link, it says:

,--------------------------------------------------------------------
| To represent shared or circular structures within a complex of Lisp
| objects, you can use the reader constructs ‘#n=’ and ‘#n#’.
`--------------------------------------------------------------------

what is not quite the same like 

,-----------
| :parent #1
`-----------

but with your other hints, I now understand the problem. I wanted to see
how the parse tree looks like, so I printed it out (I did not know about
the existance of 'print-circle' then, but it was set to nil). Then I
tried to experiment with the printed representation, but the #1 syntax
gave me an error. 

When I set 'print-circle' to t, the printed result looks like described
in the info page, with elements like 

[...] :parent #66#)))) #67=(headline [...]


-- 
cheers,
Thorsten

Re: Invalid read syntax (#) in org-element parse tree

[Thorsten Jolitz]

Thorsten Jolitz <tjolitz@gmail.com> writes:

[continuation, prior message sent unfinished by accident]

> but with your other hints, I now understand the problem. I wanted to see
> how the parse tree looks like, so I printed it out (I did not know about
> the existance of 'print-circle' then, but it was set to nil). Then I
> tried to experiment with the printed representation, but the #1 syntax
> gave me an error. 
>
> When I set 'print-circle' to t, the printed result looks like described
> in the info page, with elements like 
>
> [...] :parent #66#)))) #67=(headline [...]

So it was all about the difference between printed representation and
the actual list object, and the special syntax when 'print-circle' is
nil that I could not find in the manual. 

Thanks for the tips, I have to read more about circular lists in Emacs
Lisp, ,first time I see them in action. 

-- 
cheers,
Thorsten