Re: new exporter

[Jambunathan K <kjambunathan@gmail.com>]

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Hello,
>>
>> Achim Gratz <Stromeko@nexgo.de> writes:
>>
>>> Yes, that has been my impression as well.  Again, I can make them go
>>> away by removing one of the byte-compiled files, so I rather suspect
>>> another case of a macro expansion that's not quite what was intented.
>>> Only this time I really don't see from the backtrace what that would
>>> be.
>>
>> It looks like table-cells have a wrong `:parent' property when
>> org-element.el is byte-compiled.  In `org-element-table-cell-parser',
>> replacing backquote with `list' solves the problem.
>
>
>> This is related to modifications by side-effect of list elements, but
>> I don't know why it only happens when the file is byte-compiled and why
>> it only focus table cells.
>
> There is an interesting  "pitfall" mentioned wrt `nconc' under:
>    (info "(elisp) Rearrangement").
>
> I try to make sense of the pitfall by conjuring up this argument.  This
> seems right to me.
> - `list' will dynamically allocate the list at runtime.  It comes from
>   C's heap.
>
> - A quote list is allocated at compile time (atleast the constant
>   bits). It comes from memory that is allocated for global variables -
>   externs or static externs.  Think value of list is the pointer to an
>   extern C variable.
>
> I am not sure what backquote does.
>
> Wrt above problem, you may want to verify the following:
> 1. It works right the first time.  But subsequent invocations create
>    side-effect.
> 2. Focus on what happens to the `head' of the list.

Do table-cell gets "composed" in a special way wrt other elements.

> I am more or less facing similar problems wrt element translation.  I am
> holding off any checkin mainly because I see some undesirable
> side-effects.

I dont't have handle on it yet.  May be it is just a coincidence that
the translation involves lists and tables.

ps: If only there way to see the C pointers underlying the objects one
could actually sensibly see what is happening underneath.

The closest I have come to doing so is to use a combination of
`pp-display-expression' with (setq print-circle t).  This latter part
was added to my .emacs only in the last 2 days in an effort to bring out
the differnce between `eq' and `equal'.

For example a table like this

| 1 | 2 |
| a | b |

gets rendered as below.  Track the :parent properties, the Ns and #es
and you have no ambiguity on what objects they point to.

#1=(org-data nil #2=(section
		     (:begin 2 :end 22 :contents-begin 2 :contents-end 22 :post-blank 0 :parent #1#)
		     #3=(table
			 (:begin 2 :end 22 :type org :tblfm nil :contents-begin 2 :contents-end 22 :value nil :post-blank 0 :parent #2#)
			 #4=(table-row
			     (:type standard :begin 2 :end 12 :contents-begin 3 :contents-end 11 :post-blank 0 :parent #3#)
			     (table-cell
			      (:begin 3 :end 7 :contents-begin 4 :contents-end 5 :post-blank 0 :parent #4#)
			      "1")
			     (table-cell
			      (:begin 7 :end 11 :contents-begin 8 :contents-end 9 :post-blank 0 :parent #4#)
			      "2"))
			 #5=(table-row
			     (:type standard :begin 12 :end 22 :contents-begin 13 :contents-end 21 :post-blank 0 :parent #3#)
			     (table-cell
			      (:begin 13 :end 17 :contents-begin 14 :contents-end 15 :post-blank 0 :parent #5#)
			      "a")
			     (table-cell
			      (:begin 17 :end 21 :contents-begin 18 :contents-end 19 :post-blank 0 :parent #5#)
			      "b")))))